From Andrew.Gowans@ofcom.org.uk Mon Mar 5 09:06:19 2012 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 DDDFA21F87D1 for ; Mon, 5 Mar 2012 09:06:16 -0800 (PST) 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 jewruRbwxo2C for ; Mon, 5 Mar 2012 09:06:16 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id C65A221F85C5 for ; Mon, 5 Mar 2012 09:06:09 -0800 (PST) Received: from [85.158.139.83:23441] by server-11.bemta-5.messagelabs.com id EB/2D-12959-082F45F4; Mon, 05 Mar 2012 17:06:08 +0000 X-Env-Sender: Andrew.Gowans@ofcom.org.uk X-Msg-Ref: server-11.tower-182.messagelabs.com!1330967165!17923415!17 X-Originating-IP: [194.33.160.65] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22326 invoked from network); 5 Mar 2012 17:06:06 -0000 Received: from unknown (HELO WOK-INTRA-EDG02.intra.ofcom.local) (194.33.160.65) by server-11.tower-182.messagelabs.com with AES128-SHA encrypted SMTP; 5 Mar 2012 17:06:06 -0000 Received: from WOK-INTRA-EXC01.intra.ofcom.local (10.130.130.67) by WOK-INTRA-EDG02.intra.ofcom.local (10.130.239.20) with Microsoft SMTP Server (TLS) id 14.1.289.1; Mon, 5 Mar 2012 17:05:57 +0000 Received: from WOK-INTRA-EXC02.intra.ofcom.local ([fe80::550e:933d:224e:6a19]) by WOK-INTRA-EXC01.intra.ofcom.local ([fe80::f0b6:2506:a722:c58b%15]) with mapi id 14.01.0289.001; Mon, 5 Mar 2012 17:03:59 +0000 From: Andrew Gowans To: "scott.probasco@nokia.com" , "paws@ietf.org" , "paws-chairs@tools.ietf.org" Thread-Topic: Latest version of Use Cases & Requirements I-D Thread-Index: AQHM9y1QacNjlAuNJUiwuASfjndBCpZb8P8A Date: Mon, 5 Mar 2012 17:03:58 +0000 Message-ID: <9983D74B649EED43B27BF353837B20C57D942DE4@WOK-INTRA-EXC02.intra.ofcom.local> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.130.131.249] Content-Type: multipart/mixed; boundary="_002_9983D74B649EED43B27BF353837B20C57D942DE4WOKINTRAEXC02in_" MIME-Version: 1.0 Cc: David Donachie , Reza Karimi Subject: Re: [paws] Latest version of Use Cases & Requirements I-D 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, 05 Mar 2012 17:06:19 -0000 --_002_9983D74B649EED43B27BF353837B20C57D942DE4WOKINTRAEXC02in_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, For your information please see attached and the following link http://www.= cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-regulatory-requiremen= ts-for-white-space-devices-in-the-UHF-TV-band which is a publicly available= version of the document which the current Draft UK regulatory requirements= for WSD in the UHF TV bands. This document gives guidance information on w= hat may constitute the regulatory requirements for white space devices in t= he UHF TV band in the UK. They have been generated in order to form the bas= is of discussion between Ofcom (UK) and the relevant stakeholders in the UK= . It should also be noted that although most of these requirements may be c= onsidered as being mature these are draft requirements which are still bein= g discussed in the UK and as a result they may be subject to changes. We wi= ll issue any revised versions if necessary as they become available. I hope you will be able to take account of these draft requirements in your= deliberations. Best regards Andy Gowans -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of sco= tt.probasco@nokia.com Sent: 29 February 2012 21:59 To: paws@ietf.org; paws-chairs@tools.ietf.org Subject: [paws] Latest version of Use Cases & Requirements I-D Hello, Rev 3 of the PS, Use cases and requirements I-D has now been posted. Thanks to all the people who provided comments and feedback on almost all sections of the document. We believe the I-D is ready for working group last call at this time and hence would like to request the chairs to initiate the call. Revision 3: http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-r qmts-03.txt Diff from Revision 2: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-problem-stmt-usecases-= rq mts-03 Regards, Scott & Raj _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws ________________________________ ***************************************************************************= *************************************** 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. ***************************************************************************= *************************************** --_002_9983D74B649EED43B27BF353837B20C57D942DE4WOKINTRAEXC02in_ Content-Type: application/x-zip-compressed; name="SE43(12)Info03_Draft UK regulatory requirements for WSD in the UHF TV bands.zip" Content-Description: SE43(12)Info03_Draft UK regulatory requirements for WSD in the UHF TV bands.zip Content-Disposition: attachment; filename="SE43(12)Info03_Draft UK regulatory requirements for WSD in the UHF TV bands.zip"; size=328467; creation-date="Mon, 05 Mar 2012 15:30:24 GMT"; modification-date="Mon, 05 Mar 2012 15:42:10 GMT" Content-Transfer-Encoding: base64 UEsDBBQAAAAIAK5qUEBZ03uT17YDADlQBABHAAAAW1Rhbl0gV1NEIHJlZ3VsYXRvcnkgcmVxdWly ZW1lbnRzIDIwMTIwMjAzICh1cGRhdGVkIDIwMTIwMjE2IENMRUFOKS5wZGbsvAdcFM+WPzrknAQk yqAgOScBgSFIFsk5i+QoOQ9BQJEgWUEBCZJBBERyziggOecoOQ4wzPwb/N299/727u7dfft/7/3f 2/ZTVHfXqXNOVZ1T53x72r6v9kiOk5dLkAD3fhVwEODy0vPQOz+1I8AVE+PW8nGx5JYxdzd3cLbm VjO3tnSj5wOaNbgfmztZs1g6ccpLs9Jza7q7eli4a7laWmo4O7vT8/II3dComLvaKzpZOQN8rk8t n9EDdJYSwEGAa+n07EYG35+F3QjhlnH2cAIYiXAr2z5zM6Tnv+YH8P1dCdxUfEK/K5Gbiv/3Tf7f VwK/K8EHN5UQ3+/qN4mQ8E31QPCmEv7NReQ3a5HfHURE/pDH+0d9I9+Y/m8V5/9HigN/XC0BxX/P kYalm7OHq4WlG0Ai6+0ur+lu7m4JnMtrCtLfSAfOhOlv1JGQ4JZzdnIHGuV46YX+uKOn+tTO0uL6 pqIjwFyEXuSPBjVXZwtNS3dDbmDpuLUsvd1/E0j/rmR+V4rX+nKrWD6zNZd29jakvx6hoIggFz8f vbAAL5cInzE9MM1O7oC+bvQCv9VxdfZw+ct4bi64Nbm1XM2d3Fyux2Xhwy2jyf3I0tPWwlJDXhrg rmX+1A0g+b3+v8fuRs/zt9Mk8DfTJGfr4G7pyi3nAEzDI0sL52eW3I8tnazdbej5hHkEr3u5ubta mjsS4Hq/rzIwdqaRv+XP3IzkiX0GKlkrWl8mRv+cPZGCjhKv5xURGocll/WM7t7PjxuUjaZQbfG6 W7aKyW5TzeH5d619a4uKiqyTRQO/zpZw3bZ+eLSa0jXgWdcxmbZa4xPgX+tz2XewGVHdtwymSCk6 eVo9Vdx00SsGOZ+ibfK/v3boK1punGzGlUeqa0QRelDqLviWvf4uvB+mV/fsffUHzk6K6fOnSjtZ KkzC09q81sOK342x/bPdcymtc48oz0fIrd/jfShiejGx2txDWPHo8cuvbXkSgy4vP/bpvbpP5Zbt rp+H2XVHmsM4qjNspmUSFPvlAaFy+2b3g7ol0T13V6En+57t9EPmKQv0O7UtERwfmmX12ndLzbxi OCCe5Gmt9/dsMxLs1blpxx4tO263p5nVRK+rEvpbs6/7rr/KKPspuxB2n2cbhzLTfT+EvvNHrVAN W2HN4D35V9mZ3JSyDm/2XfmpPsIYP5zYFelEOYx/Rdk1ubWzMSNZXe8tvRfHvLCGEtXxWsVYkjKo rP2uWCP4RQWtPwb2nHWrbzfu40CZbTYGogePpMR6iDBr0lt48FA5GPjXMXhzv1LB46Sn0zNRklYe unRNZ77MFaDHeV+kCcLdDtZ0R18AEQZ2Brl9Wr96FnH2WleyRNNFaVdDMGrAQgutJlei2TyKveuY wgU9C1WjRbJbwWPh1v3IPVcdPrLHTybCGVYIZFHqSbzpFWmMW2TH3xJiys0r5HZI7rqCaH2tsKjx URjRdhZDNSueVDLu4wQSnoTMfrlNIeYSN4FRvyBu3UIIC9RE5Ymghd2jpoYf+YBg9I6cCRSmoBod wUZ605jNY5PJW5/tWXBVg5eJ0aIp6bIEIu/4K4uyaykXzUhHvgqaP3lcyCSK9dzmG94vlpDaLJHI uUd7eu8Y7xtFB9Wc4ns+Er3Iv78cVDkch0bBgzftZjtUQ/dFpk6bisxdcdv+ng2VrPVlDW9LU/43 ekO92/QmMWQYhApMm0WWLUtSCyxBvaqOFHGJ+FiSdzZI+VFLw3XSeDDYsLrx9V8maaXlPI90wcFq nFSJYWwxoGyte4d214xujFWsO0XAWsrsGeqqNFZRr4kk6/Nb7p1CnGQYKb45W8x2Q2zYZGJBxMXa HbK7JVtVEe0iQ7EMqz1xSXezOBZ4KPcqevNVvi/m3yLAlnTjfndIRszA/m5XdkqDLPInJYmmaZaS CGbY1HLSV8rc29SHreK5tmyFaKiKmlU46o7BQnXdLFW0zmpCzQcKtO998b5bsQXJkKK6E78iwBTu 25VWEyOAyRG3vjGcUnvB8VB9SLKIvpE+fatUOwldREkVa61VRpSl0gXbD03WszsU1y6po1HN0FcN XsyWRxB8gErOR3nvx2M30v2U7yzkSiEXq7bCz3ai29H0cUUEpZlzc3Npt2aKhbPDyvfMtLqXZsxU tObVInBzWIk5M4kL6oOb7Oy1KWXZHxwL3n/EYJBLKvjxi0si6dRoYUyOs+8CRWR/IUehlpvrTwnM XXOwQXLjLHoJOb2iMUdqvtot/Z1BnKp+u3lksK00SI2KhPzwMT6rbwT2/BZV7rSPJXvleeHzD/jB j8qdW8lsSO9WOfTzFpXmiKpR9oFcHxF8nn6Z7NdPgM4DUpOF6RlO0GOlqpONicTeospAdXUI73x0 DErUFcl2CQoekX6MO8lHjLrxWgmtN7xQKxHCqNgt+s4sswyzrFA/QYimkCaRp6o2Anet2DBu8w0G c6oQG7EoRyybNq9OnOQ7BQY8iU9cdzXGp2jObWrImbO0KjH563iZtvjI6DGOQIvpexMhB3ezMvOx Kt36ghJ+5MJvedxnfah/TyuGvsBQ/4Dep+Vt6sbjFZ97ttwWw2ZodrKvRem1ZVVd6Mheu6QRSGzW cH6Rr4aD9KYP2/hlPI0kZYIZRnMpWS3YqqYYNzW37Sft5aWUCEOnsw2GUsc+aQvYDJF1ek7hbOvo hS+rY/vCJbUV+jS5J/SYPlYZPr7NoG6xPERpRI7OyOncjPoS597QsgvTuuyIi00iOd14mvkGzVPi ejVB9e5mo/r0R+8eYpfs+2tSB4ipRI4ePYhlgAl/ETI8oz/Gpq/uyaolC454Ux2szSomQu4YPciH omKcFkUt2bSgsy2+wavHQE8/xRp35Liq4vM53maiyFzn/tnJlC02W/vnOwQTopsYzzK/VmCLDDJ0 Zd9hYiAcZ9LteHPygy68HleVUDFtXQrhdESd8DWo2wJqZcJATWwQU2lJ4kDwAmLjSLaasNDRcft1 +hN0brat1pDEEYOHuffs6aZnxpbf2kyz4eKszoyUcinkZ7ILBONVory4m1SOIxH0RKdMu/zDp1sy 6p1qKGrQHtuWhFqzZ1kuFnyPUDdVRnDHmeSFLKbs1u/mf/uMW5Qece9BiRiZCxdbKp0fG419Ihn2 T/eft/xbrBqM04PMereevwpj7a89bZR549wCDRT9QNvk8il1GE8AZHEwIGiLzWQhdOgb+X4B03CK ILla197kCXOZNXPRr3P1dx++x/7cnq3/UXredyI2oHOULTzdH9vqEF39/RyuwFPc9rgeKqhaYZkW BK475147rttcSRteG1qIkGwJOkoHl1lbOZeer2EZlYK/xULmtz3TiiJKV2QW1AIYnSCwx830jL7i /maqbnAGr8vFX86qUVcTT+ETS8SYXNhmZCqH3lEDaknTfVdDA9x7s7tnm+j4kj/0pdUv79f6oU7e nZxedT8s4+73FW2pnDvH37pfWGZN10LBA/ecazwrPUO4jROqX8RKu/tS9NRrzqJNqV5AX+bOs5CP zg64/Jx/fjhsD9l5Ztew6Naw4mM+gS2IH10/3+My3qPK2XBwQIjM1DGKCo11zpkvq5G/It8Q/nHr qnSjYlIC3b5++YDhNbh5VCbr+T2Fbxj4PZBJLi7PiFIJHwp3+vfDp168DHuD6eHbe5+NTRovHems Xs9aXbaoFX3tm58vWfNvSAWfT7o21NFNExQ9aMuhOFvr7LB6eMokBY7fcT5EELQa7CSvXewsOdj+ SIEWrz33/MQX4KhjX2HR7JzM4NdKaPLhVOx9fBo7EvbQM9D8CdI20Lh4gODsjo9ui2ViROOVMbik xCRw+kn5luAa4mf8w9yTzSos47KexAX0aOUuhsfIIytZ8E60k9DGkLV7hc0HYZxop9uRq3QKl6T9 chIbPlrvEfX6M+nbMNbXGt4j4FmHEdLzDavndxSWSTm+RrBapK1+Z4lR/fzm5ItIrb4EFQ3Esl6z pqnZwc9XqFbf6MPl8vlbq5N3a2h53/PedhBA5r0gPlmT7Xuo8tW962vLhgS+JdSzHE0P4HjeZncy OKKsvkKZephrnRZaikYPr2bC3tFpIaPxzqwqhPJen9hI0W4LyRH7T7GFz9sTFJ7yPwnsQ/IFhYUf XKE+d9DVFUuLoZD33U+/gIaRHKN8XR5B+WD964jIjcKQy8RJgPv1yYn33W1nIdwMjgylmje1LVs4 GuWw0JiyH4L4jeX63D/mipOXO8qrF71HO5syuxns0DLaDm45n5ib89N0si8FVGSvaDSxi/Jchnic /DqdfTo9fLhZt3+wi2Baw46eZJqr/GEyQO8dWO8fE6VmY5p++4rtc5Mbamb1+uvZQ7jzYISPbdLD ZiEvz0+DJ1uidu6XTmIuOFeb+4HvLi5zEUODl7Hgu62HXpgQhAXTt0e+vPfJAntCCaZgCk1CMEdR H48BtO/+fl4n6g8yKyYPf52kqrDtlLHBtGDTRR2rX1IToqngcDCRA0P/TdL8lwz4L/mz4J9hxr8A CW5pFe4nzq6O5g7cFub0PFyCPLwiQn+begv9ues1wuDW9Hjqfn2hBUCxm7tPzB2BJl5uaXM3yxsK KVdbgKesE5Cg2zpZc+vaOkk5udn+y/U1zSNLNwtXWxd3Z1f6G8QEpPaubu4yNuau9Px8ADb845yX jw/o/szdxg045XnwG738VcEH/0jBv7K+ubzR7rdGAG6wdrvmrwjAUVsLKSdrB0t6Hm4pN4tryCXC I8h93ff6nJOPlwdArS4KlrbWNu70D/iEuaU8rW80oRcQ4AXQqPfvCz4hIcEbMbq/KQV4eLj1/ujF J8gDwBPz6zHT8/MDGMfSUQfofUMufYOoOIHeN7Lo+Xh4eK7F/D1EFP4n1473bzuJ/LnTHyjwXxbu Btz9nlb6B/xC3H9Rl1cQgHMOzq6aLuYWln9FadzStu5uapauMs6OLs5O17Mj/Bcg9khG6w8YpgjA QFcX52tgdoPR/4LLeIVE+EX+FpghJ5ALIGIlOUU5EAoKCmgG+AdCToNkQNiYmFiYGNhYWFg4ONi4 +GQE+Hh4+FS3SInI7lCD6e5Q09LSM3Ix09/jYKClZXnAysHDKyAgAGYWERfmE+PiF+C7ZoKCg4OD j4dPSUBAyXeX9i7ff/pANoNIsEHjqAtoKPdAqCQoaCQoyHYQGARCwUC5OUB/HCioaOgYmFjYOLh4 AEEVMQgVBQ0NFR0NAwMdHWgNANpB6CQYt+7ySmGSqptj3XtOxhcc9xGbQbq8hVxjaJ+R/6lrCA7u bQpKKur7TMwsrGwCgkIPhEVEZR7JyskrKCppamnr6OrpG1g8s7SytrG1c3P38PTy9vENfREWHvHy VWR8QmJScsrbd6lZ2Tm5n/LyCwq/VFRWfa3+VlPb2tbe0dnV3dP7c3hkdGx8YnJqcWl5ZXVtfWNz 6+Dw6Pjk9Ax2fnE9LhQQGspfjn84LhJgXKjo6GjoWNfjQkH1uiYgQce4y4t5S0ody/w56T2+YGwy 6biP5S04DPwa++RPXYdwbzMKLN4/uB7azcj+uYGF/JdG9i8D++u4pkD4aCjA4qGRgCCgYwimN3/r uAnG/klHV3ilbV7K468+jPGtTNYWt+Lbk3oYj1JnkKAXpC1I0DGbDRTGFYEEvcpuzjhUFRNEgsyK TK/IqgbVsCBIEDZzKBK0oTWIBO0bEyFBpPJw+nSg/qgpgwS1uEPgKu5k/0P3P3T/Q/c/dP9D9z90 /x+lW1A9Z06nRoI+a5chIg022DP2meEJAwTQCbZxJEiW050MpC77bxQ5WSq6SqCyyUSNZPlHpfsE +GseR2b5QfJM0ETlSSfHecobJkgDPRlZNvMXziH9+ekp+Sv0bSRo7wIJigb/3dVt8JcMK5sh7acj Dp+6krzQ1i+/oOmgsVLhQ0Rxntu7iwIipGTJ1FD+byr/mZlKVDcqi/T3yfW2fKwByfCLTZ7jH4Bj n5JRq2drVI6wFlUUdhc7anb40kV/M7Xj6WwrRKtpuvvd27PhgNRkXD9hB/PnzHHkTNLybG3qKg5j vCLjmQBYOWyxQNGkvmSlqf90GgmK8hVgLPmQ+73nDmVQEMIfkfRjzt969Fl3xbCj+Z2o4gF4uYm1 LFa56r0WKXuai4qvGUvVkVYQzn7iWIVF8LignOrLdLZE2q2fXNDaSEjuM9tUwqLixlmJTtvzzlXT xEBx9uIvMPmlh0HUC1PTaJMrM/IrvBeDonF9PFMqsgGdpN7L7d/HDWrh2GQZ+2neKYjQB6Zno56f 4bdrGc6m6iWRoHISSP9I9L7OY//a3vU5MKIBE2zaq5MKXYDsE3KKBSy9cIh+6obYx7rQ/oZggpVy n78MR4J870N+ft0NJLDbwKke4bQUD2Xnho0/LPAXPxBKLj7c/M5hAVswWz6kRSRG39VlK96uCVyJ fg2Norv3MlaIhjWl0cKS+dB50/CrKbXagqktR2MJfs0VNvlKTDRNosczj4UifBKVT/ZiaWjqpgm7 EmHDgUwwa/WpTwclzyAtLmFQk4wSj+QzHuNHX6b74ztnqSiJ7Ve2Gj79Ek2OFU5TrU+drdt2Ihpx F6AzYQg3G934MZc3KpC00kgFa6iJnzZ9yeV9qcXeBceB5sOLRjmdMhuqlV/baugZWRoTSpGBBV83 j7f2JRciQfd8WbJC3yit+sseoMnsHwnw/XDiioB/jlijv0wP+bb3cp7YKnzJmEI+xdyopH3LB+uy 0M8v9VBDEbADccXMC6OKux5ZheOeqs98hQoOIvRrrIwlpuZ+SvQ31yFBEZtGJXtR9bKBqhlFs2an 0adEw+RhsljDQ30ulbo16CqCox1tTulL+oajM+VXdhwJc3VQHLjgiL/MLRNjyMS2YdJTvkMi881d +2GBvXA6qs+yRFbjT0Trd59AUYIVljqshcX4VwyqJs53Iy88xBgWjymN6fro9gsKzyQw90d/7iQo fKXbqFPdfLxkpCx9MQwNPtJjdGcqnt56MJZxsOPznOjKLSnlnPqEmxTOEMaZUzv4LKFfPaNCYRLr angcYnAonatXhErpIrWjcOrytl5CiGB4vNZaPQ/+6EDivdx3xU/qcNJ8Fyhd1fQGlHIpLpnTbqCX OVSwUSnWNS9j3QQiy8dL9eRW7djtgLGI0dTAbOtC/dzRpFYVvBgqQrtR/+FFCNmct6m24pKnva4Z c4QY38WVvIWpgsFMh48teT8HNauaKM8udncmrHiAMxkzS7fepD8d2GWO/o3d7b+1EEL/BFF0/7zf sICyIllQWLK+wOWL5TM3KHyj3jIx3tcCNnZ3tKMODGlCV/WY7RWJe95nl7j8uZulhB/vwfeQIDGA QtMEzPFFlb2PvaJ73e0hbXyAiqKPl+DV9rgXoYnt+7ryXRUphSswV9/mwiZL2esiXJasdxuxMQ9S tSIFrL3uams9i/fTLfeGLBo31KvP228xfRMr+Rr4CAnyG0EkySyCw35aBQRuibdQdjlgL4tPXwR6 bJOBwR/WjjS9fbnGZhEvXFrI6+1peXNsslG0JUFaiRqD/kWOW63XQ4+yimRByzggCq2EkjT3eTkU SUjoL6MYQ+mQIBkT0qUB7HlvHZi88BHnM+ae94Q0ExdguwudCsGr2+OmQ+ufa9V0ZM8NabM9GTal fq2+qzJiHHm2Rzi/4l8jqz/CYTUsSPOaPaz9s4J6E26J1AX+s5zE5H72gn3naGcxTl/AOoZnm/xQ xCFTpjLwX8lZoaLHrOOheerG/Fu/8H4FKPXS9Omjv+n9mBTxXL+Rc/RHxKLfjpTCLXk60qslF4im if1+RHs0wUoq/t7b1f43z47Nz4IuYqBoxuBOnCkIdhcxI46TGtgFBbIota/R94G2VdjH0eNIPvxh ZbxATMeHVxyqGraV6lIXt3R0pIzBwZUKJ3u3DQwe86MmcGSP6r4PZEat6d1GUMzLWy7bWyYGMcu9 JN3yAfeGJoBZuwg01Ob6LzBILGQfqZHLgdByJSJZILzAwgWR5pfdGw8k3RINr/PzsfewpyXtNVYP 7h5YNKmTxdIhpTHEYWZ7Mi4mjyAbq0CCIGMZsDOYOhKEa6+PBGX8UoX7wdmnNzKPIdUHTf2Ny+2Q RZVfpkdXtkhQLDTMtynsuO8DTVuygcdIEePY5ucvxwxigW9LfIXJaN/W95G8jgzTdQ/Lybeur6oy HqcgeSRu3IzwSIJEiT10eM5VbpWHqA2V6qHWZt7vqHCNr4mARSwqXGztZ5xpxx6SDcD06UiRoMwv 0PlqQB+CwLxXgEbOu9a6sq49BxStsc2jS2Btc3iHUWhnIO034df6FRaba8GS6bfqvUIv39Uoa5fs lXCNezT0a8RquUCT9H5JharYdABOQ/zXjEW+hGn1BPwBxElOaiTd5KsF1iEL2Zr9RiqnWoGL1cfV PqIpU4Qfju5HbRSrLlnMSaYuiUGmpnBHBUSm4WSqfj5UEyC/Lokne8OEJmUk0B1UedPwcxDIEcY8 JJV5QF5MQXdkrVVKN3VWXnnQaDGUJ8mf5EMXmYE8bIMdmEdoCtxGQMtOPAuxbJBc8XFcoCgEXTS6 KGEQRxdud1H7ufczw8Tg448su8XXKc4bQH9QVna890fjn0ovxfWWKlYO6KJJ2raSg5CgcUskiBo3 WkR5US6XPF5M9WNCcOHkOqKOGzbaB5jvL4T47kLKVQ9KplPi2IFlISsK1sfczKAbjr8L2p9zGPIB GClCcT28aZvcHgnKSq7FBbFkRYLY+wIF7Ahuf8iz3XrCHJcDzVoGFwUmbQkuZVCtWCzhYR8dlpTT +yVDFljEHeJxvSdMc5Eghu9AT6Ih1ET8VKXkUfRql05VgnsFcBX0ninODBVv0yfG7G0GAaml+C6l ewVUkIKSSDsQieRmpAFRb6HKDydVT2D2pf4uA3vhbzwclvf61g4F6i5xV0xxPZRDN2O8xN9evU7B 39W/BTCe8fjBwOgElQEMzCuJBWCA4jIyMk2O3EblDTpdCXzlEpPrx2UmsNaWek4beb8wCGyzjKTM ApZ2N6WZ+lH06BQflEwgFo3vU2NDRIZhRRcwAOtGckZ+RfSD76Rk8UL4xaIhhFL5G5kqTMUDWf5E y4bOpJu/aKPKt3hZSB9BX1/lniK0x8Z7Tqs1J426ntvztwlYu9bSEtuP+D88CF5+FGpczR0jMYS9 fmC6D8+X4ObrZpN+8onK2HMr1iyr/LiMzKb2J5pFfhsrpNXQPlA+dbxbfEPC030dy7aI1yYrEvtW /lZqR3i0nZMHXv7CSy+L8QnCvP3ieQrvwvHWWmWjvldc4NUQ8F41jPDkaK6i1I766nJ2i7QyRrW3 5lzNF2VCzU/ESlXMuonZJjAwItc+gwq1QjZLH3Ob+Vs3OCR2S9ZlKiWmXrGQdN0uQS4CRi+hdyVS 6hpJ9LltVU8JbzZs3quAMUGZnyJZ11NcmZdxxKNqsQx/Hpatfnk/PqgolKPkzIIuD84+JaAaLgH+ +VRTvGm6FEufecV60vdpXPIDwTazhvHiOob1Ezm3Fxpdg/jDc1PenSY4Wh490uxbbzkcOd8w3h7s zM7KArFp4lsX259rinm1X2yqHiBBQf7vZAMeFsB0H40uW9YPO87EnbVimMNi7DvEfBbC93NH3Azr lPN+uETN+9CUDl8RMAw3W7s/dzt1dO1eYUjV0xPQEOXZ0H55r1acu2uOEfCkKiqmKChG1x4KXBVS 4iag5pvkMlJYpBUJZZgR4z8wadOMf2isw2vpMoOD0u8Q2NQGQ3hsFLaM8L0P7b7XqATYjPLSu9Ll BOn6N3XSaTuTMU/mwqCEvI/PH88zhlGKHgsZZo9sflGIYxCLIQfCpwuG+lhVmjjW42TEqUqcnKiX xQSRmwnGUhPtViDzh6Ecez/iQGV3cfki31QiZu7erWXL3U3yOnFdQ1hupu3jIcM60yeixQyrWLO1 gfqlFOqwllKjCjwWzhKGbRfjJv6uTRMvWaxx80OO++SFa4FWV/PR9Yq+qmnFxiA/uWlIMjubo9zF +lXATn8NAl4MfZe3aaCyW+WfbOBPILAz4Y42kt7aYCgHe2AXV5zasR3fM8cioQ2O1bzQEGhf+ix8 hzE+IH7kYI9PZnT6KLv/OdzxfHyIx19ov5gN69Sg8WFdOaKKAS62X4QPfSYt3vYANix21u5tCCfa l/CM2VpimqU9zPYtijO4Pcc87khoPrqnO9HfHvho/PMWBBsO8cyZSnst8pAsoA8GoNWxMt4D3WBB VbwMUTUujlfN36JciLIJ53vjJiP6Pwt39Tj6CRiWw3KX/PjQZjrcsyuHYtd4jZPjDuJ7nxYUToqX iz97uWfaV3ZURpX1rsQ/DUvfHg/CSVQo8N1CdYzzxUXAjC5J+sasRHZ+KffS8c+2xTSrSPmoq1w5 9ZfiBN6d7wrnbc5ee5i77ivlFaYTld/p8MMMLbOF3HIfyrV3CWt4vc5SrCUhPNOUoSQ/MNabm6IT w7AU4nsm5nwpfYaAckH2FoH9GFLJDV0/XEYgqmHjn2DZi8yTJc/qBnOTpYPKv75ZiUP0IMLrC5Li Ij/fDW7BqrotkYb1qu3p8ndlBI7FNZvAXcjeL2g0eIqi6ej8ORAuDOF2VWT6d9J778RZ/w2BX0Ps a4F5Qm8a5W8jTjhJO4k5FmtewkC+l3qOyEn2sWazTHqf9cK466GWO9rUa72jg3NLMVMOk1fijiN7 gk2vDcYyt1N9uyywnmJuEi15g5Oee6V+zc4Xse/79apH5GrlRTCCzLZWG1Hmynl8qc91X/yN+0V6 SF3Dw4XdcpfC8WrP05qtbC751Q70BymrWz96EJA1nxYRAd0SJKg1cRkhYwREJyJEb83ALX/e0Uoa Ee6nSdyc2VSuQeHqv2KWNx8X6jfiFicyiOu346/TL5VO2oumpy4Wl+3S06/j3EU73LCLJqOLKmi1 +6krztyGBFEIsitqcFoJ1lVvWEp9lT07huT6Eb4r1N+68Pca0yz+eogfDu6+oD7XqeLwlyrYrHUc y7B1PzCcWe7H9YGL88+FNvfz4Wo3bNH9ghPZHnC3XzHIeH2tQoKe1JngdrpEBkzD2furTF8FMo5M hsy+Voh9VE3ZteRqH3sxNhexyGnfziwakFCpv2Z9rhbIXLaoMBejHdIik56btttfs8dVmhHQ0T8M Oct5A4Aq3BMaSMhZadDs1pv2AIaorxAx7VcSuDyaq78kqy/VLC6GuS+tuV+vasDB53QqT3Seieiw BUQ7wzJapjLCLFW/simiR+AI+BdIRAyOi0ttahQo1ZNt1n1y2gzkO8B80zy15ZYIPvyhM9cUV/Z4 v7ojzW/TonJsWVn/bZj+sIQh+Dkc0ltvEEkoZqId3t5xJDdQK1Glo6vWK4X1RpbTp7pVlUQlf9OL Wrsv2Y/zE5O4Eu0BzOKEfFMLnLG0/7NNJ4nVHcghQ99fx/x1OA4SxHjUZnqKC0zUkLIxhhsCHQmK 91ksu8QwAJKZ3NKQoOuME/cAGn17VTCab/m9Iho9sFd/hZ7anfoezb+uVTaBWT0cMapKTIu9LGm5 ei61uTKqzeFA8ytvztsYCO8XwpqLbrQH3URszbE/3smi9xgLBFijv+asd2Xt/RICYYuvgYLsfhXB JDqNJ+MZD5/RRQExH9xZ60vUxz7sXqhElH0byJG6r9X9XUJ/Bon5LWttObnno5wnGQ8MvoHk+qh4 gm+dWI76W7recxycCkaNm4ltuIiH4C5vQBR6WUX1hGVPm+bzgQSR7k3mbbNCPsVm1IaUpfcQ632J d0RnjNFQRsE1BMHPNL0Dpww7CtY1HMZT7RUkiHusQX6ZsitsByu3GwkaVGFYr2ArWCNjLY1Zfwkw G/iIy1JmCNPM2kxtitgbVysPWXf8gRKHwrB6h8iOUMyT15zlUp89u4elLJNbggz29BfTQ5+SgWKN jBU3vRQwhoMhQrzKPhEJKo0rQoI4NMSm/GVDUzo8DoHMqrOFzTUndIvdoK9D9DQdVDVaOiQvy3cb bV+EfK5vX2cFbeUXSflO4y1IiQ4E08PMe8RR4WRqhLpPsK+w6IniRRkMUwxMVq9NyO9DFnr1LeK4 qOgA2m4nEtnR0O+IBHVol8E0RZuu0DkhTHncLdFqh1Mf8k9aeTNXPxglG07vCg+QwNLUDmSPvXTX eCxUXsaFkMu5DSZ8t9CeNX0SwKxbO7xiNuB8V7rZQnhPqyB9B3s4WqCAXT4TmBMasIy/4M+nw/40 1mz5R04pP+LKewZUh8knxu/sD2vFqu8bvzePeGcnlkL3dvPiaR01UT8vHAnSLxhomAB604boMEfW PyCKdHfLG+CXFut4IxqkcO/rRmahx/0nSi6eNofzMI2vpscU35CgJunYvzlveBKpIw7eee8Fh8Nj OZCgMHYgc5byi708ZjdtM8XfgQuWdBS0FaiwyxXXUYHQSSL3WEs9O7sGSWVfpdtHFVHgPNm8oMM7 UG5XLfKOroStQCzLHwqFtiTAYhd/flOqyH88Tp008sP18PFu10y8XRX/3r4Wg/QL266sa2/K3fbb a0WCiDpyYSY0Y1KnRUNrD0m6TRfBKZBoL+2MrHtdHyeyolBQUZAg/8gmqXNPrsoi3cTV0ddAzusW ptNYEar2JXlsjZeRr0BHQzRUh9WG2vFh9uoHL+UAGuP64ZmEFQVtxd2G2NXIH6UDS6ls3rt7aMXP E06mjSyxNmFspaV0pH6VIcUTpqqfTFv87FaZwtoK6LKK1KWGWApkOw35txyJtGINhjgFsRu3D8K7 Pu5C0OJMSA8ePIl4clDVHYShOGTFJorqDckfWDZJ2Y/3SmmxpaG792E08N3AiWCzvzESFDeNmNU8 r8LqsiQ+pXq/Ke/4hBBwy0ueknlc76frHaKtk22JYXKbuV3YTcubetp7SBCeu/uwPwNBj/q6CSm7 kEiXLDjlKMdHv1FwkWdXHZb+ctPdGLdN8rOyMvZtAbTkrv6ukfS1yk2WT4E+Ir2urgl1T8/yS+8p 7qy8ambb0gqdoU6Oa9y8UGPc3o1N5Da/FLxqBx/90FHtXsosqu2ChwMCfy2pXmGPsilc6STUkx7i shSUcE7tHuI9uzxSKC8bea/JpqGu0hjhtb/XbGH6xs43kiSvc+IREpTeD8ksex6CXfJRzyyaIRqT XMsMRc3W11/U5J2zhdPHp+E8r3VZIEL9z094PYzShm/WO2gZwTSZOx7s3IdSeyf+I8NHfMgn+WVT Md2fEGLoiuwo9FfKCfmRB9a0S58zwf31C3oAp0i8OY4NhRzyzQFhswzRX7Vz9atdAh8J6u7zQ4JM mi75xqvPMuGXECQoMKXv8FpK5/XWK4IEoUJ7xPbHr0JKoMca41JA2A2GrKR72yNadJouWO0zfz9g KpqbkoFaCuZsUbO+yS7Yxe5QlUVTyXP371iCEs142xumdlreR5nF//DhIXVn2Scx7UVDbrLNT3Mr Du/4zN8SWkAWt9ibxWQWo1XbdMPxNrCloV58hzHisceZl9t5QuFsuKSeqfDHdoBW0w9VIwK56ahH U/GqGVRrm92AhGS6AipzndpBIx+lCgIgKoqPkjaEfaV32//+AZHGfrehLdbUNj+iYBrY7NxPL9wz z+uXmbwjdvL9jXXdNuyUVt2dXwbeGdPW5k6eA/hx5J0TrXlDgkvTRSySZOS2ev1C46QORm20c87t ZD8pXv8m8Uzt2X1OJvn84h0Z45/HOdwBUHQQNKATylVJTqn0ZEjXKtZ3Ge63TCkmmFPP881RzoP9 FhGQutlcQQzW4IoHvrMMfgGYpBwRsZVKPNkz3Jqwpfrk04tf6vXxu4deqT6E+jMrqURZfXxsCakF L3UiN0ffVFTG/NjWf7sS78OUJksGtkuqlJIVIcnxUBipK2/WpmIcL/YmXUx8zWHwqeH2bJ67TvTF bWBH+BEaSxOT+yJvQP2Ca62rdQCnMe5TY5Ef3XTdx0NW2pwA+SVfhNZ8VMYhxxRgF90IuQZKECao uUwE1oME3fteduUfu2IjwY7zKp2ZL0x/d3LxWF0Wa0PKZHTfECEpGnHljwRtF5mw//211NJzrMuE E/lPQ4CiIDJ12Zvi7dzRgKnM6SNoM3xFtyNpdScHvMR7Tn1UeJGmP7QjOMtljzcyTxZa5iH+8oz8 aD2y/k4+zOAg2bs/OQrq4ZK9yjB4QS0/veLznk1Dzzfmp6FP9vusSNYMOfc5vAMHBNlo/QwVJ1Pr ALG4fP4Z+TFdSuGkvRDvnN4M4+C3bvbpiZjORp0SFYp26oyI3for0c0l5j1mbWh+jrd+qQqt4Wni ccZagLyiifFHuEXlWw7f79mSV/if4b0BByOBVTObc2yDVWoE6XnOdyGtptfA2brrKR/8yZ2pHPCG w5AKYc4zHvrL4S/iNsI3zxzjwrVi7YxiDR6HzgVJGB5ghG6m3x3hmFV6m+fCP+vWAi/Xr9qGkNff vd9NfRVlmS447Ropwib6YHGu3vdFYFLy0nJkW6ftr4qTazdsyFCDWW1y+/PnGd3tbaiFso2W0cEM l5X9hDFD83sZVNqnFbqiEuLzhtPlxxqCiNvoQ1ggAv0uCW1P7+NwcudlbgE8XiixlDp3ILi/7Dem 7h6yz4nG4YMOu0YucAlYhj7Y5ksZV3Q23je+Px5T1v+MhG6i5wyX3yhJ2e055+xINT+vraXrblcN M1NW5hUET3liKFqiB9hRNuA0i/axZPa8rYV9tlQEz7mE8TZPBAgbbNQ/balMMkw0Um7uWCy8lt7S LsV7LHXMHDuIZuJ44IWQd770UF0b3R2UuVNJ0nIrLEYQN9MTtZ55aQ8eM3+6lfE9f8PfU0V7rD9X /aROWBTQfqe1MXXfGv5qSvfKL++w7J39ZhkmtPtDLnQcmA3RDN52JKgloqAOCGb+ZhoPZiFKBnKX eZuSYHZ78CFNExJU9gpyzKBVuFuOBN2tQ4IuYAlIkLSgUvzElU7s/vIGed7i/DnVccbFVQQSJEP+ ziDwDhBwMhSBjhPQY14V0lcI/CuqE8oNicTK0N3YXE6s1eDrh0X8B1iIRyq6iBqouumD31vvo79s vVx5U/sDl/VX0EeA6fNvqirA+IGsinPvyhdwkD6T+bl6mYUBeFR108kvJKiC0w/qSzRQgQSdbfo3 XW/WYmb/iUdn14Wt5DTDtsCgqmq13q0VThYnRW6VHPxpaTeWbRxBZNj/XeKVu5nFQNwDdtgDddha /ZH2vu5Ld9fA0U/9FuDDn3cbVFeHD8pyN+hJvmNVhw0caOlyNKyuI6x7HuOW66CTjJAommqYevvJ j9Q0DDtaQ+a8EzMGqEp99xadw3Z9DB8EIUHDrHpQUaKnKaRq0PZQ01dHqwbVI2XFPxzLnMwgx706 piv2E59g/Nk1TDSX3VevdMC9+X37T/igHiXf6KKdM0YEsVRPd1GzKufnYiVedwYyvgCljq6D595U HxXQdJkwm4eWGCHQiTaN6/zJEgNmHVXHZpCgAy0gGQOWctAOcrkP7YyDmPaaOsOxECjr1XSM41xH 61tnP4i0+b9COJYqjKfkZrb7AxS/+7bCSUXOq/qJ7J0RvSUd+zrt0NLRUsOr7lFoum1ixfuvqWfg maYFOkFZv4bqVjBhW6xgaV7X2WonlJ7ddaA5kKq85bVCtRW4g+084+K2DV9B+zcbAMFmPJzcTJmK CuYoXv9mMSXACS+qGmq89Stl1VTNZvueuAzx3jla7FhDL4234yAjL6OdKIYahqLU6lPh+PrRgvvg jvfjEf54WTAHrOrQ7zV7z4WogL1btbXWwIBFDLeqUCdFUN6TfB1MBVnRB5BSWRw82lfQwju2TceE uVxZeZk+Gux9OI0FWRl0DC6hpnypld6TwatusoME4Ya2Nc0DNt/UdGUHWVTz9ro8g56dIUElUqeQ X3REA7tiTA15C03wIA+ii3MkaFKnFEDXmft7Z7tI0B6Q1BjUmhLATLpaxxIMJ6iUlC6n+x3eL4N/ hn7/7hYlwY6/qdlw/OD6IWzyDUy7LiFrY3jd1Hhv4/Xem8eNEMuqyoLSnmwccUIXMaKnxS7EWyrf HK18mwUvzgRWrfuWBfkr5tzm2xzgkEEYSB2FnrtCSEwV1KMG/fSMLsmlXHuOuCFHEsrxD171KkRF iYZTCkxdFB4pDFehT/tYOIteKN6qPiIP9dhfbx1/lJCb8wwJGmBiv0CLvLZEDcASTVIBVz76wCIs Qqtb+30/tO2LdZ/ft6bZFEi/NjOMOxdcUzAXexaSsSk1Tne3RdnvqitueuviQ2bH12wv7OMYK8Bu n3DTeqfToo+VNi08enBUJgfk9px5gNUZ/ELADCCLSptI0PHtWiSo8XZc4pFDqdOhLhJU/QRHgsG7 BPB5UmsHJMhX4PrnD7jMgWE8tGqVapsE0tpAIoG3sbB6QrNGF5QJTLzdtil2vfDbOaeci77YFda3 9QOshppNV7Wx99M60++/J74YXYejqjT1kU/D745wO1fNyux4pVBQVlMePbPu+r5rXxW6WBZmBmBj K463iMtyRFX1pw0DnTf9U4EZjg79PN/JzBXpXgzG4DvZvyiS1sofrghwiMvsvaP0GZ0uc/wtrG7x 8YOfin4fyUKseuytFikvoV7nAezDmzZiRlx8X2/7H3+ITToRp9EYyuPZuu06/RnSWQ/+uGEXFmDu Zuvogyfjhu4m14bxTK0Z4dGzBcEX4w9Uvp9tULOHtgNOUSLKbzvgoK6ymTwHi48rZsN+tYve49AZ 394vU/h03nxhHWc8O96ip8g0rBcnf2b54sEWNkI7gbulxFzxsGyH1rPb/Ir1zs/vfDOPHNXztsJC l4VKQ0k3x+LB2hxNIyNlB3nqbJ62Os2nTHKC75Eg7HqFb1NjAMh0xEYkDu3HtrcfnfKI+w8jyH6Y WsY3ODUecsoslb1ytmCl/WwQOtIGhrxj+vYr7d0es+2uVbyt3kp9lF5G+3gAuGXWJ3bAwypjnwny s7KkEXdGSGK0uDM9S1gR8UxDlNXiSz3f1bTyEJ2maiQrU5xFuFDcxAJbVILJsvl+qNRXs3G+mdm4 yXkbeBCianwzne6ngPu0eV4Lyoa+mhNEc2SYp6y98l6JEmfTt4MmAn+OUQ9dxROeMaGI9w8uOuna qpfPdSttLgRjIsySPYk51LmNPCy2VN10N20kLGje6XZC5sQfuuPuq75uOnwInS6ECpX5lT5obyKs 3COzm5+i0PVSV1x9edquS0l1gjUWapRNoYr36jRJqPxolHynaT/32PQC2xQJmgdiXPsQYJumskhQ ZhgSdHWcAVfh34KO0YK9zujum6p48yMe7bAjGobPdRkAOou/pfOa0smgS8qd1nu0fdAcTJ5BRe+7 FLe0rv8B31K4M0XO+Bp0uLDS7GYAETMuEnSuq4cEvZkFOvsDYj9S55qseuxD5WvrUhf39kKVVrvx 36ID6+f5EXAw7izAwaSRIMSFKoLpRWxtXjulcAvT/Iz3B1uYG0IugBnRZA5QdPiOw1kDKBAhFEDo /Ak9EBSPbRW/16b2tV75cs3PR0cbXxO9AN169fQT2ySC0H2VbHZq25f4MntTWXJBXQF2E2TfXT8V vsdVhAQZNeWXpRVtBdgrvTb6yeU+OfuTddyez4IhfbKUAkHW+RrA83hI0OUmBJZKlNPj9ljiVuJH nTOn9VfqJtN/nkPw38/xsHjGSQTG7FWX4L41Qs5w/uIEcPnkhtoaCJ43ZltryuHslLFR72HXahyr EcobP5RNY0esnrVvqd7vlYtUrQE9Welc1GXJUP5VAvCvH6H9S779f1L518/9av6MOyUxyNQlcUws D5S7LqpDnY9h7iPVlt9ezcJHmN9ILmf4Hm/tQ2PnDymGmn69yLggLoysE3VxidrKvf8xCQnC6+uA HHW2Ia7AB9kIipRI6Hp0xNUFZNnEWtHgMHvqogS8Kv7gbxvk4dzcZEAwoSG6PIZ21v+IFFEL0Ik9 TH/37/CylKXNlyiSP1dVASx4dSnjfBmw0cBY2NDf9Snjz4rRAmtnw/M+QVsPD+ThB5+B8CwPt3OG GaczI0HpOpCzDSQo2semSLuK+nnSbhS7+Sa7AXMOtHX7AAI/LL+htgFETC5Bz1ctbkSMpw0ZXlJ6 8p4KXNLFAeIqgJT4qLfrDx2tXyFB60mxN0o6y9J13gmdGN72lYdzDZACQ2QHXw8x9q/St6+lN5D5 UXoSWaiWb13Id4JJTE1fWkb2mWt4RwGN7pD9L4Kx56uADfpnHJTd2V+Hh41fdZZ2VoXTpRlkL3lH kOsSRarlsrMzANqGxRVDB9hNL1eu37/73dHxpmOpaGRT0c9tb9MpvaZ1a2AgeAx61xo0nQHYkzqe 6GVqfUJnOLsDPyhQEyHYoTWWcXBOdLl8Pqa9oRnNKlDLryQSwzoS6eaXnoIE4QA8z+4CUVj1er5x nD5edUP3EhCCobKBj4/EjBFCgeEfaWjm95O3wDMRiPPrFb5fG/FHjzECsqbKA+iPrh66LkXbJb/N 3Xghha/VRmiAMU5VXHCvGnl+QILABwH22aUcT5yjo4oL+Q3cM8fyc6FLRZf2Xa9uc2ZTdktkGJQA omOyryZuRL8D9pTuJ6Zt59rU23mpT2c0Pai2NVsGXVTaN6CLvCPQGqKrQ2hnucf8y4vOt/scvIZg nlterDuxviE1zhTQkkokyKMp10+Eia/B4Zm5hq7BB2+jJgLRQr6QcgAp4DmbAHN1G3rWcv2D0KLj r/mj1gEEzPmgFDXyssyarqvsKi4ECcqwAZK4v2nNRtyea0CCxDiA9C4c6LnAkj3Z9RlqsdC0PvUw D9awhOGA7XCAuP6VyRnORUR87QKQywVg6Vz4rrYsn6sYPDadpOQ+P42VAla2ZQl8vmgNLOaNmWG9 hK6HZVwBqXj9RWQw9JkZwFMc6/f96Jv7sTAjOmDG04V+q320xfL5H5FVDHQOkIYiCm/st1T0C5Gm sZ6NnG6tmP80SkRW9vZC0q4v5N+y3hvfaSAf3zafOAiIluj6j/xGvjzC7N93m8t/zm02/s5tNsH7 dWKqwEwXQ/eGbpbI0zsD4QMY+Hw2QnDtWB3QT/y/Rb1/0qv/ffVM/0RY9X/oOP4fV2/7v6Rekz8/ LLQIVmdYVzmiMWsROd9vyootMoNV1uAb5s3cXHZO7QG+OAJyhrGG3W/2HXKe8hkmbPxfbkeyFD+W /uff7QOVYcGukKC7ATSIb9c5GO5Z5L5zLBL016gZvm6CBds4OFKUJS8//pdXY5QVZUFoJYbkah5F HsMyBQOmmeqy5INuYTcvL6lLUs/RApndFyTo2+jE+J3FgXO8ssto42hHVYujHyzA7mDy+vpBVqWE A5u9KgwecXUA36JOHUZAgK3AHyraRgqn8uV3gBxYbMV8jWQpa8+tuYifAEClDKft/AESRDFWK7ou sAdDgl7/Mr7jA2t6dYfsq4ijKUJaAwHuzR/d+cvZeAAkmG6VOxjDtZELCTK0PXbeNNb+4xzxC6p0 9s3vCgGBdO+1QKloR8nUTbPTF66TKvwm33eqKXua7CF57T3msmRaN29y6Yhs2T8tH9A8Ke1n1mwe EIroB1TakfD/6y+B//VyAgk2PRTYgpysIkEVJX6r3uA/lvjwZokP62fkD4j4SeFyQG5kdjPNtH9+ 6l765xX/vVImnAfV0qNVjpqKAQ8f19frLb4RqQ7OwVWkpSVkn7L59CHaZtQ970fsG+gi/oH8FV5q NQKlB0HWtB/unY0I+26IBIGAMI17cUZmMVU0dadpSnP7P6alG7GYirUB/wNaaCvVUuwFhaAzHC0B zv5r20891k48E2qr+kUCCB8v+DvAx1x28zAs5uv3A7GtIyEbRqNN+4Sq+2Vl5Tty4vmnwVe5Et3n eAjiATLoYE0RdIE2Y1EHskh4ALnCmyq7lkF+8gmD0xZ3l4ZBZHmdc+jQFH53DnDFj37aSFCzCKQ1 FiZTDzig9CkQjINcoWEB1rKmY6sTsSV95YfW/zEt2DDF7GKmDswEbb2zBL2gqDKFoyfAAaN+8RDY JY657Zqutdcdc1c/qfEkumaKCF1UJZEqKOr7aKeQRtR/Woq1HrnV9Nkj9gJjDnB7IOjinjmxNB8X xQgpf1xcE3HnHQ0onq0sX4RMiHZdoZZB99qgYeC/Off7ipVLSZeIaJLowrpoUj5/93eUyvYf7ZZ2 77nXNaNFJaD5XrHPuIizNBcURCUuLI2tytzNxWF1EycSQvQ3AckAeyywW7UmXPIByMq/FLI3CShz XMqy1Ci1v8N8OnkcOJpuf/UOigRJ6IKvN9ow8CSQWh2tPr/ZJnVzEWSBZNCixKYPEVXW6ROb4wV+ NOI5W5knvBn7JXsV34F9LgNxXppAlhFmrhmWP+LlZtl1a6nE4oegitCFirScssjkEx4dPnmlvKuk fOhA9MDVhfN+mWZzduSUmIgSK5enp7xgAVkKm1j1JbsaoC5NxuXx/KLReKT7nadLhhaEKX70KMGT aLTup2VeHZR0SdPBvbaL7GxDCY40Gj+2hjP4IiWAZOSFBZAZZXJ9BNZw4NoEecuggxQAu2bra2u1 QBtUD95gn79o2/aEFgMwLA7MjwT9PRFkkXK8aQMvH7oANIUF8AZvAOtFFmB+SnSS3nTIsMYqxr2E OmOTCkSG6mt6a/i9OXpAJl02ILMMMElMrMxstJ+fE+q+NY3ZAUlgEyng6DDZesDoJcXlkSAU0xsT MmwHH6ONQPfJAQUaM5uPgT7JwYgKXYQsLIMbuMe5RHSBsgWB4QIpnPy/lnFtFTbgX4LQFdNXR1h/ ac/93Z7sf2fJVRWu+RcvSQdUIi8RLU3vus0tUhRZLaDxT9m/PWDWwo3VXF09GfsRQOgK29H9w+// 5IUfyAKcjEN/uW77AxAJ2wuYmg2TUei1L2cjiPeAUDnYUIgEXfuvqf6QPOCBEv9/ZMr438H01n+V Kari/wVNw2F/MEVh/Kc1/efn9E9M/zOa/heZeue1lGDp/qxXhHJ9zJ0zkBtL014PfkPa4I0eU7Xj rq6nlfa+9IdvglsKP5Bl5dP/595X+j+siPz5Ycu/9f/x/t9dUJCT//BzJjefcPzf+dlEbjk+el6+ /23fSeTl/W/8UOLfffeD928/u/lvfymRn+fPX0rM1Td2pu0i8adoRn6O9QqumTlPR8FHS7Z8qLTQ /PnditRp2ysxRfTHdDJ0dzbm8wp999yV7QrQUKVWvpuoqqp6eKgMHG5P1+2M1o12fL28+FXhXD09 2hFxYnm2tu3vdnk5ed41fTI5UHSm+6BoZ3RtLc25NqWs8dePQLigx96eqgl+gOJHP+hhq/Z416BP ygVxrb2YArz0iNfrB9GV2kNT1wx7XUNwxEzYx+O7HhTM3NQS6GLNWqYPHyxQyEkcz3n8CJur4kIf r5O0WLfLuEW3ItHyPHOZOGLO/NNAQLDjcUMCK5Pg286J8YkaNd8X1E93P+wZ4Qe4UuZKpM2vfKMD m42O+IJXcVDqokBUMrMdahoZxE+xA9rHBY/DUCgCd6hvyypgV+iTlbDhRqyXH8lsJ3St1USB7Uz9 181JaBwbjgLQXu6rF31+YWGqaYqSI0PmrRchIcrvFG63TfPeLFGEL583MveISvOsEzRu/aynT9f+ g2rumUF40X1VyBcCXHZUW8qa4G8+md1wwhqiCUxiLMnlU0wx5rEJ8XhDHmkTPvmI90EHWE+x8N7u 2WpYZFz9uLvOHAMi+jn9mek2WoIkJWdnJkPAZcsZmpqiNiWBUthAYASjCyZCYn2uDbxgRV9DQhjY RZDSHJFd3naksfrMBRUrmKBkGSEm50hPRI421iXs1u+NIi/JI9mvPR8RQqJh/hVj4CBooU3YgipK LERKPac/GstUJKKzPJj0qS8KpEEhTP3HEhdWc8vjlvopAQon8acurmnFjLDvn8tSOhU5uBjbO+ay Md9ofG67+4OFLeY+sRhehwXFDPXSkSXWPqNjco8XFMVVRzCHBfRItIHC8JtRQUie1eh7zxm9Tx8T jR26sVjusGFIKjNGpW5pPbYzfqFExu/0yoPszlkXbXAXiRiXSs6jfBJDAoZQjKePeMI6QDkf5FaS z44p1TOt8IjZrwzIX3S/uYcbt3pLSw6/1aH8tTB+ACZZ9+1PYZh37sre8bkdJKOp/zn183MeNspg qb6gqRcOb2b6sb8ZFAst4moR6se3v9NKKw5gAqUJdq9RYGwLY77DW8cSM/PRwADRfQkzFWDMp5QP G6c+pyLGOuhcC6cvsA8RkozICUjXxw+lz5xBCQnaUXJWj9Swj0xYDm0d8U0UHsQeKqBu8TLN+cZr +G0IvfbNykhaP8nhCyk1yZ56aQeFpwt6uYJkrvSLBWIXHUNmhjI636z4ZGXpX0Zl04d8sqIRbHpp qDTHSG0mbEP6mTK7yvceYcfbNzjJZiw/P7fgYEpyS91nuVdLi8XU+lARE/uJf0uC0uidxJPb8tEr jSqjDSt9FjsGr5YqA4tLvdkElImUMgQx7Fx3cmoZoVhljyk4UE8PWUIG/UglHMrfPI5M8X50yEP5 oULh3aVdLYWWBIq8Ejbql/i2FrPvIyZjVlTRpH1CZhRxEwfZhDotb7WqOw7R7qNSPyf+kI8dbcnw ZOOxPXXVQTcaht5T3JHpMuENo7NQ1Ox1ITqhlmTqnEjJ6K3IoBZd3UJyfTpVZGE7ybtkxuUwSqZD +5B9ZkE8B6H6CdwXZdG/nil8FxUMtg3XCGKKsTTKYRPZYcH/KSX1tPRFik+4NgcmKiVIgIE6wmy6 M90lqouxyopuv0Qd91DhmN5cP4s00puMpPL1LRKHF6AviROpzd/pqYcoafA/6YnRD66iX0jLTptL O6JZYxX5+bPJKt+93YvKomjKiPGlSy63gJLxVrTg/S8L9gW3vkXc2s9S0cAZJM7NosbvxWpPGQbF WFO4v9zv9sKuO6XYXEhlv9unTt2PLUm8VfGAS9hSMOT0hw7No7pu0TLRZJLHzx6YfyCNxaeD6FTS Y8FIC2hh1CC59FaVAHWLXcxwrkW24sC1iDsyz4v5RNlo71sJY/a+zRkjnXuJ+eZrlQHiC5vflxq0 Qu3RypjiQpVQ7iS8wnEcCb5JErOKD6g76uQ9hwK4Qq0qZvd88JdH7nff9vhftH1VcCRbkqWwxMzM jClmZiyVmJmZmZmZmZkZSowlhhKrxMzM0r7XPT3zXndP765Nz0eGpcXNG+HX0/OmuR+PcxA1IZqg gixTWssaSfr4b4H2/GWkHHCjGqAQZH3KXNSIgWUXY5ag4uP0S3DaB0DMvxZSvbj1Z35x3iQyex9d reJChOSNgTAdluxAHXlIM8Ur9VAmw4Tvk1EjTLdXuNOKqGbO2nJvWEwcdc9sZ0BQQcbz5KbKrj4l SwdDYzWMFhTgH6WMc2bFj2CNGa2vdyxQYTJsK2JxT9TdQxNXGSyZZZW7faSqjYdjOyA8T1FFRlmN t8I+RVaS5IjZoewS6Dxan9VZyCRFVWFWEBcsqWqAG6UskDQqAsYO4ks25lkNtAotC4ERkeXwlt0C 4RMUQkmTUvczIKZxnymm1mBIbkcDhGjAUqR/yy7itksoh9dfwjTmkZmKIkHYhUVmoWJdzuxVnTbG FmUArrCKwWOwhqJQNYnGBg9IRv8GdoVSK/7bLz3s0JyRp7FGNp6d7C3D7w3qLfWQgmHKx077dGpz G+joy5uwkHtNcA2L5DCnQ8CaZfMajW2N8OPuWCR7pKrq4/h8R5tazsHQQAPdxfO2jzq66vh82zKt /MDOl9jO8X3z/rpz2us3j3QMS+be2PObx4s3WwqGbv7WMBd7UhZUyA/CGPZIm+GWq6hYbSoui5xV l83PIOmnie/v+yadG1rT2huuhJyAfcSyQRwTDOVfLUWePjShJfIFv/2Hmmjxez++KLPLLA6Ljsmj /zpnO24Q9o0j8wkV6vH05XgRLX9xdj+Bu4IBjpl0dsznUqnlv3tHde7f3jUV7h9TH1avtW3RerRx fLbrIztEtzoRRzDli4x+NdAZVmPSAJge4c6gk/GgSBTPEchllmYKc+7OcLDwmgK82jQavhzE7Z/f Uj728bv4tjvp24+cVT8d41lajRM08iFTyGtZpdDT0+PXLLFLH5qOx9CROZ2ncaxg8DF9F8hRn3Ov 78jIHBp3z5joaL+sS294qhveW/lJ6O4MvXWOnzxJZ2Jzwan71XlQbLOK02v6jOetr44D1SGzM3ah tHzb12iUxcfDpVqeXcQWvglzYR9vmE08MMxT0FF8G0fY26pilL8q5bYBy9md6wdvRytH8YpvKj1W ZPNMR2ePtnYV3MyhdP4RMg9TtPmT4zHuVEBT7xtnxi3emNGB1fnWyTZBNROOwoJ0UPi5bWRxZaQv STywBSZG7cEB+sZcbCSUtr+v0etaghZSKRjZ4+fIU89a6cV086x3o2mFgpU1qmdJxYoUgnUH+VLb iufqOrB30mM2+I07u4fz22j0T5HWdm3fhAw6PoRbnYZfEXJdZ67WImSJB0H8yzAVhQ7YGb9+8MK5 KcF6vVCgv9N8fDJKu7J8PVql4Cta/dSYAu2ujB+QtIWaieByXZmesjy7NHl82FO6hShd3XWEtRZe ccX8/tl/7Wz2XlzA29QMGmX3i1/3qq08Sfz0bfNljB3DDIRc7vAkBgKVnlvcemFXbNCDs+ndS7+7 caf9V7TrmcPssK1622OWy6a+a+Gzlbf7zyUAUQO6PUHmMp/O243NkJBX67xx8tsr3i37ItJE2wga eSiJcHlH30TRwxbsBv3p9nW53UWra1lhqCWPliaCn23QzzJa3S2DGeVR9OTAn5pvej6L4iwQ9J46 CeQ6LK4EzxHxNOuhr+0o4QzD9qZZbu4xGu2y1uyvv6Jeh+13eWNwZqwvurB0I2SzJm74jsFP7fu2 +2PWDgdV1E/i2oW3s9J1cuVKuz/wsC7ADfk0GJ5MBtqngxz6gni06CVr08uHNIoNXXCldjU7ws9T 2Sv4c3g0BKHmF34++BuzH6Pf7rCG5nHHdQ04p77fofeI0t1hlfbxjMK+C6h73Vvl8s1tnjpf1tvf yrdyqJE30tJzN2BhukG+f31l+zHKkBiAKf1sEeg8CAPzcT+FXD8dzya9AY/xabHYIrkBb30oefo8 bGZgOXLm+LaTS2b5yuN3kS5X4d6tly1jSFKHRPMI0rLKLkywMg097AuUhWdTqVB4B849rllyvhMB WwdWBu4DzbxUQDJVX1Ofa0lWoXM7KfRUlAp5+11EiEB5ICvxE1gMwVXun6dI/0CJ/694G5n+jreR VsjWyuj/mbwRwPwv2RsBf2Bv5Ph79kbAPzDg/0v6xr8a9m/icGTn/COH429Df+BwZP+/cjiy/4nD kYnjX3E4Alj+fpX/awkrgxgzIeA/zrEQMgH+95JY1n9jEsv0J2/9ka70v09i2TiY2f+cxFZrryWs iSV4qwZ9AMdOQrEGdYDWw4sv715rseHursye8SzfCsTHdRh2juEn0Km/3mdSoKRSx4EXnG9EJ+OI qCir6MiZGCvrb/o4cmz4qtnKDanqfn8/cNKwvVi1vp5fc30t9f3u/bhf7v26+7L7buPdsXnZ/dHx 9NC5iWH7+eSq6sXT7aOc3Je+s3uqWqFSzBq8WHFX4lZEgPsLbfV4DlVK1VgZo2PRWBHDWXH1B4ZY +lynwe2LMoqU4RGExdmJkHLNgpuFVCm0qFIFVRTUUW5YcoX0IbShs2TTap6hobf59d64QFMLPV0i tjKbyIlSuVV+GYzBIqK4CsYPbKdY1+g7aV/zZ38zbUWLcV6kgR8ogUdLDzxgqlwGsyzGeUvNVKA5 sDqVYvnRs/Ab/m3l6TA7mR0LyXTZJRSwhZUdsHcCPUibIpXJX7gzMigTUh2O1Ng7lEilRLUEwlgk yQajJZIxl8BzeHjBp5XujEB5Feb91eYvWZLz2mtL8imQQRAU52km1GGq9YlNxzPClMDbzSmTPhQV Pgc5JddXfDzQ3m3MPFg8v9GXSbjD5RhUEu5wj8ZQlr3rUTbTfb/gFvEMzS/PJ/kt9zJnFDf0wIKV UaUtlEpFA1xqSw4X0YDCzHRfkEkyWaPCAL3Hy/ojIcOHg14ybvd2uQw+ZasReZ9I1dtlQGuMvLHk jA5ib/tjkmeb8wTqIoeWS6AZKRltkcc54HHpCc8aQ1rBxoTxwgnLG6UUqYg2FoTjCG+Ak7fIlg/O ga6UohcSi7q3aPO4OU2nWOdhG46Ojp6FQwxtLMZoB/yKo7n7EKoCd6E/EVc3G6NEaEG1t15B5cZg 3FMkveg4KEfy5boDkVsgz3i74k7IcosmL2yFPlnIqB4yg1sLcrOY5hthttFbLGHjte32r88YzlOF FfywlUx2NpWU1Q/flQrDgeBvYPEzwYvH0JS1xWGTMviZkOZt2ged0MJVFzrj9L2AQndxIUmNpLmQ qjB2kXXP5Nj0Cbc8UK1BAIunHkfdmEvjNJxflw1RNNCkxFzNJCZ7Jq7SwgUGiEAWd9h6xVWiIGQi tii/2jB6Zo/mWvYkQgaLf0GKEGWQR/5Qav9ZmeTdA5zEf2sw/RqRkBGPFhThOBIXr4gV+Auv6gTh NVSZ/ywS0rYMmVqZeltIHOQRxJESrMQMDDA+VJ9SMiE9CRcXuTXNSG04+xYCVl09S4ZhKIkyZl4w RgidcBNz3hz91RMLncWY3RmRWIrQpMkZ5KuEGGy4G9CD2gGKvFiJmEdfmhwjGj1oVmii2UD3MEqy j2RhrwM2cp0+5gecPk4bK1plf/hPs2FCdJD6iOUCtxRSjy9KYUFw2Z2sX8HUMQkDZ2DmlM+2BCi/ BFcMSExgl+H7tbA0lHwCrWrFv8Q+oRUIGZKyuD9Q9aNEnS8z6PcEsc44inrF3xOjggerM+tiWzCh FvRiSg7sOJMcnK1Qhjv28SLjFskQDeGgG8Lh1IiU4S9bZvz6nEFjZWaBAXMRpley1zMmSgBVrjJL KQxksRoaBhPJc1cbQu8DwNlU+1WcVZAW9/JvOQ+9rUb4CyaCueOuuScTF/mVImKColmOHGk47in6 DxlCBgan6EV5TfcS4g24+bmaqakSbyNNxiVQTrZYsEjn3IG8EraKCZDWkmQ2MBK12espQVWw6zW4 Q9Ow1WXlmd7A44hAGgGTysLoxpsnYh67nm7vCzwL2MLt2m8hWiMVrNDKbh2DQuUj9gd/beRYWQPN GlYBXoENG5uQ1TMokk0xBZm4yyEBq5Ml2TQwgIYmuvraizTk/mVBLC0CKFSkWN9UL8xsi8mKFk5I AnjYIsQjDW4fOflKuqYffxQoRi3QZC8WKF6kP/s7St3tGyqX26DElxI4WLERFsVhU7ZvRQr4BQ12 hiaRvDPIXH39OMNukVYgM6REoNviWSmImCXQ61ej6BLAGkxEU6tVj2GVsJrAvxDeCZn9POOZ8IQD yOFQtjRgEA3zfo7K96KYImUtEOVwuLnwtI8uWDyYw6uzymOvoMNRtsfkHxXpMfgn0jB5NnBQeJxs ZSw7Bwn2isIbx+jRQMrMS8ToqUb+Gv0iYRBjsoM3wCK70U4I7Ce7ONsF5hOl7+i8AOWPf4N+gyKO aUimTzHqMGpjASCAu+6IaLQFbSVc6WcHpyTyyPBDMxhpM4qX+2lFBy/LGRxMhKTHxZSlETYGQTnM 1YAHl7gb7E/yGiS8JOGRZaSV7dmbOFOfRtSFvGsBb4docaVtoCfRtxXQFMOopPoUe04aOihXj21J RH4JwUKkCwoYIZbuz7sj+rlZpiodIvKxQw0fUbQ09S2bJbAQO2wT6krlSkfV8deQ4/b6ILg6CNJg ojDX5tAEkE3eyNQ8nPQmDtQZbHKe6FF9l4Rd/gnQlFuMQUwecp0f5FeM7h3R5GStH4bUVoCWnZmd ZnStWmD8HFyEwSKwuVxVq2qZiWealzlcXEp1p2hCIBUPFkoVkTnA8Xy9OduVAgBYBG/LCHybm6Pz TpqZKNXRznbO/9A4cUAqPINcCD/487xzqfaXT21EidujP4iAwuxnBTGhziqxnkJxpGsRikbPYoPP 0Goz9cfTy0959s0NAtXW+0kT51PbHNXJSSRfXNXtAx9nS9uHSk3HxsLcyPOTxVnDecW5y1ga33lo 4HdHjfdKt8fUpdqPKzmOk+evX/Xwbq/nZePzz92HA4Z08+g+rkDpBphpHm0fS+c/AK1ul8FgIg3h eX4MJQJN5Z1EziG84u1I6TIyHsbkKYZOJsRDawSAYAKfz8PLCGp9lMrMyB9FM+eijEaMbuKLrk+Y /O8YlveXlZp0HSt1NhLwojYqETxAjdivfLnopKXnoimjZEJLJ9qebl2b5wQqRhwEfX2pE3Fq7gmx Q9amxYU11PW7w4ppi9l+xCSlkLnbRWJaEqv7zhVxxEdJDwQ0rrcULz2Xka6Vmsobb49SnCd+Wofv HqI59cW+U8Hm9BNA4VmSnM8VFUr39+3k9CwlaBhDFcbzZStEKKuXj1uvQJpUo5Xyab3anQmlpaYv gZu858e1hp60YV0dz0AV8W85H1w3C613q7+scgg0487lbNtIPABkXRRjeKpSY2vWkSYLlQns3Ix1 2uU11y9pmUilpIkrI4qjTf3I1gVTCIPY001DdZ9fmPgKYzcOIq8Atlh9esck2kMvFCpWeT0Vjop1 qU2SceUJv0aRu5XHafsyJdd4lpLQjqCW8vXZfP04e2s+2Q/7IlT5I4cF9aMXQ6HOp9lh5VzbyTMa Y4rGPCD8hXAQGHFSKqaeWb/paJiT4a0fmFERlCOno7U+Bc/lu2bm2njd31IvJcytc8WDvEex2Q6y AoFOM56grKDxt/T0xrCl9TFbBZ5n1TGNWurO2n4klGu3oO5ZcL1JKQquGmQYczWp/ZQ/+0FjsJhQ zmJacmMrwAClMAsCXh4nLKakGc1yPNPtcz+9idYZz6qzOJylLlUIJ7brkBSFbvlie/gRO2gzK/LV tt0q0tLMAoLGksDDOz0DX/KzdSl783aHqOEnHVlXJG/OUrM9AYOd+2FptKkXvruTEDWb68q+byF+ J8clb232VGJlj+x8gJ/zUUF43qK6rImDQnz6QUyloOStYUrLMLYDlmaOJQySdQAZeayqC1M2vGRD XrDHmBEIeVh9SCYTjBp+ZfmZ0hQTA56xzrzWuN3TUZPGwdw430BEeW37N5lXeSnS+0k8xmt88h/+ 3yedCelS4UzcUEjyefnqz61WDdZ8hAxAvEooGmjP+yIASZooGJuzl6n62w2BhSmnmUZ1+/Ax2AA6 BIxJqfFFHZHxD2lsP1bvxFbNGozhycEPDhyNx3wLXTspinCkmzaKo/14ZvInTRuksI4wDQ7QpJxm SXMk/stFHgECtUf5SnpZFHT5c6QqY/vcwROtVRqITStQ1P6BpOhKyWJeggNm2JBGnfqNgCorUJvO BbvYng4jj18MYWQ9WRhWsJ1Ns21a+clv3GbXXn0Jx1WAKHZ7W84khSAmxVX1JIB7kv2yuM2XJMAt ZeJX3XgTIU8sY+hhUHAwNfThQCFR7otncH2eIPPddFat4BsFoVfDlJTWnyir9/53BM/fjPzfHeD5 BYHOD0SAg73P3O0e2L19WFYfDmra+NFP5e36WWlP+U43u3aTrwK93N67pc/XQCx77RohEhvuxp1F Qw4GmOL1x5lYqM7B1hskekX3i4zpaQ1T89OjGlYi1wNGY4rbDOPzBcBLO03KWW3vXCpAL3iJBPeX WZz890IXf55vo0jK9i9mgozfM9RtFWLekQxVTW0slSpvvCvP6BKIGl+EDOAHPrcZjVzGDjS4qXVc RjQL1EyzHW5q1kB48VTljn4DueYpWjoVltY2uzDgZ9HA4PYYXdgqos8MIy2N0vHyZ9cnmeBvhsD+ Sg1nCHm8aMDs92PMcU479ejwWRnONo0iuoFT27htEW+eD69tcc6YV437R66wvr/+a5rKt2Wa68Q2 B3s/czvLxZGXOrTv9y8bkRqSEKXcyLKtmLJWx2pe6Ha4XGSN7cabFKrvbqF6XpSMU4rEM+/bH3fB 72464qMS2uyHg8iYfhA0e6qF74OJuam+675s3DV3WOdW6w3M9uNXX/QIWs+S29AUdVGUZdaG7LhF d59pVyTv1FgoHzRPktAV4mHtwQLP4zIAYbXXAdXxzKY75gmcvtKwh5HUHLNIB+3jpCv+j3a7KQwS DZbc1lnyDflsyXM+8zT5KCGXRvZn42VUiBiV3biriY6GYiusLG2BiKIlb25RXW6N/FaxDON49a5I WrABOEnO7l2PWju4O8AGdRzvMePfQRd4brX8EJjcIHweDak7t49QRW/avvIkuYmChV3Egl7c4I4I YWZ+VeU9l24oNXUa9n3cs2c8Ic3nysc1ijxpYR5BFXTo7+/GedAy1B+C5GQwwEyWRP7Rt8NtNdVU OkRkCyZ+zs02r8EDdguVVScpk0D+LVeGANriE07BpdkSUfw0Ws66nad8R9gFilm+qkWhABncI2ll x7iFewVIvlN4uF/tZzBsDpA8rWZdn09VRl3ygBeu1gCfnUymLoZHloWE2VIpyFzhOgbjyKm/vaoB cxH3fNNBhLte5a8Myu0N2y/LZ7DMpvjwPzOKvNnWtyHL5c0LDe46HM1+Unx0bsvP7h/EWJomZMeY rwrzmwbdcrdtG7b0k3IvSacFl5dDWf+ibc/LffBUEIyKW9t5TyUaea4k9QSTfxUHydZ6akX9EE40 PaR96/R6avWXrUP4tOF7o1hYmqAseSehoWu1U8hQITIPtKqwYlk8gbK2LfyRk28Kfe82CwFX8uYA dc4E0LTkG0GGewtIo1sTiRwsjd4xtAKcX/rnqZYC8z/HnaNTZCfYJAZcctlOo4MftWWjrr8ojX1b P5JmNk/otvZcThucYYsJlZkJzkatuyqt8gI4q3dNB1OcWg7nllvPzN3edfHSRMuc/6TZUx5zOPZP rcI9h1Bx567Khmv0R7Anw7N5eCViseakwmRMfuUycfRGeUqTX1+panzFMmX3kup2dfEdWjE8seyP NPdVo9LoxKt3yx5/tPPitHYz+TZuod4liu56l6ChwmzNozg+pzYr3nQmuBj0nNBswYKc3KZ9Ipjl se8Sa5G0i3Ed6onLIYsx76MTrVybjldiMRdFp5SwMnm8PZ7G5qiVcDJTI1wAh2G2anVGOlA90IB1 BWgz4QpsEomDqAiJrdNhKdPnTKUJGTMOIePZcbtOSlmM4TSI3TgKcqvSaPB77Lqccg4/i3MA6Fu4 gTrp0ozrhxIGLd+E7CDXN1juOm+Y8GfpLMvAYLcbBBn4YUM8m5tMRqEEEJFNYZu4tjCWJAORVDY/ Umho5xW0+VogmN8ba9nbgwPBRDfj3mAhpRbn8lYEemJ9deThmGuDdY6bTwXcD3l17fJn7o4Trbdl modNqDNipCWmpApTlUwlM/gHW5aQsDsfLIKQ93wPiGTmOyfR7Z5tbDLVp98bwJ3qXasvQjsY0BLy FsWFOn9Uk3nv/1l4ZpJU78DmPobYJnKguMpBSB8TmjO9PPLeRYp/8tuWzhKa6ol03u8mAae0egF+ HYdAw7CD4KpeQV6c3E/CgBhrWG7AXmQA69OujUvXSpEI32gKIN3QGaak25sw+nYKXNCQFjgeYLEC KRb84TAqwF2dLEEmTW2F0FgKaU/fnTO6XR9pbJbtDNGbqFvGu7aBHmNe6OHpotmZwh0lLWZXwWJ6 sCb+800u/D6LOWfN1qU2mknpnGHsVLFHeVYV9XA29KUc4j5/oa9cVVU6iUwFPvwZ1XdOED+8klmD s24hZdmXJlSxQTvZZBS+2AhXFaCMQTT8YwpvhGSlUJjsinFZFjddfMpnt49eycauOmTHcYNC73rx bU8Pw+a3ZHzG7aJd6wu747YfwJ4etV89Wr0EiKMSjuqcvQH/RoFvVhwfUjfYvCLzUTvaiefYqxG/ 0vJSXOks9ToAvikLp2LVUPST0XVrZidPgAeVZm7hFhxCU/otIiPcE8+djuHnkmWOUCT8hnzsOOIs UblXx9xGUuTqAUYt8qtDk+mxFG9ijV78zNJ1WDDNsZSMtyws4Dy27dyOIz+KF313MwEGGnUomAy5 1qJGXalEpoRHVyFGzEcyXUYeZ7rKZQOr2spa2yFEf1qB/gvq6YY5B0xK9OOTX1A6bLz2wY7YndCi /ZitVCef0W5Xal57menltBlFvLsNkj+OF7k1Xug6/qG7JphlhQ+F8spUBr6+tqJiBruCF0LfxEhT O/Okdl2EZzti1ZsoCT/RgZxU4ukU83DY/cySjvyGOR9rK8X6FdlEUG47c43iqlfE8tagqEgn7dLw +boU2TmYTO6ww14bwcfMpVQXXotbKhVKKoO9LmuO1E6gt79bI/7ZsTc3GB7fcqCj+DeWMymk2foK S7EgZUNfG24olLUHRYiXZ2VY3y3SYwP0sUyehN1dhgFeIG22W4mcr7rp+kKvpvRrhDeXnvJaCSB7 sSAVSempeOBK0qZClV/WT2LMweucve2Zt/f94C4HxEl3iG5gmkJ6ruqCnLutCL6tksGw0EPT4Qje 2q8HsdG3PvHNj6tWVkAFJvaX4/5Mc940zvqxJPpNHfUy1zNqOQaC9Ef7TU+zFwoj98Hzxg+L4eu9 V6Dvu+XUzJQroeUUe0s8DCXvNLZA2S2vHM/fjbrHeWoF+yjwt8BzVMchRNAni4YfLIRWqylK8mbp mHxEK5Sul8ATADedx2/3fqJVoCmVUJfM5QkPHIitVabPLTJCnWsIxXb81S5Tr7refFdkn+OmOjt+ YyyOcsmbbwseK+vXCkmcq46biszdpv1uDGibzJ07noBn1s1I821taRU/MT58ZPZ3Z2OlDxHR9Wnp HeJLSfpMmm6feMauI2LYijIirAI3QbRkhmdag1h+/tJvq3uM7y6b+DA3uMWvgS/tfuPsrgkxO97D +VZgZLEU2EyaMed2ZiY7pqo8VmNJ1SmIqRZ7LwpQ0nFM5q6CZMxrcb9kZGMWiTg1fMUy+TFms2Zd IHD5YrkFV+B2fmE14/V0Iu5fdwnJOA9HhhxJHBXjcfHtafNUj2hTUUGLGZecHeDKhPMbYtqzOELW rDl1EtCecTiy1DD33nrXpDcGoj9unSYR8I0EL3h9ptU6mX9EqaxX8denZXvWwlkFwWIIjYBeqUKP 3WCNFF0X3+jAO0yszACaDlrsLeEf7SvPEtRaXJFXada4YcxP1Vc3r76n7IOfSK4PpkqEjj8Z79t1 hNYVqD3xc+KxvvV1l93mjzedTebiYakByrx2ROCPW6m157/qAF28Tj8M7n+nPs55bSecNHaQTIDl ffaA9m096R9RvEKKF4zGqFm7ZQ8p4QYGJshtynLS5d7xR8haoKLiy+gnYtgaEE4StuogufbyxXlF b4XbHV6/oOcTw7mnahW0cW+Wrnn0MnobtyEDHXwn/qgPlz7WlnnxD10mqDFCsUeJaAkixfnImvNh xdeGeYr6FuhZ5dZD5zNMGjC6MyPb5+KILXdUiJEyG9NzO//R9aM26DnLcWLs8DX/VGeCDka6SByo 5CdH1Bklb7VbbXhs63LMFf7nN3i5Nt+Ogekh/jBp59vcO1O+apsSj0hO3+MHpeE8UIgP+uApW/l7 trNn4czxKI6S8yq3OAkY5sXUCTUwMQaJxty9W/VJ2escZXqPpJKqSOeCHOtZ3fo1yWDn8rJrdxQB VRuXT/mGYfem7tf06l6dxSegk+aruXGukv25lCwWP38V0rOBj/Sskk+v+LRzbOLXBqakiYu0pyAY 9stry/EAI9kseMQHvZ1SiLdX8BHaoenFtnDsDmtByhRtu3GsqdLuFjq5JwJRefUWMoXv2/B55eSZ PIVcP8ucfKz7huu5BTujILmX/VE3048vGkE9TeAOH7hik8J10cRj1dz0EzCwyJxemuE3a3DR7x4O lLpMG+lyin7Fwj/PQOQ+1oWzBEe+Mx84GVyHSzIn1PEtgu8afHBk7V96k1oZXSp862UlKj7neGqq ePWqgZgvhZgqk6ed5i0RlK5peJrHt/I+2NBjHL/wcFO8spSjgHnjEcMBfsDP+AytZWxdaL3JRpRz JVS7fbv2gznArEZqWZ3KUXcR17lx5uouwPJC86S0yVuLMr2ywrqTd8WoD4IaTbEZ0JPJVdUe/pzZ nPdftFyHvdQ+JMGhAkkTGeijWEYVoyJDCqAig2RSfoXp4K4XlGAPVlIpvy7n9dIrbw11GYECeUh7 6iJwxhwSgvRi92N8PannJo8NHi/9mGLp4Zsq3vtuVm+fYeWLZzwNQ39fh2ztakjIVINwemaKuD+q sV64zhl6FZT6WL0OFZSymlJd/tQEjcQHd4OGDp1ylUKq/GgzlNCvvH4R9/Qy49B2vbxcVzBEGY8Y r3eakaezhw+VvsRjHURXCioXEnEEFvJj5/W7Wqqaa5LXpLSKsmFbHGHrBesI+rWYXV2af8tsjvju 3qZa3BCU6/i1WwR5F7oCs0XMAbY/92eL9StQtom6QWL9uNXe6Jek0bBJXjKTCaIS8HWeR3WgwAso b0npNxKhVz9+qCz++YbERgMF90NrecR4O0fRLtnAy2r4Qxa911Ybi7cVUJynz+m4B/sW2Gd+cR/k 638O3v5fRPd+OzD+F2Kr6G5tYPsHqT1JI2MbJ3MndzqJ/4BBjfRtnH7/pCMh4K86e0q2yjbmv0Np v0OynP8Ayf6nop4mIeAveKM24R9G/6hH9/c2/M1CYUmR30//bijTHxbw22klW3FJEVl9u/+0kkFE lRDAyMj4+6Ciu6OTsfXvYu+EAM6/Qph/RpqZ/iKwzqD6O6oM+Ae7/yh6J+9gZOzwmzco/3YfKkKG b8am5r+52p1S8LcJxr8rzjvb2VkZW/+Owf5JbpzpH/qL/ztQ+j/W/a8B6d+W9ydEmu0PiDQbJ/N/ IdJsv7nhPxFpAADA/K9UBf8KQ7Mx/gGGZvzL1f8y8/cLaxP+ZUzM3Mr4d3T4r8L3f1on4J+t87+L s79TdPwXYcbE9A9h9rdu6j/c/D87FDQJmZj/PsyY/tgX8Hcm/PuijInln0YZ639FGcs/mP1HKP9/ FmX/oMr5L1sf/l1dD/+7ypV/jjjmf/DeP+xs//ZGiP9p+4OgjY2tk+NvMfkfW9//az8E01/31n9P PwTzn5z2R4nT/74fgpWZ808qm25ZQ1rasTgj9d4YeZ+MseMC3NzvvImYMBINuBx+jt764O5xtwKO VOfEGg6NA82FvrmOFaYhG6SZezqnxFBW5iE/N34ql8op+0bV6vDbXPBNYWSeZNrW6Niy3Q6d35S8 2N37vF/FVj7q4qeo8k/xb1QfZHben7x0eNyer52cTPO3nyh+3ogqQphWyDPolqn8XFTSaF9NO8Fn wPWtbLpPnpPdaEqG736w/unSbO1lnPEVR5VOp/voCiMQw6xiTYr1CVR+dUFDWSpdwzkZUKES0i/V 3Ozotm0ZGgPHzdZSjqZhoQsxqqFNgyRaCF+wuFhdnQTFqsS6uCSl+iNjlYqnfXXEJ3vHzctfQVvV koZXUH8/n9DZTBwvoBJPiaWk5amd1Tmv35+/Ej5QiKxsRZSuQ6Xpq5stzcbyqrlMzsBRSXVgDQup lbh6tdNGX9hRofVQypFaa42NvgQ43VWDtUVlgR1GtcUpfPbW2C1VBrY8m9Jq4TEp7K4FAoP5ceUp 9blQtTFmzAHLK5I6iYW6GrZQRf4GS5XEJ1s3W9oXWnhQuHnLq5yW4bPtdT+Kp6FbqiGwIFtzbgkB rwBJS8vaEfiVX9dQB/6e3FHhfX6kQGJfCudSvE/FluCqdjTqFUhqZnRiU4Ky9X3PvatnCSZkRb3E Ha/Y5Tgwu3GD0H6FqnCZJ2FCRLBqDz2b8zjD2VNy6XnxePIp6qYNCGCpyTR3sAHL24kmwbnFYrDw BfGG9CWGMEFCH3LaF2q25Ned+0EJegDxNftBy/+CcXkG4hZRIKw9L6Lr+DkjKNlKHwLma17idrwc 1gceSqlpOQikBe1EeWQOHiEMiTkpMJsGXvrl3QkTLqudzuNml0CvHZM1iBIW0tWCzmzbLh/ttknH QM5kHSAjC1locwVBaK2B7Ae7fbUgmQWd0PEjgEwI9QJ3d5R6KpYPJIbODpcLmEypOa0CC5FWrOkr OSOmnjmZ/GDK4tkssUAhbdRywyYm+PA3skgBozZMKBJqJGMAzBpLcyjVFh0LM55bEKLyYLo/HhcU jBgKObxIOqRe7xwhmyAOGDsvSFUIZuYR9Fc2HcpwujE2nYNjPTUGBL6HSCAVry9poGs4XXpuCeB6 PG4wvl/jxIYa0e47Yp5YZgIfhvewSZSWws3h3CTa5OcjS5BQ4i70QAKPoTeJUYOrJeUiGEC0K5F2 6kLqpQqQ3JYEMZdeymqiwfAgHW6iD1HegiBIoNuXaUZDCEPwNLexkTlp88d4biByMzhY3YINO0bL voJlXI9BCmhjUGC/Bv/q38uO+4IIv4wJK2ZtyDMLT0TcN69mEEKIu0gJAJVhCJIqhJwpNhQWNyNL Avab7+6VlF60HjzNxuNIuI2pqgnuZhm20dQAxOZiqk5AazshCOUCwM0crCjsJd/YNHjwGCFnxpXA CpbinxiHBBjDu5tCyeBlgxoxvr50RHeZknrBfosAGIymYLLNVuWsjy/DBtYZLmNP9M+5vFWSqgAK E9vgZvn1iNUG2EAomIRG6pBkJORO98pxvuET9iKiiDq/DbAlLDmTRNQf2kiwkcP/hKTptzBSpYTt qpgZJrwVfrAdsm+SOQwaBrU+Cqud6NdkY6Zla8pDQ++OVaMQ0mBQR2G714PuFQFEBdZFuJIEAXMx ht3TTUrzC/8IMQMjBFpsosSVyWI7CGKxya5jfffTJSkSiG3Cp5yAOU4j5Gj4qqFOhCQT9MWIsp5F kD26N6w/LS88agjMn3qkjkHESYZ8j02vJdw+tieYUFgQYw6EcKwbEtotNliKoo+QdBZQAkb7pK4G tSwMaeYfnYiYRygkajATxi/QbfVl10xFsDwYoitw2dgnBW/dkdRtBRpCERQo6K2KBD3J7SfIA3XM IuQZ7W5XchOsMW1luBonwJjxfTAPnMOPQPqgd5oxzxj9ooj+5KgzpALGHlyM/30ggohSDIsb2svh ro61CJCvIXurgeqXZL12xM8Qny1L769BA6CjqkyWBGWgg0jSGDGTNtXEzNxH1Ysts5uVB9UX1oYg RR5BdEkGtY6HADinLQLbad9lJq9vz/C/A40PME1JjpALLW4bFxE04IXY1ZEbikuH2F0xbsBt6gMt SeRTXc2y1FoWvbCJDbdGTaogg8jG3uUV1KHoNAi7T2iNlGgUIENC6HPBbhXYIZ5zokqbOgU80qfk NGXF0JVe6ZHWG+IxF0fsWuTLYKMBUGBAAz3iNHpPv7mF1bjU4cJwk804KGBqJ2Q4Fek+oVGNG8yV YTt+Wr9bqOsVwq3jv0vpBXBrWQ23gSnhzsXjhWEswie4GtF/y+QAU8GQxAM+7gqq9hfPjyYhLhSM VsudYCpyIWmITg6AEXAe7Y7fgv34Au0sQG0OHAVV+ySGrsy2+C1HEWkwLnI2nEKZexvPaWcM3oQ2 ikeHCy2YLrEeApJL3yJvCbg2Y8CJlBdC8Xm5fqdgksjRfdgsyC88Hxyj7ylmvHCZAQTxUhvl/Nh4 xaj9Wz9BenzrsO/tx35k5aXST+VLfmJgJbgPhFCm2nRqJyGsy22UKp21No/9H83lH283Q6GRtpcv K8ae9WnaL5Gl6q6ztwzvtFrrk/TnQx4u5vQqbtobE/R4+J0KyJeXph8GWOBXtZNnBD9fe7q8ri+8 F8wWBvLz/G7C8QnoKwKs9GJalSETLB6MK1359ZB01Fp71G3ZTl/n5rxZEpCLikIctPRVVPq54c1j 5MnQNuZrOl7iPd6vHl5tK8mxPF0j5FQ46lEEZDBCztL2XAelFxUFKDgYE71VE/b7zUo3p5ld67Ws 8I+37i1MgIBd68vCAoc8So6uxrd15b20NoCBYLCxGiq7NejY385b00G+4QMn+5IHfkaGdYIZE0sS cfjpD0rAQAtt8dDrdj+9ElT8RP+RIxLHJbn4iXcnGoRwslr0+DlpOiJKa7ZNW2k/BIQ9YeTbvSXy a/JsSDNtq/bp8BBr8+zB/j6bE4hyEYMydw6/xxz7p9YlG1+Q2Ir88ZRiNo0hojl55VH6wKrcpICg hemwI1vl1jTcxvvogaNQXi4VmrYc4x3vJ90yotqd7pMjg3UKitDypLg+QoAAmPSenkK+IWdymVAU C/TQxOtvX8zaPlUViX3gVrE+iSx6wUbtguVzMPUYC/q46gyJ1tsN2ZSiUn+PTequUs7Lk6pALvGM 7srT+A2zu019evMsPTKaY7fXUO6KSAkd+ZsIk3Yf+gDQGiJ21Hbph0FWsteClHLGxOXAkLGCCpMK uWeMmLSGiWSziJjXM3SHqDMEDawY4shIzYGZaAWiWdZNbMoO2UmTpdr1ROoyDL7tkZ9P3+HYFAJo +xvU8GZLO1UwU8Weyn4g+oDO+JQ2eaX8CDzGohq30eRL6dC5VdZCzAZb3eF5WBUmqhP/eesHnO82 qWou5CTHd5/+wzckPstvdr+6sKvtgIZ3nxCSUF/vw8DQrp+v2j6Ss+2bcBoeOPbsD/MZ7w1//IJK /bZnq81CTclcdeDdYxIJTjCSpPAuRtUd/l3VNVNVoTZL4O3iqJiwdpFAvSQqTNkz7t0wPLRtoPQG K7XKsF2Nsf0Mt+z4B51RIrntFVAyvsj9SPvERfkC5j2nypikpWRhPOGrIr0I3spRFsElAb54z914 JhTHrDzOKr//PDB/6s5YY4j8l7c6skTdmIxQ7kC1KBPZQu8DkpTgsYL0l5PwryUnwUrCZV991O85 e9FbqR4e86mFq3OZKoKaVmLPcOPFtbc0qX5BVHAIFPpiVzslrSWlkvksatobbQJQjBr6K0fao1+f yoYdglsbU7Ck7SEsCqAKupUZ0pA4AVtbmEwvXkz7XegX1KSMtG7KlNPWtXUq+/2rnpMRBtRV0s1v X9VMd0p50n80cLx9B3fsSZJAxU8sGa9VY3TsbAycAoZZKGvgVmEcHx5VX5xRE2ulT52EOci9oshr ydWDvm+46QzkL9VZXPfik3ZcWT52WFlqxJz+jioUTkNNigW1xLcfEM+5F8/nzVr8Yg02unvuJaPA GT3hWcQJNkB18iDHdluQghDrSkNJvXKrbxTj/4ZoIN2N3TCKGqLYXKdJTGugjzh/qPQcTZXUPPTV BdKh2NbPeXIJ9D05hSRmjSF95zb/y8pv5uAfVFLl3Pu7pchyJT6QS4NaBuzVu9p+ekQRTeTj1y/n vSbiG8rRylGOftFny98gftBLRxo/9VV0qvdC3HwCYydV5nZiykXG8AcUtytubY0dlc1tsOx1IW9W LIcuPM6PAj3VYlIHdNIPsdkStXW9FspYxTICptf6U8LPocjlhuRl+ZPJdqsuL9WfeGVJeeLPktYb sTnQx4qRdWF6sgsR5EM74sbF6ItU+JGxp1c4Z66VmM8vvMj3fn3nV7W94L4Y7aYIIZG9G7eQ0xQl Ltej16PecSbu3p9cklYZHiOKVPVf+1TA051SWT9X2XBn3l9kp36VcdHZ07loZ+f+QGUYnrtaqs/q WqlpgK9+mRNZpmjegFLrlJvaaAUfbntNuo9POprl95xpgJjJ12CgIBxD9Es5r9lWehs6tjR+Ku3s 3sttsc4Y3nq+v9LZzX3Q8Hm5WL2OZZQo215C1GQ7eEngXW0lHs6tTlXJiaXT1LENbbN5bsESxxPD yc3ukkZz/NAo54iSv8shZ+pGCES3LcEXG8pakRuSjYA7+aZcvDeJ46myPAYoGPNW1YKk9lRyidXR TtfBa0xfnavklqtNf6LCLWmwNZGRXQv2pT0sFUm2hRS7MEzMzRn3rkikZsR7xVpfgjTNZZU84Mhp KG6oLT/n4NfN+mVCeTasLNv9luRQnvvQGPLTElP00dyAz3qmqK+7mjJyjU3r2626jhiyGuN2fms+ JNUWAg2tUvd0P0jstthKVcgRCUr1yP2T0igq0ZxjRc+2eec+SaOQ4DoGSvLOtVaJKGe5eg6SUcM3 HUkoz1Fgy0WT8XKjnFg22mTx4fGh7AI2z+vT2EEGqVA2qti38CfZIfln2uT3zLNbHvRMWIhm80Qf aqIRphOpB+LPIejtcHrPNJVW4Xj1X0Y/T3g2mlOYM0VUTt63oheO+A2J97Gj6nNZooy9j8+kb99I 9jT8y6X6G2L4uIKFACPccM97uYJmU5ds9JoxGLCy9DipzbDDvLoXVni2K2fKLRLl+KYDKZuHTuMu Yc/PJ8sXPVq6Sp7dMos2tRGZlSGyD9nqv6LvtRbO4VlzCHmTKrx0LIjQLuCaFPfuXyNLkVU56VJ5 ctDKNWJ2CqyGD3JdW56W6onlY0DTNKREhk6Xq3908ksp5csotaCYyomgxaAok/sYvKSfrVHJ8myQ pD8BIKDvk1qy1RdvviiuzmorqNhUGzWQ6d50OJo6rGwIeWp+HaWb6dq0WAUQqCsGR4a+7lswwyhW Kx3FqmoJr+YKrLJmA92dx4oanO6xTdgMhAuZmiJj1DYa3YbnX0fJtg+fqRd1PZ/uz93EzJGodtG3 4NSwX1qoT6A46FqJl7sqblDgrLW6XqfldZxWTu91DnkNkCSQyJTuYT/XPJC8T0RCbH4lx62zdyek S7ViPj9EEY2KspuSmuH6pSvDvWMwktu6fN112YQiaICPz0R/2QohPTA8fn0V++j7WN1CnRNg1t6X wiZDvKvcPjrr8EhtTU5nUIIj/7Bv5PPDyY2b6dKC+mSacmG+CpCcMjbsoOt/NKlK7IHD0EzBzC14 d45UcAh+UURsLY/oTe3zY15zZUF/szZiKXGv22RRRiPpQuBKs3Kb/LRonsHp0EPw9oN57vodz7Yu iGgSN+J0gEg45BDtqMh1OIrL0Rr7+A3X8VqDo2JSRoXjZAYty2d58hCZoqD80EPMJ3J86PhjxMmg PabuAaMVzF23S9dQiKJNCi3c7oOUk1bz+ILestQvY3PUhzYWlr34zFyThj0dRbVUq67VVGX5F7ad ydCi+pSDT2fn7ctLAx57sVVHJviHY6CV4ZRDZcP1w4vLIMLsl4GS9aRnrP7KodRCr2XndZfpl5N9 8hED6s0xEPlHtGnsEa399Ar02xHzhXPjDPNMtotVm+mSFozAkOZ2KXaOohWTdpBw9YzuDV7tzReX djX4zPNrwuN6fLm5Ye+9+btYoXasynl7zS0TR82hyhLuR7Mb5iqOHqFHQT7xHx0MN1/sLrzpM2++ VC2RwpSTgvxYMm2KTK2f54uVHcn1x6EmjLy47nqm6nFydD0RSvFqRnYodonuIKaQkWlczWF26JFc DKf5cgdQxXNtS8E5DGVAxeMQp6mx+dpXxnZ5YTZ3+kMy1rVVs1XWY+O6KDU8N82G/JU/YVp6P2/u ZltvsSDrpGO1uMDhKqBCQqWWIJIsTotfPjN7tExl3BWiXCqUxNDz05JfMDtZu12KdUVierSmY83a a69JbnyJo5wWpoNkLJmo2ceLdMI44z0QNZQd9N469p5dkVgGhOdg2XBiepr6WdClYm7Fna2njYUg OQPDNmHsWuOLvzWdiszMDbCUJxBnMfFGPjnruX0q7uRO1wx0bozE06fs1rFeD7u/qXcy8pObVIMP NoP13UCH4DtBwkYd7JQYvQ7qouxbCl08L+JcF+ytecrl5csxLYU6zciL4TuHtSZAdCUfqLplqV/u mrRsOfpFRvxJEosYyhbm8s6sxy1ecGzEVn1pv6CTm7rT9/1sNBTvba5q4yLl+ECET3JIfoUqef/L pQGXTjiZmjMD+6xZ2ff+bkQ7QUlYUt5c+e/UQRvD+1RNsm+kfPHv+iWrCmud5WDRWwZbYw7PLlyX bJJ6NpY5o0GRZ3XmdSEsuPzGW9Uh3jkMGyBX1z159sODTwo1XrLZoyk1ppV2165lejvbR63i1Li/ MOHP3bGvWoaQZjevJxeeW7lcAgSuX+06Uw0qmD9VSdWngxKc+JzTN9HiL9fIlfd6TvypGIOesi2X mgven461pLBkF7/fOfZmHK6QGcI232JlHJommTNGn1A/t/HIXfRiyN1kb17cY1W58qyxaXsfdTZN CFbPyFFLkR/vr3bNnIuPgQD2tVy6DkjUzbxUAUzutcbtcbUfF0bgdRlBUTnIWQavRNZXBnwqMpma LVW/agx/kpkeaMTfhSIoLuMQhokeZPAH7q28sLrL+qyhxppsmy6hWV+tw0iBX7Lc6LuffYw6r/YR Zb+Vkk45SFB3OEtQuV7dbndNqrpkfzC01RhV1+5y4Ydld6uzccC/Echpk+Pjpkb4bEjMmTiEvjO0 FRqB6vd+AoWNC2f9U8SN6Y+o1t/wBRlzG0uGb8aGTpqEzCwc9KwAQjYWdnoOJkJmdjZ6JmZCNjZG ehZ2bUIGIcXfZqn+Xt1nECNkYRD8W/lX0NDJ3NaGQZFB+Zvk7y9KMycnOy4GBldzS/O/HkStfru8 g62NuaGuoa21tfNvb/R/n+Ooa2Ps5GrrYEn1e0n6j7VhQpY/lYb/iHn979TT/+vBQlZC5v9BPZ2Z +f+vns7M+G+sp7P+0WnMf4T3/kU9nR3A8ud6+nct7ViS1mRvAr0PYV6pyKaSJ3XlSEK/ERTP7zAk giXsPpivgtUq8o/9dM6kzYHPj55Txt5xZPVKiUYYX3i0K6RvbnyyPN0lFztt4UtLQ+8PlN4+Hi+7 ObMXM0fOva+PN84/9lNdW3V1Wi4/uj7emjRzcx46+d/y3T6313Y2Hgm0r5+fHmTbK7Ko+Hq8Cy2a G0pmNKq7qHKuA3c7hbi/MwXP7VdUwWifKitiODc2FDNEMdFcRkyuscs2M33hz6uvhFHuSD5QbHSo +Jr3TVZfZuhDsErpu0MNo0qtQCUcN9tiLW3uWwVIdbWqikS0Biuhs0WxVf4MeBrr1uiJkPrAxXMN 1PsOA54PULWlyqqUvJ6aO+Ooj/WI8L4KPG2GifK2s7UKWi6sbqVYffRszEZ8W3kwzFU0vbO5qtxu +MBRg46yW6/tFk6ThnlD4ayIoM6PesONo+QASrS2PESAJFpYJqEyYw0MnzuPsk7ZlRENT765fNU1 d8k38+NK8yswolFGVh37Ka4ZbCIHF+VAieSkzBKha/nwjz5O0gsr9u/IPTgyCI2hDpLg+6xeEdUg g7FJeJQz3exJqzVdF1xGniP5szOCKXEcXxwx50P7Rp2omKjvK8Buf1XryXSwNAGdn8olxJkXigCd IbCJihHihgVecmxLuVmHP3Or+fM5l4twyEpWO/pkyDPWk18BheQzT5rewNinIVf4KfT1yoLvc7kQ hhSoKpMNbwmcAWBz9FK+VvZXMdobzmiTDbaol+sdo50pQhQGFHQt0xPwdGKMsylFAxiZ0njdvs5Z nw+SXX2pmXmGUascbJ+JbVhIUMixorKzHkLVxGC8ogrrrDG22JJXzfZDaQaX5XvDIcXoEhs4qi7g aka3BGjMs1HlrEZOj0XhZDSXy45k2ppVlQDOkoV7P+mU1FtTFlDRcVP92+zvSCKBm44gdaxYf7EZ JOn9FJrobtYTldTUDg/V69DZHqu1YAG3/MqdCf1ipq1og84/f5gHX2cUzuSFzN7wo6lpMZC/x4Iy ImRSZj5sIosj37/Swh4GhIBcbrdlhzuuzP9ZEHuVaxaSXPfLpogqo/HH10qgdNIUd67Wbzo6rPm6 tWakqFp2JnxKqGk1VUAId+DiFOZwvb2OVLAB8kJw0fAivelMevno29iESLOxM+VgcWUYQPhBej+Y CGsIubhDWpITl7ain0BB2dALOe05yvoR6bz0lqFFuIWpz6mxCOaFpP0N5QERqBYAQ4izwCgw5GeB s/p+ilyZNOy7foB2r1IHrH2OXEH0U4YMyx1MNPI4gFR/APINRw+nnbW4rB+8cjZAkBis7sdygVEK 4ncgalHiEPoNbGoQdLFRIA+FDincLEiyvK8tmGPqKD9pCujEFp9CZw4iFnwDdAHULORB5Ax84Dzb y3JvCQ8wVfk50lfgp8aUFaimdF7mFWOEIvEAiYEbZ5SJlUiFgFs/T0Tc4qi4neiw+hK4VMGynGXL jKnPZbQMrIkA/43eYCmoKmIRjq9UEeicXFIDKQYyImATA9T1kOHmTpaiSmiqwUnUz/610ttLKSCw 2MhJ9lanytASgvLAmCholhRHGtJ7islhI0CBoHR6sN2mZnFyel0FrmYaqsTbwJNpCZR0LRZNEvge +d691ViI2851VNIoBTiqAdTJJ7CYbLF1BjTxKPewl3XKiCC0QHNNd8mM1mFIPZryDBQ/VN0swWJp oGZTiDQm5pSYvImJ0EC0yiyQSt08RUvrjYesQgYZHRWhAPPkNMxEJh4MSAHLJem2UIAAIeWxr4NI ZO5ffn6RMfYzLJgLY4YUYXHCAqSEEBURGjYL8E5+aRfBegquDIOA9mNerMN6iydMkGhrdgXqnJCv DzSNMTJbHdRziUqH5ouMZ4q+QU0uxoHR3PFHPxKBsQXbpWuEElKExILl7zP372VR3gkxbQECP4qD klw0+W6qhbZccfS+gMAM2oGRdAyGzMIC29ucQkguUJmeG0cxRkxabshjf3fm5hBf/nNnHrnBIp2l kQ4W0wEv8KjIjCGZVJXRUy0LxsNiG/uMSw/RXkEoHdRKGbgEkAB6dpLHvgxEesCIcglWAnA+rEAE GjTCO0DbGsEEqIbKAXlMaG5RwGMaCvfDjzpM2Jzo8WXsOBcbbYbYAK/MsYN+/XaX5gc3KGc3xpRd MaSBmykFLS0MoseFKYcXtg0aVg/fUmju0MBoVyfP5TRZNBIcVemM4IHMDW8iUbvXpgGCG6zxzAZg /MrY7reIFXKS8Lms4iBzllRWDz945SOEcsuKLE3bgPhlLlTJN1CHDhbqY0cKKmLG0rKcnqWwEDti E3yL7vh7TUqX9AFxe3hlPzIkIkKoU3d0Olp7Pr6mPDuxt62QHkYZKZ1wbLJoQOUP9K2oVMoDoOQg cDG/jqti2gqr0WKeUmJ0Q2koOp1Tv1PWvoGBawlYMgFfnfBm6Pq92jNpaTuBhqMMPyCtY/2vNWFC IzOlKPNWR4V9YJjOYYlkwZdHZ/m6E2D0h0e/ZvxTjRN3paBkUYgQ+n19Xx8mOy+VZlFbESCBRMM/ lRQAOqsFOwVSGK0zUIu1zmo9Duca6Js93rfm19vHbV3lGJn70bpd9JlD8b64qT93zN0NMV73o9XP rhzte7rs3ay4pN4+uu4irQl7P+XGdSPWPr1eD2Jb/QtjEETBFwEEueiiIS276TDovv4tT7uxaiGm KheXvz9PyNnqdhkk8vvzhGEMJXpN5WtE1iG8oeuQ5CiJOunhyZjZ6RLXF9NZ/bGbH1f5lChs7R3t ZTJBNgRgoIHb3Gqb245vdxizJyP70fAdK2E2hKH9e6hgCFtVId21VxVixD8fiGuvkivOLxjWitXf zpNlePFaptc2jtP0QyJNes3XOSgMDvwkuA3nQt+JpOHOKudjcpdGirWzWlbYqlr0WPFan493Q3EB sLjbAPIp2QT1iTCnb1svFXCtTI+9vnhZtA/2vf+Ht3cOsqRd90S70IUudKHLtm3btm3btm0bXbbV ZZurbLtWGfPt882Ne/aZPXPO3Dsx/+QTGbEyn1xPZEa+kT/phiLPvxXr6G5FYiTKWvjhi19Efiim RIHRXOZm8n7j/dHD8R1WgZR767bkvdlXp+IRuK+rmX+5ME8Tu+7V076oab78NMHfxmvDUd718qbI 8Z6uwI3sldKAA+EL6nv5412HBtdr+hPL5wvy7Y22zIwsalSD0EiTs7SbZOPTZW361jYmwI3xePuW Q7ws775x8mXUbNfDCx+VTqX5GdoO9l37bQiyjvuIn/5gUpoaCbaYGZpvpnaEwdnMHunFgmVBNR1b Zi43oy1C2tva/kZ7IeDk9dhkmTfhiqiY9MBDk5iN4pRnardt7UvUABkZ4eiRy9xM6+KnO8uJkLRi lYNWlV6qJI0uvLUqbcuToWiCZ5X5Mc8nT+KNG4eQga/e1EE3SlQCCn9+98QcpUQ5kSZ4xLzhb+fO l6Y22om2HOZ2wtn0sqnPlwyJgfMal7Upz7p9bbY/+om+DULz9TqSXt4FRHa5J30/J7DcU2CpO/b1 uBxv8NscEY4gUp8xX6f9xWlcojS8678dijagC2jUVe4yuANJ3jSXYdLTX45poisF+NQaqkMMDsEe LJszmukHHOWEubb7m+TWp+rr0svwi6Zammu32b9sWnis4IskpljQTIhKwKVx1+Ga94IsoJc+2xdO ea3IWJzegwt08MJCb1ft6qIGEO4CFR6YaSw/BoYNjIvwDUyQamxwa3RoqEjnTuCkBQxUJLq3vrom M+OrQvZCnaQJCr+aVpVw1wc6RNKmG2Nr3Z4//E5O7/aPFgk8LhIwPvSnRppNuKXFsVt8Ih1/oViz yQk85YAoLK/Z1h8YVRNcqVpfunMGl6jsMLFWG53Eex7v+9w2HNEREHmiVpovBBWp64hOmAzsiTM6 ngsywsgSPsvXFWHHo6P+SNQlbDSTm/ljzXRZeRSYQR7KU+6dI6S/Lr4ErIwh/lUNODDATTR9CH0Y YbMI4/Dbm5auVgRU8SQ3WKDPkdo2ijqyt39GYMlKCWOxWNoPTWwGpzm5aTTnGBd5jPISAmrHeRNd nZxx7pkzfPBtouruSXT9m5RxheW4Xj1gvmDnQF7q002nt4wmLX4ctFOcSY9rujYjJPYFp1KPfUME x44z5ucv1YHeRDu4eKbKEyT2N2CLMCDqx7mnpSmpM97Z583Z2e/Qq2fAd+FPf7pXJSs15Wm7dIoU SNOhdeLzWVRyndWsSIe+5JRduR7td829Mt4uz2Crs56KMf/6aZjIUOCM+fOeLlyC+i4T8UkPJ6n0 kl/qlM35o+GKu+anbnu2DIz/YEyZUXaF1LLmPoQAkDEogyCWy+OwPK2TjsjvhKn53Mr5OZddX/W9 iirW2DlV4khSGYQptLToJMFqZJ+Y0oINrn7DQBxrMrYs/YUyjJuVGMyh1iN5Xk/gXDSUyPA2PUCa cX260qHTqT57SMKPQLYFhQP1XOZY0bSk7NweGpiypCH4BhcsY/ymIilQlw2za4fdWozpdnZupsV7 FekCsrdcLBRRrRN8wtlshsblt32aSaU6a8Ez291r/JYGo7xhykKbs34BisJm0ZVBJjwB9zLH7wYW 2uNsMhnm6/MZXSaxaA40bDdYDlqqnSRmBRF5CqJ9ZnIBhqg3ncH4KZUP59y1nUtEVd2hWpyOqtgl tOsELBMin1kxxVn0mmQ/q63r24qojKl6cHsbVmAIG/E0ZrIJKY3DewhiafnCr1hx5Kc0jYu6TiBw x2EpjSWEzAWnyKq+M/HUMJrtTz+y44LdM4mYS9GI6RsCNn0xEi/l71atdd82g7xLK86aklper/cq PgcBSlPMllpWqOVIAIWDn17fbW83WUZ2HMjcuj+3xwXeRe4W9xPsMePOnE5Fh1mqkhagGcCYtIMg +dyzSW1Tn3gnwMShL/c5ZRAadV14YY9xGFkfHb5IQn9AWXRGtcRL9wYVW3eEMCv4QkE6JTLQHbgi QU23amzRJXX/tvJkc3QllBTav6y0NrI6NOffcDfeX3PGQE9kTab+vMNV842KIhOLcHUQe6HUcBL1 eluZTua6Z4Vy9CUlvIVNlCpFnF6/t1k9v8rt130yxq8aeTtjbXSxHFhbO9c6x9MHPV94jZXkto16 K6szKz4JZ3s+nhD+CK9hj2ZSQf5BODqXK9OY0Sk0CcZNk13CNdjO9NMGF6G5MxOSuCmvobkgEbLF aH7HKq7BcxP4W7018ioq23A+j0sLHsI3NFHxDwd2uu+DLVPyYh649kALcKAkUfScuLPs6slc67U3 lefnTYUXCB7IIW7fylrfZl9zpfMy2g13kLbmNPH0PPhPu7HfQ0y3sns9KcidSUTGrKkej27MtWsW XI6+ua2fmDCVB9R2vvuP4+NNWvETw+LfKuiStEDio1RP67Lkv3t8qEgTuz3yT+zutulYcb5wJ5l5 7UO8ZCvHsxXgyMIHe2emlO4jd+fTePcrBP6RyHTu5yO15txE+yXAYaBAIhdNWvTRJd5K1dk9Na10 JUwUd6KDyv3zg9Ns227gsyt7/ILL5c0RitbvbEIzy7WxINL0PZ0Lol8LvSsJ0a3Zgxr3SZr9Kk7b aSMY2HiA4FPQaMKiBqy0aJQoe1GWngDZT2dtjUrbVq9ZmpzLVJymGmm6f+Rwr2rBnqJQyzi0YeEq hAvYCuNWa7jdt/cWG7f3289S68HwRS6CLffDnP4T7m7OSaNvZlAJHaZPxKpbUssbNW1Ducb0JsnY Z9HYVBgHPmxGrZax3d7kUJUhTXSFGRs6CS+fYV9AVIhjckDh/gJPOAJtP9zSr9BR/AVuC9E0Vtul 4lIQNEdpm906/vjnVvlGzcYrPQHZuBaSo4tT41ICAjuNGCP7wFdEU7GCRJ8rw4GWUDfasstb/hDF 1beiYfK6pZ6/asnDwy1vAgVAA2zbjOYsVXxpQKQzg1chYsuhGR5UyyYnhXMZiP9259dp+NVwOefg 8wPLMQ8aL82p9+BgZ7Zh5uUzb6EvYhMVfQmb4Jb6M/yhcvlrEsNjlwrlDsg8WzNJ7JdBXdd9g8K0 Tq17mHw5qTwbfE59PwWpYbSZo8k7Ac4wIkVmwMjD6ojKd8rg9zg5GrKd/uid9TDsmhWnsurEe7E/ VUZ+OZjnd8ZYTFs9dv2NkJuM6NhVzZ3NSzqrluKVCbA+sjzcSxoo9r37/lmnbKgafrt2RDMmvfSD D90qabjRyGb+TLJKxnxfPYsJb6JIRKIy4dZRrrcj/uJIUYgmbXkf3q6hyZGOvaC7SXd8LQIGTVcp IdZyZi0YcSrTNNfcA0sy5vndrAF83O4LcMmN16iV2AVMj32VSl2MkSjbr8zVijHcbOEp5dCJeSXY 6K2PCvtoAM4eA6HL336lmqrqml7Ojl0OmTPXWLW/EPZttqTWsHKbJurgUrX347gl6UlOXC4FP4K0 2Z88+9D2v4xH8Fwr1myQ6MTrEfbv9ms89+QkSQEkOvPo90Z+IhOeBbpsnDTlmfdZGcsQwkqsSc5Y MW4kzqiVUrVT4bLAcqzLSXmiZUxWrwm+kFB9OQkx73vuDp2L3jnE3J8T8zkK0PGCgw8XYgSoUv1R gUQoR8X7UTjK2YGh6vY06P1swhOxtqvtxszu9t2x6a4kItgVb7K5+4kZAJfo8bCQtI5QBYvuvlTB Cod6H3ZpX2mrfjwhAqznrpFYm64eZ8R9yGSi4svRIVtU2zMVfJNp9WK4Hx3f0PHy/QEhIcS4fHGH Z9dvxMBupfguHGWrCJiyP1D+dHvp2y7nzwZLdVIlzszOfa3RvT6UDE8ucksKmJcqdF3OqOoygVsY qZ81y4O2fRwITTX+3rkhGThi9lyS6x5Nv7uvzJGUJl2ZgBOiqdtZyGhiBbVt5DwMBEyPzj3jpM8/ pfsm5WYGQ9T8eqtKk6sZ7IYN6ff94/YDpUSbs1QDWvKVHdh+3sHX+shdBfWxViNYs4zWU47g1r3l 4hWf+GwKHJwJSpYBsHqBJbo1iTa9VJI2GHPkXdm7O+FYMHEmGJGhwt0lFGvs33d0YsbIOZ3WqBC3 Us4L0Q3YtBrfbpV0vsW6f7n1z9fN9pgG9RCUimnVoKFRz1CznB0Y20znY9ulkm3CT2S+6+YZCjBY AK/NzE9oCwiuUzqbDrsCk+DVhhtpZgYWBm9t14JahPg1GaaPaRPuwCRpbRLl2A+9bYWpxhTciN+z 3g9xXpj5N2gPRJmINERlOgwTvBPvJ3GbKWY0p+PcZXlLmKX038tlOTDJF9FL7bgcEtTikuc5NHkr ly1x1SA4aJdroS9FNwx9VkS3bclEID4YPZ5Xx8S0pjWmcGt3jqk3zB3nYvYICPh3tqrWPYXiuF9w am54atpW3j69AS0/TQJFlCyCDyE9L0zW5ETmltl2ZCTFoMFIHTy7Z/DQdtUUM9vWnj/FebMaDMMU JnaUbTLnlzTpjiheqkFq5zmCwW382ma2Z5eLMLwNyVl8KJPqQVF4U9DZJvIGk4oKoC81bAs6KlGV wqqz5sLPDWYsOSF3BB0nBV0td++VoC8R6PeRAMaZZgdRVhJ0+5Lt6M92myqJMcTjBKBPu5x51s0Q E3bBcJ22H2zfbDuS0CV4eNrBqwDS7n7PjBup2E17RZ2pI6ch43XNJEV4bD4BerHp8JDJ67BP1LS+ 3hrXobPup8KtFtnEXHPOnaPlZPsXJQNtrN40lFfUWvHzdzhl6cx6V25Kxf2AL1CHoZ+q/xKKYPpP RBn/7NzI8h+dG/8WB/yXvRuZ/vu3/X/t3cjA9v96N/7t9/dP39H/pcfk/9y78b9f2r/UMdAwMP5r JQM9+39JycDAzsb6/0PJwMLA9m+98BmYWDj+R/9Gpn+vRvlX8BAHIy07Ez4DPQstAz4zIwMtG8df E+OgZWP5H9Ghv/7aX0ew0KlraOKz/tWL9a8p/vWrf8J4WP+p+f9N88j/B+P5P6ejYPq3s+Azsf1d /jdVFUz/J10m2f5prP81l0k2VmaGf0aBmnW04rBGUnzZdr5m6WAmrZmVV6rpYIT8TUbWqONlQGFG gy4hI4UkwMxDx+P312u3r7nKOjorxgi9kmVArVanKpTKZHO8cih73l9v7Z9suzmU9XyAd+cDBt0v dd3Vvu4vpk+nZWl2vm9NPi+twLfOMOCu7dPNmQrwdd2uIs3vlVf5+knPV6EWsFPxVzXgbLyraSCt yq68uiW86Rx/LWVs0V3SMVk3XXJWWan13lSusVWjVc6i6z25/bP7vQNQw8jyuTPWkcKSwmBr8jrO 0cgYGxNzqkqwI9L449sF1OqLp8nsAmslqk23DoZFpCxPpmfvmbeJdidoxTQblRHV/iYlOneISpF9 0O4/xBVCvQ26+CAGC98E9mbh2JsMUPwLnajiarlaLSPsJ2pl4gQCkGYvUKJ6kKlht97Gl31RqEln DKw3qzW1NJpueNY1jdR4wqHQdciawPXXQ1QgBTH1A9J0uu9EsZ4kVXrPQMDl4PKSF93vbEywnHGw gtpa/lBqBCw9pcBdjo/TY9Oo9ye0yM7e5TNjZmQ6N+YTrrTaqsIvfBsSyGfvxryWsJrEjVrfgz6f v6E4hGb+5AcUfM+Ms55/UTGC9L/Aewa/0/fwio740yehj44RLe7V39Kss5QveRIs2kwdYnPBLzGL 8dAq09jgD+mInFBKxvGMQ7bB2RMdA7fVmvPtdwwCZPiSz9CLBjeQ5UXevu/Z3fZZ2lsAHtKYn2Fh LcXqNrhktoVma/97RNwwXOifpO+MCJGz9nvTrhcDwz2QclBlrTtyVNIhZaWIW4dgJ/kyfzx06HxA lkEhifSDIsF7f4t5nK5F9Id8Z/A1IQBTV7QPA8nVVWeI9G/89StKw96yb6YFLKDRZCHF+ykvP1sS TuMX+KCjJtVG/y5AdnSBhdCJcT/X8Azg2gd3DpLqioPiD4t4sxiV/YMMmBKWat7sgEcutmXvq010 Uw+J19pNTyIPTK+IwqYWfuAvLaH3nxfNHdVaRioM87fUQqgn0k4BPY5IDMNX1M4OR0yYbUkPqT1X AVPUb56dAs4SGSsI8TrlC9EZClj0D/5RkMVAtz7Fz5LHMratgXJvVlkDJ69rsBImqSdrliG6h8W3 JvoZ0x/yDYs3KEPr0c1d4LYY9dttnebzQCgxZW53/srTgRwkt7iddI1r4ZknQXUQLtKmWXtkDSqS /GYAOPwCig+Mwi8bmUPj58LDec1w9vLdLkQL8N51VeYau186tT86SJKUtpm9+zl3/0ALChQIrsVH CIzIOsOhcJAb/PY4+JlnmYOpGmIEsVTOD55+OwYdFKpLVmEf0Gp+p5sMwY5tvU+PXq/iQYijeRgc OojE2FQ4YElk/O1UpCCRvP8EdNWBoAoxBQSCzOcPGU6zLU3l1ls5EYfd0pnqYtrQqo4Y5dFdkaNI 5ez5Hf8DhZK+TCyOMO1Yb3NKii0DVFtaKVTkVsXewC8txqQdKU/3uwIlV9tgiiyVMs+ZiGf29F/H wfE4HqsUGlhnuuOmWFiQkdUD1NwWI3GG6iHRAgctS8AAUlAWb5oL4ZhZJetgssFS4N2iWBIkan44 dKHq17PmRUf1dwbBq6J6B05lGk1E5SLX7/07aguulMYyTZ851NgUC5AK+zQW6KN6GCFkNkcn1uq7 qvLPuh452PMshiwCCxCZoNaG5MPV5imksNSwpUEQtzJid445c+OtkuD238pPd9nZc1iPwJmugsyt asB6VFIDPYmB+f2YCpw1KLx3/AB3BcJ0KGhxhUIrUPrmOkQso0BZFlQ48C5sMfV4cxbSRZudNc1D 3DyAaigorTKMvkQ/oZI+8KT8gRC2kNhzPJkepge1GnwrCErdIAufsC8UASVBgOwc5HDCFj+2BC1Z kf2O61fn5AxyH49YP6XX3J/Bb7CCH9YpaNFVFZDrWDjVqC33yfeyk4zxtw+ki06FY/kvCgXfnfz9 uFkgeyBAeKrt6XwVZporIzrIa1LnZ4AFI7OYkhggzd4/tA2uy4eFlzQTVwZAjNdrFoBWwg2NYyRV yxHSUWNnxvM7abFgkbX7VceGXghZV79WcRURnXMK+yE6QLLFeUX35b+X05wJSOMUw+m36a5MRV1C +c+4fDsUyEAAr1NKhXP/fRYGgBcCl09qMBoSBK+iT8OyCgMRpIktrYsj8RCi2Wp1Yuwps3Y1RBD3 TIcsigk6IcHbNAJwujYTpuzYk0/6gwSy2n73ghdZweC/4S0/lxjXuOSIhCSJ8K/WlCza11TIIKY0 FsUBg/SLV9dfGrpF0PYpxsbhIqpCaWLgV2TRUOlVV0unjpMYsJpcsdNUk4PE8qm76Kgxlj6Jzd8k T9NP+eZ0ULT3vVmrnosR7VYGFLxSrQQ+ADYmvHogEjSLP1Y5kLOAl0WK+VIWsKyLTUtv6Q9U+X58 A03J7K/0GzWfoZ5ShkYgRU2vYlc52Kg8CqS4oAK+0O1bcYGrfZDR4o4JPWB1AZ1NP1CXmaWNzV+P Juz09wOo+BK5/kA+TZ8jS7KCCUhZYQgJ6C3YAFEIDMjgmzwVDxZ0FjcRyftYODfiF/Cvl5f7S87v 17MpLnT/iuGv+vwmqxpLLwUMuzrScF2uGF2M9uWlvJ73vbBKu+vHFbbNpaPX0nbPjqvax/e6Xtva qxq796Wr12Ednh0XFy8f5JvVnzS3n58d7QBLsHents/fnvd8er63I2yRc/5i/kIgB8jcvm0VP2y0 AO56zdXpmfstS3hfgfhdCK29WzjwnW+KJ7wIY1BlxcE/oump6PaqhULvlSSycA3Uut+xbl8n2Pw+ WyqS6iHRIajBRZYEhYWCQeZ0Ejpa6KnBkuOB5HMz8llHfV8OPkaXS2FW+3Wqz8cJViR5kfz54/iI yPFnEB0oArpA0/uBpY4NmWCuU1WpMLcVtuGgrP6l2pVhbRu72gmhKJgl0+dt5G3g57dkK5Gejhac MpOLpaeVzzMtftr+cxJ8yV3EBB+RraOysA+DD0Qon8HjcIwej7eseUg8v669+E6xSH+owSBmy5ot 29vdAc5Hn5HrJpDO8f24lUga3pqZeS5azAtLrrolUzc/uVT3PXthZyJ8eLCtwFDZ/YW2is68lwS9 baT2ESQFZoSpYS8Fy/WIr8RmGqQseIusVh3kmfWEzF7tLHugQAIRlmq6/AQaqSJdzSP7io0FknKD PDAKoYiJza7S8Jbn9iX1Kxq7Pg7GFTPZLTFUi7nqCYnI1GY70eBx3dJv8xRcjvo8Ooa2PqbkkRN1 IcywV/U9tThv/BSPQGr7W9jXkB+d844oQ9L3/YWIpQL19NQDZ/iDpikJD++XHJ4C9zF64xpEZPG3 19aimjJn1kY2lzwXmpoe0RcLJcT1PBEsFC+LwaxHTHOFEwTi9iYoojZ6AjHfxk/w5GW7oialkpta 2BcsRJTS+BGdZl/O8DYnHGcJRlIAfxELKOEj9wyfKKiyiNDDcFMTqPbigevORABU6WS68p59EGPf IMTy841zJ04KiDNY/kbqkgTCJg8kEeNdLu+EeAGZ5RX0jWnrXy9Ohla3/KEBz+xlXS2WIn+4TDPw FrwxmvFzfrIwPNxITpBYnZWD8CspGywJRhIbEcusrXDYGloa1I3+GomSRyvxyxEQ4CWRdq7BVHLv 2A+nBEwK68H7GX9C2WBtxLuou1dJY89oqQpq0jtEugI8aN0HXOI3QCk/U+nvUeqWSerErrO4zuvg EVkHKReZMjRi0Ma2hS5H0dqZEUBajH9xYONwmkvnShv3eTP/HTqbVpabV+wbSnvVKXFH54FfRP9T 0It28U21OzLHe9kHtyN79V2GtTB+pgutY1Jassry4+VoeqvgYGJmZ/XJ51LUEg4Tf92vNXWxmsP9 ipOspklJmkwUpZtjAO4QXim2H3OM8ej9t8EcOP4G2jR1cpu3NQJxCJOIw93hwonOqeZZzwcWMWD/ Us/U0rIN0IHtpCqqhVQJr/AQfr1BcKd0FXZEmUB6TtBJ0FXqrH9uSLuJv8dC1WfL+Y7gUeEWLsrZ IsWFqvBAAe21/9zK1Gclbl3hAAnPeNCItIAImMRPw8Jboi+fmLnWNxL4w+fGUBtaB0gaBX8ke+sr htVZjZuBtnZ1OmLhPPxod11I5dqfNcEdb/oHHKKCKL9OiPRQD+6XVJOl5qv9mLyGswLshKF1xqPS dr710xJxsRNn9OJv0fZNPhLqwmLNOE1ukm38zYyN/ZJV4AJh5zT6laCyjrNA6FJ9Qy/PXTNh4xp3 DC1Fk9AcQRK3D4ShLbuuL5oshpg5SpucxMxkbVXs5b0EstUA9vjtGY4Ghtfw+CyyhZnqcF4ro0Wa VJPsek9BJm2oWakKSjuUJxUlow0lDDqGILi1Uvx+fz/nGsoY/3TX4SIFxWl3IYxh8RYhGF71ejls 4UqnbxuPmXtGhJ0sv2QQbdLbHJJNRuPcMnUeg/hxyBJczoGmpOl725dF2ULfgOUrNsCxLMmExGar HRuteVKC2IYp56Ul3aquAzHJVbl+3Q+pdBVqisws/wRSfRNDN5QG04WpoSquKzVtuz1pDU1Mjfvy TUWn9XGpYTHm+WitrxcVg0uegDYToVVcJuNd/z0kKYjiB5nqPgbTQ8N9kgHP76i3uTcUV1Uzd6Tk kXNWT8T1qV1ZaznYPZCdocBg/VkbwB8ed+/iaZn3xDEZn9rTlU2OkL5C5KsQWf60Swh60CAKiTcK uacA6g+8Id/qMjCGrGD1G4lvgwh81qKbFLnrwhVL5aafVbLO3q8uimtGvH6aaXPdyCxoRsmBP+G4 TgVjDw5cbcR2gvKQwKBBvwrAG3LodEWP5dGEfDc9s4FYsF9yaenfE4KmlsXW7u154vW/QPHMcB8H kgew+HKm4PLWKiiMf+xUKlnInfAIWTQiFeW50FrCkbsb3bVkUTRSfmXfVZP4Dc7qN+wk2idtnC+4 OnccWwzr3V/s2QCz4lvr2rqTv5uMDmHbW4Q12B5PeA4kjl71b+kcQCyXZCRjNeTTanfTDjtfVn1h XP+o55GxBLQk4xjsLnTZYNRkbpPYaBi41FwmxJ3LPrc5NGYukQPrOO0ZYYRcqfkzmmllRbqPqy5X Slqq7HV+oJEmvie36HTtm6qHr1Jjk5tvigBcR9FFVTVPulxif09i71vHneRVGePHecX1BCDtV07D 1MSt0/U+j/ip/kxqMFfXT6TI1KyY1IhV+Alv1xHsx3eOYzl0T5hYN9zN5KEFfi30yjDHEEYxK8NK IskBR9GtGwpiwTSg+qQvWzoiXI8IUh+GlyzwQ7LptNyWcbTDgTaLgk8Xjc0h5Cyqzi0H7Yl2IPfN BDMvijeX+unKgl6pdWnksm39yWH0MHulEFd56tA4AzXGsNKMjVcoqiGT/dxPlMnTb/GxCuLeBO6I i+OW3rzuqgtiQlMPX2T5URvTXaNi016LGPL1Wvo6NcgGdatEnZsLZpI9y8VhTRmpMNk4Pynwi4Sq j5KXjWi5kZU3835MfJtBKymAL0Gaxp2iJZWz4rfTUROqGy5kTWDjuhloS+kDn1XZxMRLCPi8hBR7 pS3Ci85BT39Fn91YX956U3prt98ebOoRubb+D5c1fdnYTWObIZPNa2OhBwwIiffV0vj0jIswDFjx Mfc6zkSTIQrJOfdfcGGtjr8M55J55CAeGinyWLFtmrDMOMju9ImaqZRCqYfzwB9uOQ+AmJI9HERz CM9MNbWLLWb72So3Bron5ky0GM7dSZY2IU9qFKjP+ZSQX9ypZDQkZRpmkVntHW8pb3fzb48XsQn3 D6OMUE8bDBoTkkxb2PJ1otIi+DmASrtKoLJhx/c/uMMjLNUvR2D3WPNHCk20fDazSHZ4JKVkF50y ZwISH+fi8X3OySY4vZWWuRf56+yLS7IOhmQqf5A/QQ+iP10cQQmzbtaAVrSoFfDo900HycrXdOnn TUCSUtn1hgZhNgIYn6rkMjMfWjuV+RGLC8Eqd1xL1qDARNqQEkduGrAbDQMoufMbfZ3QiHCg3YjU 60cZcKCt4tJaJQ4M4UbC5kBbl+dGwitWriPKWzAIX+wNdTYdoiBvytqHqxj63kYY/cdtpS2tcupt /Ey25shbciINRzLMTWZf4RSseM8tZUT3pvx5y9t3vEEwj5li0zVMcbghxBVe89zSWQkqjkbZTu8k UtPQzKboxuz6+8fBwelgIkWBzAd3Wfb+CsSkkudctFjiD7+211qmwvEgLov1BvVWs3VcB2+9Lf0D inSFbkG0cYgijs4/6S7t8QgTAEUCXuyWn/YO08Hk6pWAA5wVJUQA8poLD2m4yOhj1sifn3HwHKim AOHOUfkN+d9m94qQkn1yBstH4tlZSi7QDIKBSxs8WxFDPHUV9NI8u2k4Uqunm784HA+YDnoqrJTo AOK3MUtG2TCq0ZBIxzYuUurm2r+GiR5QM8Hx4vrKeNDMyoOgHaE+OapGV91m0ZRosFqhNl9w+v1Y hEyNG2dOx/hx+GQQ331yjxOZZjA6jiklPHCpbTq3RiQxE5KrUklUrXv1ovprRvcVDtVaa/8kCcU3 8GaP/XZyms7wlg5w8KdKMLl9EsNa+Y4736iJMbjH+vOnpwnTdIuHtEOWWFBxU97ZXV4kzqtGGFNh ESRmY0smpXhLf6SXgeMo17kWra8ocQsCydaOgVyVYr3QeuSzWdUgudxEY25DZpafAmHg6QO9GSGi jwahIDdFl/FWUJ0XRzJ62e2bvH9xwMuuEAlBXMUpTSMNpvddG9bAiqL4mJWCeZbijsicdUdRCxqS e+TmyKLNe3GJA7O/aS6x+NkF3j34QNCk6ZPDLzGJw+zNN1M4XrsZiTkeWrGZ6pt5SrGt9oUYiqYF VK+EP7QoIlJzKqzjd6/J+CtIxjlRUuNSDKZgY/VJckY+ApnNo7GmKYoFIwhJU0oUvtEoWSRketdt 6oG8YKBsWWeu2FKEHz6at+hg4JvwbTOtB42Mf14gxC3MmnWnROlOOXJXa8y8lRIlcoG5rTS2V5he LZcOH08ZYOVd6RaA5gs0bH4ZL22kjOLTxo2j4u0yHWmiWrzryE+heKdNidqPfPAowfx5V1PaMhwN XSjjxvrUt/oueNJrL9HrlvtSO17tuCWKqF+RuJ4yAtxFzoUoeqYgpV1WFAfpPThWhVK6p/lRZZ5l l+lm4ceCM4NXLYc2rKfheMM+aPA3ndnHGMjzN3uS06B2IZ4QfExFc6/I0e1kSseaX1U5kVsOEHIy G/sGN6bA91xVgjihmGFJ9ALw7qROJMYTtIMA4Z1uVos0tIEbpYxF3Xh0igmW0LduYVttojSeYjDu osQaiwPQxl9ceHeJawxuvSkVWehZpoNc7bIkMZPv0Rs4KdEa05OLfz1MVgdKYo6GumlojRmn4rIM qCce1zNVLyHY8suPgVhP791NLUlZSfMMsjmYVBLCCBDZBukq0ZuDSfv9b0NIdlv9Q2/ZiuJvi0W7 V6pM25uYC/FBUj7aq5donfBorTHuYql4M7biFvnLyXZIikM6UaNVWWMKqZu/B+racdhspYxTKu8a biNNBrrK5g9sJgg6jZZpLagClCu5Wt1EGs8fOlqKtW6NBVL52Mpk0W5cma7WiqGOsQhGAt0qAqVo G7MQf9s/fJCvWQO+r5kCxM/vQEgd3soGCZVir3ypwrRd/Jq1IRfGebwpRjPQ9CTnh4kFHXLiIlwr zI13jNFKjZQXVammC7I9UybsGmTTrG0BroBoz1Ddea9oRnaYp2e0a5iQUAYf3sHGxyvgj2AR5/pJ lWkIKTvG9O2S2yqu7/n3K0Wua6dbqi+iAVkX6Vv7H/E4vur23jLMowrhPduqymEDAolAUo3Czg+C 7V6e3dky+bJ7L7ngO3yJ8I/PcP5WI4N0aUcujB5FhNF1SKw0uEeGRFWamFUUoFThktWRR3hTuHsV H4Dnk3WL3oljd1VyMt3wFqOs6xCi3yzL6gdKjPW8h+svb745VeqVZCqPThxW1FhFDzIVP/aSBo8A 46wYPc5majSFRw0lDoxvI+OnZF6qLyxkoccESY/gk5LaR4mI5oeyW8Uzc4t817KVhx6TGZUWD6Y8 zQMLKT+X+r9QPIp2e5xAvcEzzMQWXmG27GC2OZaZlitLa84XSNBvnY1BP4WhQ+WdMHQahni3yp42 f+/BgJFwb1XLk/+6OobeT+3k0R1H7IhSy3fZ2zSz+YK9DXVlj474drYu2WB1rezF71+ddu+LU4RV u23JVR76emYw8q0ccDLEwKZ4gPLl4Rmuz7YHJpUwdRklCUbq/IFQaesOjc3Xk9Rahzpb6ggUH7r2 TZ3GQ/TmuXXojEvTKzilqzC0y1TQOHtrDVblKShRRgBW8Q+i8VRLu4m4bJ7voKgQLkUrsNxnJtFu pfTbQCiRPjolfX3nNS+5+NxzXa176Iq8vRsHK6uiOLo4XDwC2stL8/piu+uPfG/u2HNH9FHUKCl3 EXBuK+dV9JZJ5BVGfz5DsIs+bTqcSaw+JtKGBJ+N44IeXO5nwVM1jvhKZVsX68AicSF7Iitd6COc lxDtC+a7zgudW4nrUqHP1MuIs9fP1Go1Fa8Jwhqb5wpQ+CjElTGmaJBxG9Jq5o+Wy/4wvRFP1iB5 K8Z2PUh9Qb7DXFG//obniFrgt7QT93W0FPMOnFWO9dN7qX2+RRHde1sxtzzUgaq11Z4n8aZCuLmU memF+GoG3S01abzWDan9Re4FYA+321/ZHl3xRrmpyNL9LqUPiOzW47rEyYYv1inGmrvDgZy9/W6T xE/GmxOIeft2lAK7/JMJmxxht+vxVdvPLZMQbDfUAKUYodTDpcgpMvzoF70BYUBeAq8g4uvwy9tX 3OkI7SZUQhNuKY6pMZQIJTGRXLhDpqBE7JZ0mxFA8Jr2TqRSHuSQPZSckap2BANM8O71ur5LaOhE okoMaEE2nmsJcjcoKTkHb/UjfrhBcVLzw51Fjo+h24257R1KmJe90csUeo+befnIPY+L6eitqxqz TOfQ32/ghVZwtT9gv+QtL4i+Fr+ViVo3/DaIM9D3lZ9Q9fzMk3OJS10LCXhKn80cLmn9JPuJTfIq SyjbPL4d+ow9mHOpEZVJUNOq1LMz3vrX2khmcGD0px2K31qYD6f1CKmWR+OHxvkWfacyU9AfW0NL 42w76UThjy+G3Dxq9T+j09Nyan24JZnI55TTioDnUmtdrbzmpfko1YmTV5HKPi2ye5DKW/vnwpKT TewoxpWBHHhg1SVIAWf4MyRCl97kQyibiRtG/qHiuFeBmXixdC1tYdsv6o16s3bfnfyctmoYjrx2 ITven14vh7GuwzL9L5VncPIOc3/eiWVndu1p0k5UitQcqXqq3GX2tMiuBos2srLd2xgPyTz75qkU g2YoidfHSrZE6ouufDDJgRlXsw65/mqDv6bAoxRCJwbg1706PIhAG5TXPUoPmbVO6hdgN9qNykjt Kpw0tgPYf4a5RPMRD6/KVpzQ5LGgPlNF5A9un4gsDovhp5hXrZ8t5Lu6YcYyWx4NYix/57hIVCcM JjAxOMAORfA2/kFYOrdAIaeufWA9lXEr/6QE4cMXrIzca70HMdAHehIUcXqRrGQ7hiSH5XJPZy5m qxNLKaDh7kNXv3Al8bj+18Ji/Ir9DoH87BZ3njcChWUeqbRCWMwuxByzfyyNq2OVxs4rwX0/t69Q j0EkbgqB+4dP+W/RD3nq4XOPGWlWnMnNYPSXQfO4eU3e42V6vNyAZ7Zgr+a0xcsSzVr0Kx3u5F9F 7/WbK8VXEmGXxwJ+4YwyglZbNCUOMwbGYnPKWhoLIVvx1hlw5tRqle8pYZ93zIetHf2Lsjz+Ws/W zwvUQgr3nTNiCb0dzDIxEgbVDFiLwDB0EqyOzgntug5Zs+6Njz06mOa030PbD+IKqENdSjgUHSL1 xyJTVrsBAzBwy3iiBVpHQ4Mw9Xl8Cbq+Fld3wp7tgmaZ4nvIpMiIPr1e3PSN/nJ+0Rkxl/m9yNuK 96jHKYYr0XOvizrFplwnblAxJ26SsSsB8Mhi1iQyCj3sWn7CtDilB1Z3ZDM7arIyfANLxqG/5cyA 0nJJvVTLZqupcRIan4siAGVkkUyGFzANG4zpW8wO8HmmQKo1ddkE8siqhRKt8v2m57NG+71uCANE uBclDqaHuHbezHkDvB+ar0Gah1yfLz43x4vduM6HTKMz23GMu42llL3AI1SZpRXH7umM35nmrcXl Y22DXxiy8Sxz9wnNPq/OR9jU130MIl3Em19+IizuKv+ajPHv/Qr/BfDPyMhBy86Mz8xAT8vMgM/I xE7L+NceIxMtPev/GvlnpGfCZ/nH2f8j9M/+Txg123/SnomRlumvvsystPQc+IwsjLR/7bDR07Ix /6e8A+Z/OGz+x+Yc/9T8P9HEMrKz0LIz4DNwsNIyMOMzMdLT/nUJf23ZOP5nzVn/l6QHhn9yx2T6 v6ds/f/Ga2D+N07EX3P8uzD9XZj/Lix/l7+pD8x/Ux+Y/zepD8z/JwWwDAz/frjM/zUFLCsHK8t/ 4D5orydisf1bwmYB7hg0i0rbkombISG1nmkXYuO5ztMV96hvvnhLpgHLmm0Dyds124xAwQ9yJJHx NAfpKBFSf2Fd2b823Z97p23dWjWxQ3pfr69R+w7tHdtVUa21dk9xfD09H0CH+9fOw7dLW4+NKze/ N63bo0q6qBW/ry2U6590eslRgIy9jwm0CgUYqx/VS4WMQ0HeuzdaBTm66YKnjgqsIbYPhTaRpTqr DZTRjFHjKJVpdABPg2hvghgdpfJ5GuZcQIhSCBLlEurw4oleeIol6jTK8FnIrGVQbEw1KqrcUiGq 5jo1tUSMZpPg2aLgmqAEWn8VYmwVbTLLCW5vc4/eS/EHmuA5IKTlQgJdNYU+3Ndmp8AVhow601Vh YiZGY9Gd8Vmj+YdNtOsJ/KCNEG2w3alimutuE7cBug5rlCbuAdeulnnzvL6YFDLJnSI8zrkqXXK4 IjQaQqG0osfespTKP1I2KT0qqBTHkqoPJTIfBzV70n4vZvo0V3NHILBLE/EZTAMWMJE4Os2DxVPi s0IFD/MUX9GmRfamQ09T7roTTscuRNrzkQ6b3SOrBcOvCbgK4h+7C5hdFU5nCQBcsDRwOaOKxLRB HBiNd0EBp4mMlMDCX0dUrQhG8yUB308qoBN/ZbREgvL7GSrpCwcT7fXZpdvL6HIZetNVhfO6/CbP bgleZuCLIWOoX77Hh42aZs79Uxs+kFz4g4GSwV4pyhGHM7/gRERnAT0bQY0xmjtCI1IzZVKS1Dba WS1ptQXmkKYb9W1xq1xYAcUG7SdKR5kJVvkwOgMjg9euQP368BzJAZpDyA5dv6bMcaJvckhqdEVf KlINjUy9EwgRL8meLaaszPOCC4J9IWvtWGdv+EHXijmDZ2W+bLUFjajVKunggvIDx3RbiEbWMPhW BeqwpWaQLkPwcy+KCmsOSXMISqyU3Abnc0IKCLMLsa518ztgnjxEhcqwhhNGNb5piYVHuFSLwqMC NYYZZVn40lzyYa4jYKPKGy4P2QVKCpU8iKwjQaW0qDnlRo1GM7xQhGmhJTmjCBnTQUWm9dvN2KDB RmoPERKLoS8hnA0OC2ESXbedpJrh+HOhAi6jwKQHZ6s8ip+lT29KYAK//dZfKw8h/Y4WcNy5NHZO cSwQWA/asfybf+RsQifsSJ/Wyyu1if6dswlOfCLyTS5Yf3yeiBYRByeqJWV/ph/rRgx2VR1jam5X GAXCXMEjlIYAgCFvoebknZHaRIythkBUMjsbnaOfNxoeHw6pH0eS587oa1mIFn3KXdpv4n9vj2Rz YpVdfq3G/IM6jQAEK/TGDny9r5ri94/jalHkIHJwA5R6EYdUQk9QSmFBIbNWiEgEGDBjKE+Bjkh4 +GBC8mQcUcNlfiCmORWR1Qvkv8lhu/QIKJuGw0ojeUncA+txPpAeqdTBeNL609TpBBWq6a3uSgpI iQh+REcwU/vadnOoMUvubuznQsErpsYrYkTWB8Cl6Zaj1K00/fmaTWFmYoQBdyWiVWasUwzf4ydB keHgFB9IZSbFD5wcoNQEN8Lc0ARROa0gLMnU2zlOfAck9uWLBGKPuOqWgFPsUIAO8w8NI+pgifKq KHGL0q8u/NX1GgO9mCh65QYe7lySmDsfQxGpxKJSVOmuEG01rI0FtNA9ZzU5BPpPjFWhZHUgSNSU lHo9yyE4T5TbKgBGgJq/2GKXyhdAKPqypXrjmO9N04u55zD1j5RNi9TSo4eAYPnwHcFN+eyHR0xZ ownMNdjwoUkZmX+kbDKBmKqi/J2ySVgPHtJx9I+UTW4wS2RpEX+hwvl5DChEGu3Q4XnC4F/6VQSL A9bEaeQ8vXuUD/yg7IZwmRF8oMJI0G6PtH3TLxTON/4JsNJY6NGxJqWDZpgU8+U//hGy2SDysylQ tu4mFd0uQeZbpvco//OtLBUUrNJ3W+VRVGEQgJngJMBahaAGqcXSne8haPLbFcm4czA4DSZqXzMq vujfIZuNUKQu4WTwuThytIzNobxT8Uv286Mtxvx55+gRsj8eFZnakRrRopx05XC0YTpl6aHaRuWP wFssfy4wJiKvLunaGYIRMpAx/cY20Cy90r4E+yazPNbF/Y4u5OQyH+GPe4d6i0yGbuTTTxt/GL/J vOXNPHguaboNYUvQEGLnmR98YgK6jMy1lyjCuTSriZ3JGBJCAK3PyZA9jBz1UzzaxZALk3QkJAD5 LViITdwze6aN88mfrMDILvRGMroSYwd/seMMCYzoBwRaoUtwQekgX0sSNhKXCAtrrnoX3mywN9xg tIhqMMGpUEWvQK0qrMT7UApsZOE/QjbtIMRYEHrv+7T6vXQGuqKcDGz3LHvBkcLRwpxV0Jis7MF4 XHNtyT/Gn/tky8FpBOMOCf8smUDalxr+cgJN8f8u7F9aLklbUTVTQikdgmokFZoqaRV3DtdXhDQC Vk8u8KBGoUkVkdFbSDe1gz9WaMUDql9CFmQocsCF6sOZaQqDByT1LwfLpibwhjR7+hiXHjzE3tBy lndYO6hTTCyNiIfc7W33edkDslWYR61zQX8Tofj6XSja1SQSI5JCaytC1uBr8/6KYrXS8Pw2gWZn pmfz8z7LtCVzW7nx2IOLa2fAQHem5R6La33GbtKaTA/t/CUmaYRVfvzp571lyy343TH7V33bR1wa XU8PEPs7769fq4PeXTkoGIA+JlTqJQzA3rnfOCN3o6NfIx/u08/2IS8EJIQx0kDQnnTQudLT0CrG C46xmEFjw3kYpvrouYyIX7W9A78+Xw5b9VBMBk3pOIKJMWS71lx8wkHSYMS1jotpxFVLbBypKcXi 4iS+WHrnPF351ER/Ufnl0v/iM+H641gfy0lhCx5uIqK+UbM1nfpiStOQWq4xBuF2j2Uy9LBxkdau 2DjlmYuX+aKac/P1zTctrKhO2/Moqt2WnqbEbHvm8oLqlGNdb2JJaQMPneOXPbg3ACd24mf/LOTL hgNpb9fb0oQY7yf9QPwb2TNMt5lYoeWjLRHeVZrOOtf7EfRschzfJE/rnQMHxbWshe/PYad2AB93 H1ceAza6Tn2U0U6W9bMF96Pmpt+g2HsXhNP7lcrMKpLM8scg71RK1uaTc5bga81tyNkJ15+nAdsu 2Irpwh6xt9qbMrQjglyqQahTbNYhg61n2ulJA+JGKUbB/pUI8zW2L82qHanTG77Dr01vKj7Y47Ay pqQx9ejt2gjIcUw0VV1SApQ5dKLCuSWNRu+PGF4wVU3DdNkwb/VPz/kH7GmMwdZHSttOFwdpyfMP 8bKL5u0I52bv5LgJtxzgn8FbOpMnKs34yLg3wxfv4heBDt3ZiFy1PQOUzhNN2Ur0qCAEcvORIGC9 U4fNjLm8E7wc8wff1X08ybBqsmREY0caS8lBEvSl5AHFtJCbZk0XFHEmr83PkcuzuvwnY+eiru+D 3T4Eoh8E4d73TUk9QHylWpZRF2tynzykGsCcta6JBdXBrNoUNow9yx7LY7M/c66dN4DGS1pj7iDX E0vDowL3Tzhh0C62ozQ7orolVbgCEjmGw6Mb8h/dxI62jDiFNOuGg8wz54YMVZak+eKlY+E/CBL7 jy/04n31IJG1oNjWbeUOX5cXL/StZBzbHjsC+ktEqPcC6ROZwY+bCGaEeNeX+C4PLgH+2qJ109ak bLk07d1p0W5I53mo7cupv91dTckscsfLPFSmSM7IZ5gWPHTnTwINSJsypOkWAqipgM1BL8H0BXC6 +XcMWWaCpDasoaHaShMo7oCmGSrQyEXQRjFoWIIPfyOSnYCTB1jUFxsowxwZGzcitAvmt499xxUq tTyFmt9Y1Dxi4zZl1oPZ56WHu39UMPtYC7Am9i32c/bYXmeJA12OQporpjpmqaix3i5+/qGV/V7p oM5+wWfvgrF4cpnEsbaPO2y/Sli75TommGZXzr4LFVHIOXXLGOi0gS5O2nCGlAKIOsGQ44ru6N9L jP4V11ThBO2C6oIpcx0jdnZXBCM4vGVjLlDLzs1nE3pKc2wab7PnKlRe/SrOVd+SyFLDeGrvwK0r Um+CHeb1nZtXgPQQP8mFYOwD6T0wa+nMQzwgluPiz1FRHYKDov62DpLG4J6Iar9KxEkOM1fEFlmN 2UjW99eNVMkSj9WLkjs9abNrHu/xvLI9RPWBOKm8UNdOYrGMLjIOYW57utLrVVAzrVzym/czCybr 24dSeRUYFKY/tLSTkzobENDc4tROllBClET6IMQL0aONw+sibQGpneCqe+DKdyItOXvw1hvTVAyN G8ouefv23R42sUGKoaWSx3c33m2MnQni1Wfn4AFIYGPBSIClul93CE6mKL0ULXW5IORslV5tNz1B Kx9eL/Tt+v2pdcaXY6PdelexWjvFeKwal5+w54It1jYRNDJhOVOioDXPqNb3en4UrkH27twp1Bxa +24SGAmeQ+fLx1sV0aGv1w6Gpfb+jinq9RhW54uyENHsV05T9j2buQy1F+yRbxPQchOGtuPEza6N bBrUVrIX1Fmar0UZ50d6axIAZOby6WL0nC8uja3mhK9jVkyuL7lRumc/wSiS88XlueuHQ+OqGeBh JenSi6OgVw5dGE6NT/2DxvKp9vak0LyiiMScxorYyHV9CJ8xb73RT4l4tyuhVoY0YzEf1dBJK8ft kgXiCqyzHZAwsHSNAsiIfaQDkyPIm5b31epuZa7cnd04MAxl6h3YEksHeI8fjJQ/GQH2JpgyxxUH gSlolDauHO3lZNnTNwflbh0bFXTsOtK+EioMl+vW+SYSQoJvImaBfgemgZaUfv5YMUTTpz77nJBA WbeYb/JfzKUfXfpZ64X6h8rzditxUHtmbXv3B4wD6tndZJcrk/PtCmK2jmv08I45nbaf5amJO1mz ny8EeGKf7BvNqC4wZVvlZII9xV5Gf4yFck0jzAS9LtR8fAMcWBmjIhsIWm3rKaVe3x08v6cdAgff sqD/WrSGb71dfr+OG6Pz8JN+Q1V8YdrkxIW1zVk/s/AoxFPyy33SI/Lf+WC4zMPOfbsChSDuTE1w QtO6OLF9vaQBFcMsLnPLBMxZXi3CWKnSsSvn6931L8iM3+0ZzrGm0OmclnhRuIgqCKdU7DN/VyCA bDdeJrFq8VX7JACo61dlhxWlY4lQ3MoveHUes7oJ4fDrgEV5obkt0ObG68WLCL6RmS2Nqedlqeix /J4eQgZQbbIuFNTySHN2TXc7zWWZHEv4Ddw+142F4xyT1087Q+w4W5jV9j/m8AXRtXxgdxI5UQLr 9AzQHMdkSnpQCZpfLRp/q4//yoMonk7g+hKK6GnzneflSgW6VDNc3t05BFH7TKWAQc2FP9BCfWQ2 MqnqkUyNqPM4qMNyxWSZguXWOHx6LQXXEQoANaS5fiVzm1bCSOq1YLSOz6uuAmTMDap6TvZ0Vuv8 pmImfLzLeymW17qUHTXZDHcirZdX7nRIhBeXAJyl3Za/Qw0FV0qnaOmWFtuLsr8dppKE8SQfRw6B Jo8cpHkzlsJFAF4Gdvhw98AkR7i5EQj9eFBUEmPIkw5gXieRNs0BZSYpLdeducp9Y7LvFL3D9fyv mC97mapcmesZFb+L/EuzdEWJEQl/R0cW8CU7ArMo86DPxA1LaUQaf3yxJcM8d2wUfwxpW+zwcooe IOKFAq6TOOJAHuShfF0un2YE5K2YAU8F30J95+lbZWEUmHKFPumT1XQamspSj0m1e40JvK9fgd9X /rpdKP66U+FM0sspcWPc3Y9kd/Oreuxtt1fEQoSk7eJfaH7e4mnXhnc+QTTCktUJHbir5HNTa71G UOFX1ca+dsCa5KkQh53TtuD+TKDz2VNJzF2uTbanpTLYA2Cjmdy5MFbCwBAqr7ER4TJF2JqKmFCG bhQH3Z+v3li8om9jEV4LNEcQiJajUbLXlp/Io5yZJ1216XVrTs+slA6zlHEwEfuS+eQux4mE4O3/ 4MpMpavPwoR8gqqYY+ebbIiQGFsnZ7g1SNru20c5CH5V1IngdNMOqrSTLMGBbpITXG/HMff/7eAR qqh5pI9oo3nZraWXPd5uQ697Jql+4j0iKKFd3Dnm0XzMuYRy7R3tXl1PQaHzRT9zpYy+LJjr6NR+ g/4CZ/s63ICdV/keqh9nJVDT86uq3ojtNEKCrn21wtKF0bjHeU52PpdcMq/zcHZIFVu+dQ5egglH C/lO6i7KIkF1Gy7M4mPeMry+Eu5hnoyw8wnK7JbEn8wPrJROYjPUqG0TRN5rxa3VD6pbjizhAk2G BxnPHFVH37QaGB8Ta+XpffBOkoz7Ujf38w3dlRDXvaCsUZjv3hfnluX5BTXvU4y8J0tvy3fApJM3 7slFLqsMVHFMF5SxqyiXGZtVtn3J24vLzWFsC95eVsP5xQwl8XikJ9JOHSMu0VXSGauC5H0a3+p5 6+nPLGQoDrHHycQ2fBg7+SFha9iNO602xANoz8zyz7o+aotTF76K8i+9lzu8k7ssQVL3qMuDL5jh /iikRHcqrCs66XPJe1KNVa+xnK/bLRPBLLrx3x9RkoSASjvpnQ9yGZdD/ukdT3vBLHd5+BRNXbM8 TMLWsd8eeuwZa2Y5sqnaprosXF334E8xRoAZnrxR09Uu2QxnHh/gH+e0vFqDrs50b1UaVllkp3aV S7rrXAPZIS7cN3tE4y9omAAnee5svOwa85v1XpNzk3eU8w1nObAV4U3WWptzcvt6Wy411pUlG7IY 2kVv0qbBQJgINkrFedUg9Hu3DP5t3RF0Pe5CQ8BvbvsuFM0YUQ9f7+w2g8NtF4QY5u6q+RoMFnes 78bDT7vBvq3jr0GF/422s4yOa9uutJgsZpYsZqwqMVgs2WK0mJmZmWUxMzOjxczMjBZYzExu3/uS dG7nJbc7I/3rVJ0xzpg1195V9WN9ey7YgQ7EfeCFru7thJMO2phDm0BNCTRHci2UXyRSskowZHuz kKHjt81K0+pZis1kPXGMjoyfacE/sSTLD6tEJ0+kstV0+nA2QYppGB8+rHWsrWuBtYNBXGhw1ian WwYEM1uHpbrD7q04jDzG53z+vtV4VPsEkG9++mYR5tkzC/cY5xHSQv7EZEFoQ3lAmJsnkB0Fw/8Q wr/QLLRW2Ff2Qrhld6UmQ+n6yV8m/WeCHw5PI9NHr2QkcvwXd9bSLa2cxfZe4qYQYYlvU6bmEEJX TQFo5CM7ty2i682W5y7ryl3EPGIRNO3+Q5kqIziq78weXwaTsUQzH7SKaDCX6k7CL8RjabtrC4zW EJwzy03EC8VSHbPpTbtkmCS3F6kT0Zu4VO+r3oABxGZSG3sWCU91Qaz6S67RhNpo1EUO4Bv4CfdF BehLb5/8cffRfFQ505u3Jp6Qg0FKblumhEMlMNYc6xUxBXCJWZruzlv2fFQwz2GqWw9T7aR0Hxqc /CZdDu2fkJHeerTVfLopCxIFo86uWzjAwne9j0UInxVHLLNmfoGzCy6VfN2nDHMEPV4S+9R9VyDo /El5zhlBKB1k0JmS0CfgnHeKPvyJH7O6guJB3Hsfj7c3GZo2xhDh3ZwiXnOIxJWnUw1mxkieQy2+ NISALPt+imTam/GMxy/+u9cnaMtwDwma0P2rqKMRWDK2xx3f9zmiuy6fOMFcq+FQPZbTXDChSOBD WMTsi/4kogQcaDw3Wdai8zB/rsJRUGZzom8SGslwYuuydk1j2pysVcOcNMsNdJgE3AEWdeR3cwiM xUwBZrBW7ga9t9GzMae0Fefxq/jPaKtloDAXoBdMQ7AOa6zl4SoXTsv9pXpEtvpkkkkOGpfm8poL 6Tds+jgGYF+1iM1WM/PlCfYoD00kk9fz6/UXMr3vtB+rTFSxU1Ie01Q4aDL0H4iPCC5ct5IGnz+I yp2+qWBjJBxZqXrdy3zcjFspgoi9+/BoKvMSwbKQ1ZEzrEpBlfnm4Qw58EPZB/5s3vjDJgT+nPXH 3gHjj3M+ynJ7BPrb+EJas/zeeWM4LrIegUY2LXFfKN/9dNq5qXcYlyN/jKXJnMFYH7RJek24vnXq BA8B5aECPs3F9txj60KeTuOmNG1/GEiPvhz9OY2zY1HfLbeVM/AOD0MukQ2cpW7K0XjpdMbcqtWQ Dc6VvGpG2QX7BTHaPacwGC8YZCWVp4JfVBSkziaJ69xbFLACEjTZAbb2Ey6iXtpd7Pd/wtmk7uS7 JrX33er52e4rQObQd3Meyo8bAZqfrFddIOpEm7F+i0o/6xTgF52eZ19x0w8ZQCzxWr6pK41PSYax i5LG2XLmIc3n7OT9sn+YyXuFrU0w5iCOJZ/If+ACHsnAWMoEodA/6WVToz0MSNC+bpg93fHzcVDr HSCJ7Y9kZj6I42xXevBE57CDLRhbq7FyNdrEjnd2W9t26iY5y/Q/b+WZbfPQ4N602W4cj3Em6f1x RD2qQqw8PVCmYbgO9fNh9QlqvnULcSfjaYFvAlY7199nt4rndOYFzj/9+vuq2RXLmzT4OzIfE+ZJ z8nr1sScscspBqcTE0ll3yQsZ/9LNJQQdnfCQ4Rq8idlZekE6o0xV7t1ntuDltdDHR4omI4UD9iV oKNbS6/TM0AeXUlQc/0psnIAW0lgvSZxgD6fib66jbO0ifNKeohrrEV+XPDcGuZqGkYVTWismJnn CyxNt8eFw+VmYjTMF0lTj2Kus4HBdF1m4RIMSE53K6cYwm8XcQdXEOsOOw3dIq66ir6xRjPpmtYB uWsK0u7jI2gD5XSUd8RYceu7wcHXEjWad/K8XVSf0Ta6BsuncKvDywGzFJF3TBzyNr4cRkMOl9/k JV5iDKj0UvoqXwp1qIYt39p+HerQbf+iGT5GfWyv93hc1tw5LnmLcDZkNbl0pxgamhjAvNdECxTa F1xv3AqpmmLYkJ1bdlhAlbrxAreLbi8hDoepi5W9WbiTbLsxKur6+ApcChawCzywfExvdsTqJdk0 cTJ6jJDYtYogZvQODuOzcV+7l9S6tMhunW0RT52iScwz+qHahfUMf9GQ1/Y0wOrMFkPfy7YF7dLe Ht/DMi5YdxLf4q2MV9xH7VoUvymki3TD+fxq6XbYod+FkD7w2XktqMCMecY18gZ3S0Dsq69OOQvP MsPco5en+jmylryvivDkIrPlmzpA3QC51LNhsP9aYSqG9zt4EtPTQQtExnlh39W3mtaG+qSnHsOn ai5VGn8+9/ZOgWMW6FVg4SurRAc7gKodJ9dGjZIFSJVX2fYjokbW4ZNTODPW+5yDzfGA+Jcu8Gic MsTjk8SOc3HqCvFaMfTKbcrrB1q2cox+k6pjIvZRuz4VJBWpx8VqZxJcm3Z6HE+PUyYZmeLCpSbX TzU4WRfIr+6yJFA4s9HWLeU1/MaL6/0Kt8adgcBT91/rlSFBWnW+LyxSONXTflNf3swfuKRK66DH XPtaJA9cfyj8QnmpQtP+p31lwL8/5P/PDpRzAJk42ElBHAAmDg5Sdi4gE5CNFMTJwQRg++91dlnZ /tL/Y/uv5QH/CDgGsrIxAdhJAZx/hh8D2YBMLJz/dW8XwMJJCgRw/RP9v0y0A/zNefp/bauzc/xx +de2OpCFCfCf9pb/pq3O+pfYZADgb8oP4mQCgUjZfxeck+v3hZMJAPwjUoAJ+J821llZ/q3+7P+s uf2XBGIA8G/qz/Jbke1f9QFsv/2z/p0+67/qAzn+2fr/JVIA8DdYAzuI689mPjvTH5uPnYkT9HsR gEz/6d77t8Y+O+ifaf/l3D3gb5gG1t/eQRy/F4z9D9OsbAAmNq7f5fv9RWD9r+XZuVhJQX+Mhf0P +n9hKgB/hzVw/HYN+GMy7h/67CwgJpbf79hZ/wt9jn+z/8eM1f8g/xeqAvD/n2v417yG/7nsbuA/ WAfgP1gH4D9YB+A/WAfgP1gHIOj/jW4A/k/SDWx/QUeA/3d0AwcQxP5XumFCSyN6TSzpj2SHbnGz Qcb6KgocP3AemQMIw9hMQAysLPH8hnkbmsaxWWn81evzW6cihbJoLU1TPIMzTK3IsdJCqYNAMdPb 9V3fzrmzlxdN5/Px/kmfntebnoNiu4dbS9uvo/39ny8TYxdLFxdNJ30b1i/HylcHZ0sDY12v2+EP Lz+nRpX3v1y9P7ErlycCg1Ssjb5cwTMT+tA33P1LuPdTYnVE69eVWZyiCpVBrKWpbOCj/iWEtJNW CTqJ66xxoXJuwtfSIhaxyoSPNQp3o1ztl/T/mJipSdsw760MvniciC4HMAczPytrCmJbQCjBP1GV whlNS1R0tacneXYK372CFnOakNI4goejR4EKE97YkWtJhAwfrGDwrpooI+vF8lFBgoGWEqyHVwM0 6uZebmK3NtAXs7oh54+5Kx8JQfaCAhekqvFR0bzmG6fRiU5WK81RFcA/tFeMJSqDN8MrNZbD/Dk0 MwZftomuQXyOGLd/gVhzdlZ1DnNVmZ6xzxZQvBLdjf9pzH8WTIHyqOiT6PX3W/oAM98fpHI8Heh/ pjqMV15CdbryD7CBb6MUEJGCbUZIWqlquxDVdexiDEPeg3AxAj7FkbKw4cY2nWokuyv701Vh4yf2 Ipw5if8R6rC0WQ14hmwJC7WRQH4fhFcNZtbQDXpQZsxMkAqF7B8t2n4FZKXF2dNw/jk2E0Mnpg8M T+7LgrsRHa8fFnhTr0c76RX4HzHfgBg/Bc6pMAKteiQ/K8hUVMlq0mz1QATZzYjTa3BHuJyY9tbY pkMVSFjKjdYc9NfC07tCPXI6HNy8Uylh2G4FiRCILBWRWmXw/FIa/Prted/sKm4IassPGe1vGDQ4 DcFkCBD+meoRDbbNZdjX89qOMsbrctLSyk7NfiSoZopzYMOoyLKRh6USCopqamF0YBxR7oZYP8WJ P0Ux7jWbi9D4lQ0oSdP3CIl8MKSjg6Sp3AurKwR6NMhNg30gWzzlMPWrFRkRQitlEpsPlYBSG+9N 2h8NwNzGTkuFcQ4kK6MxgXE0FWEskU7hpBiFAg9Wwz+kGocJSif0q1D5xDGDJbLiyippKWmxa5SF HHh3vS3cJac7YALnMHAPw1yS1QBBStwchAIRV+La5K89J8ePdEnawdoyG1pqEdgA4yxhmU2FI01L kdMCCY9YRH+PXUazmDYoeSUqumhewlmiV4FuFdh+IsVQdQeuRYDoKPqxuOPKEyL7UhfqI457UG0u akBU4zI+vr2c0Nz1MGz2KAvQNsigVVfeD45lNx4N3Ek6xfQQxzWC0qbfVLD3IwgmAG0tR7ZAGIui J15NKFjKUq00EJG0A1cJXRRKixtkGKiiz0a6XcC8V1C0wBh0EmllRfGTqKIV+6aQ1VkrPrz0Haoj T9UUwiPneZ42lGrIOS85YUvhQzE9IsRRIb1/7lLPpV44VpDkJSUfw/40lN09WYK3MmybiYgXomY4 q9BwGpslxFc+K2anenM/ooVFXeykhl1VuwohMWp3Dej3bnQ//CZMuzxR0xIQGcaPOXw3c/VkWLSc cPg8bs9lhddWJmjW+/WGycHAXKna8Bz8SnrU4PayMmSpA40LnQ+7EqmDYXjVEsLiT1I0ng3GwT3B 2GbQQQLQX4sD57XbqUyP9WhJqcLNNcOUr6ow9OCIGELvgCOf+SFHVfzgYsDk5shsWfRWUzDWm530 K0dgX/FFEA5i5wPgb/Qdv1DaG/o11OmLsKChx5T1T0NtJJCJQQ1CSdeoOaKG2iO++IvBmgitwaQy BmzuaiiPyHUHGYOTjXTSYG4TQyaKJXz6JiKcia7XM6WfSOohB86ovysCDQenjEYE6EXB1QFB2gHy c1J6K9v7asZeGXge+2O7jehBKbiCgqbZTjHQlJqNqB5YYvSipwx37djfEQ0Z8sNQuWaMpt+gCoNs Bb0ZGGG9YcAZO2zJ7eSFNxNFtBBVRc+ofXBZlcLVB6Po+Lnsl/HTWFkb0/Ya4cDgNZb8fLQBPKma FOaNhw3NFepUSG6lXDn93GIabGv+y4jFpPfTCDiP8/iWOSekYQkGYG29PZYzyPrHpJUB3UA/GxXP EOFfe5A0KKOc1ETppHXIzAFPuY19qMjzBeemV6jIhFRtPTyI21LwAFFPwMiJVFhnZOwVo1M9dojg bB9fCdhpP9MKiLeo2kCRUR0ePqTHEbcbeluq5qccYuYM/GYbqnucPXfD6UJAWn+U02UC3bfyAcO4 kulUVFzc/oB+CM3kbmHbRsZ93GVaNEYc3xlK6XjkAxzPoLG6FEDeYIKPeKc6zLIpZBNspwKLHo+m qVhHYAlnM/kavrZcG3oXuUPscv+n2jTd+dyYyYhVfFvMZU4pQ9IStOO5uoaqDThLM8pt/xxu1y3d bcTOnkBuCboJCAaq5h+fJcssQ//I+UYX1vgmwyvdiNEWIMNbGXAEQR6dLAOt+9nk9CNUpJq5RHVA uzny3PQhV8xoSBRWPAh2ar80/xPUFznGGrh+ly/RQl1ygu0uRjnFyQ0jbIq94kJ75Fdbmvw+99ca yoCBfUZCQfkfv3Rp3tJoy8S+DFK6+p82Iq/Qsy/VPY7dmFxg21zcj0W423W0X0YMGdUv34x5f2U8 T8JxrtXQThnAro5I3w/qM5j79OOtuFDHEgLsnYvBh47p1/vrCkcyeD4ySogvxLC4a7sGJt5yOP8m tjJl1QFm0+MBD8VOavvbxLntstdo4TlRbIKE1BeaIcT6mrxNvWFzdzrWQ3jngbGLsCUXnV9nVvJi Bi5eNPi8MZB0x6v89yTJ1rXvRqXj+vVTiNLFWyKVCDAkw3NM1VuMKlz2ZdsDP1Rmt52wtW/ZBxmX gDdycNaIo19PvbXKzGvdhhv9Y0vL3CBxgVAdWto0ba45NVYSFT7ytiQcn+G2napw1CTVkpqTp7im 1e2Hvjaz3krZ9bUTKQ36IeDISMjL+VSFZnqubd2c3BHt9IrAdbQceetccBWuh46XKI2m+jDZ19hC SI/iazCy6qaadc8jw7hMjuPlHjse+Ez6S52zlqtSyrDBVEpGZn8qRq98/TG1UhS6lJ7AQpleJaGY adGPOEYd2fR1Om0Q9PGVDZYgr/Qre1H0Z9IujTL3K1WEKZ8/YrVRf1lacKaVESd3QRJ4D6sHLj6T BpdzY2Cr3/q7d5C/iYz5l51dXM1ZR/hYn3eHM/p4Zysj0ecaAwTtwBULWWgYp3bfvDY5BVVLfeXn dKvqDILCpdhSNWT01kU8kRFAhRGjzqMpyiKLJkrcxtoYBLSNlN1JakpG4mcCzCeX+0rbzGVqCQL7 huD89Xjb8VjTUuY28LYqg2pPdbSW9PkOIg0YAJWQEzUx0WmIgDqrE/NpUGyu/fL5/nfn/kp6GKMJ SWZb9cO98jpL3XupG/PlBbXAbqG1nHLSVIGfFBhe02f99dkhjSrO09djtWIN/ojXmBZzvtDMpIbs 8vofpSjjwclG4cgat2+Pe72BJMzMhdGBnFw3Y0L3qM5Ui514Da/2Qr1Pz6z36ZaepJJW/k7xAaI/ lhFF9kWxFzO6jSPJB7YKa+hMircXFnDkVwTZZ5PQU0Cy1HUMAZFoXCaPKe9rzLOsTF+5HtpCYZZ2 PYH+jRN6E9BRVAPcOMm12mslbnkflfWAsgA1BnrYBI0IH+bt9bHt6E70ob36PROICtjMirqaBfhT wx8Fg+jUe5uU7RDoKGv7weM/VW8pWyRk8SRb48V+aqogeow8gjN9lnbl5lygsroLo6n8Jf1zoluI mESANWLyQDRRLcWAmixWy98lGRgtVmZl10bqjbMCE6kWg7tWHq17c84dJWA/2Iy9hcnxHsz/ZoOZ 4qNbtGUSGYu1n9UX3CSS0d0ETpAfJUyyXSkQ/qFvNxLK9YXnIOu6LdBhRWnUoZHsTKf1E6ELGmfT mfBAOkce5MIPI5mmRhx2TJdkJLhK+FQVRMIB1xW1b59nQVbYA/otYFV7UsrhavxsDRVAZD9mdbpA TL0Ow8ShoeoiIDlNAkp5bq35KQoBfloIi28VjsCP9K+vNQ0R3zFLcDZoKr+28py2cbp1JIu4uUxo Gnotr2OeUtDmtscsuzGiM5ryo99Ej8Uk+xRhYonT6sPIZOVXM7w1nhpJUJGldtwy6Z2JibCQfCFI yy0IQIpt5U8ufZJCWMqVhEunJPLwBcbOxDbuhXNFiU4VBHjmluitCPhFjnFB4zrw148amdV5Jtx6 NQq3ie+ctX6GVe/cy/Ca0BealaQm4Et/2H2iJ3k4fc3Kt+bxttlSlCoYIZd0Z65bDy/ITrGu4lSz L//kv+NUtbiXcDqVMpSugtrOYJadqzMJ6ZAPRzZbEO9pNiXbm+VqkZmg1jJiikvV6KRl8wwG1hTW Vel4dcnv/RyCWfgLu2wUtXWjbr+3+A6czGeo2nOI5AbTQIoQadFs8u7gHEd+MV0umz2CnpM3kxne fGUx/jahWhW/9RJORdP1iNXGfc+pU/9HMyIGhyWkTpokaRW1ZqFBB6jnYoiS6rZvDZ6PzmQy9KRo IudhLSQKXHEHMdlkTl7ig6h8dh5URIamIldufzQuimJdBMdXyMpm7vTMxbDhtPpyiMxhuq/TGLGR KtLNPMwBn/uMngp2Aq1DUkB+Xh2WEXKV5acTawd6/nsN6BO685OlQj+2wrtR2PH5VEClSF5KszPF Q2+2TtTxtOVxR9sVLQ5tRPq9UE2MyX21Oo3EHoqEpkUu0K8+xf2V4L+CYJgJ9hPreAywqaye07sH RWcW8U5xbZq0Z1yYKIrBVPbsFg81rxRpLUkCgo/3ZvJZ0ffLFrtR3iL8JbHqJcYQxOt1I/BLjY8i QiZuTATeS5eJnw5aRtMYsOyFocIo1zDc1wrT1edlB0ZOfyECq/UeeSyKFg8xlk2lxY2faB+3NFm1 QXwiRMMF0nxWqhUPerQPyxX19A3vH48d3XZnAQHyW4zv9ARQoSepwkiDHzByqKnGDhz0VcfEgvmp rSmoJ5U9VjM4zRypHiV0PSBFtXIKzlHiE7fVkVpDU5vaJoILCk+DQtOkq2FsA+iu96EWAMEdl1rj w0ZwaQN4M9oNlizYTpJFLb/elGIjXLCMZ4aLChSVHd2UE7xgF3g77X3iCVAtagIxF93t31VALJP4 o/aKjkC2hG8xGs2NoeEZ0hpecJ3bzUp3hiiSXBWG5aIXHxvPeQvsAzIwmKi/E051NNoyS5q4iS9N d1DUDOu7fOGoWhvH+GqZSFFr4rlgi+11fYr9VEhPvgZQ5HWfinMqmBzOSuNi3zduXkUUc93jDZA4 06+MTajQ+jXJ+IGeyZ16g6i3KkGG0mV8HYRioYLhD2fo5XtKkgFEoveIwZhe6nAsoDJSn28/vMbA psrXgppLh4tz+gzqom02PlrFT6oEU2EzRjgJ1bNj1bL9diyD+ejDlGwFeiXqRMR5gvpu6NeiOHBz R3L+rECEV+WCgqK5N1lBF6FHlVn2ZOy2aG6dKVdk8xK4v0TFFBpZFeiMeJrEyertHVlfiDR1A9Dp HBzxOngvSGb+OiKXiOcM7BgciRxSRhRweQoC/3T3sr0+TLyimJHd2vsVxJA/5MD1dedWVm17vg4o 8FG609/G0GN3bmR41Wf1+nPypppfyQIn3se+lQUJ5hASKnmB3lG8HCgQTvY1w9LvfxJJOnbTpwGK UmD8nGLcXlJfs9FmKrMQvp3F6vWYKjka4SOrV41RNcoQmEnzIjW4chVbfrNv8jiTqnmC1wtGAqek 5bqIfgAXmSEeBcgE+yVO7OfpBZpKibU0lrOE8ZobVxHe9xOo3VILbys4PAMPEl5xrLSHzaZIy/6J AGUFqJhVUrxwib2CachLtw8OmgjWaW4U7LxDRQrLV0Fc+qvizG8/MlBIW/TLgfZqrEf8Ju4VsXM1 9dNNKlHmkbmZG9/wKsFlFqHiZCjZEXlvnmjasXidc9qS2gxKqZldFFa/pG20f6UjEaH8zj1C1M17 jM4xViVTNlifkQGWXJ7R1OiRgX7YXqHBNY7eN0hA7NBZm4cWpY4VG/7ukOr0RQWETnVWxIF+7TgM 1kFdeTEysg++P1lx0UhdGE8lq2M/pkQZZZFhEGE45//Vo2yRBLsyOj99ijpRSj6tTsaWB/60hW8h eDS9AdWAMvXIKbtE28hBinJodRY5/NQYievnwXW9GdEuysOJ1QXBW6jNXpIJX/fabWq4/iFBpzTX hnmFQRZ62VxUvYa7Z735gR3VqRwfxxm5uRM/cQzRojEuyl7TTuOV4Oxhxu1QTUBiivxWlI4J59mb uPd9IdECojlI9mqZt19jIh2TI+jjjYxucdPs49Ok+lie6KzD5tdkzbbsIFanwJBqMZYs58VvEWSw X4Q5GrNzDL4n9tv0fwipFBB/OJ5qm2iuvrFmD+b/CTJY7uHyk4tPWQ/fcPvenMx8bW0Hy96hsb73 K8iF3Z6691ety8lM5n60PiaGT4J8qgJThmRao/XYuJ24XZvDeUmqrbidgKyzuPlpiebP6B9ZU4/5 64ZirzOpbuLN0qdi+yOF14b7jN+fvjtI2OU7QBD03SObdeWGnq0BTR0qvtj4Rzw9vjBKjPB9jNTk UohilHh69VfSyE0Dall/IepFxumqt4rt545vyqzli10gS/06fyo27LKsSWKKK6HD+kG069h2Ldnd qOfwuu5mM/pFWseWWDB4wuRHfxTTA2uF80/HuQiPSPmTMQ6Tk41K4YwE+rnhDV7qVIuuSGuWEFMS y2Xa9NxSZOrK3c0TBksviHQclFwRiPTF7QDy8XOfG3t2GecKxcIlt0KToDEO4UKXOalsAPdQBu59 RIL3uGv5TlGxvNbPCbJES4/0xTvF8JV6j7I9eywc2QtNfeIKIaHomijyDz5v2jbyCvD6bcC0Lz47 bAEFXS0qwQ+QI6L08muuyXJFWMwRuA2tK7ef89J3qfYlDW74EjM/OAgY5oPV4o5wbjnGCa8BNi9M QSxWaa4vvtKuNPvHYscLETg/RdJjvRQSUnE2BaxD/N4KItPgltwm0znUiNBSEZcIuJ6TBX/uGoY5 YyzP2PJpcC/Zd4g41yhmppdkOrRsZcxPvuHRY3FwD42Sn8ab/7RrU4GKeqnty+qyLKIU58ag8Nh4 mg85IEOs45H7AuHTHsa2KuOuPuBzeO2aZEXt1DIRELdz8cLis2GjsyZSTHD/hajKhQE7sO6TbWPM 3cn7Za9yusBjfxaijKitj3qX8L5mWl+9nbITgKObvNREmgpmnNvNRH59qKVfMBKrbO94kO7s8Ci1 R60wnNaKz08fn2hUrA4KtClqb6xvsEBzth836ahfbkQ0MSI9acYQ/WNn0n3aDJRh9gp/eov9NlMu oS4sn7TRNDUst3cueIQoun6YARisuairsV/7CkE/UHNm56N6KZPPVL+WT2DmkAB2C+Tl+mBfMd6I 7NMcCGrFqODxSjhdy8uqbxenR70nj1Z6iEK20Dyf3Wvg/rhyZ8y3800rU+hi1/7O5su75tcrc5D2 N0yiz6e7PWpiMC3Zu1z3z5L6veUElVFAwPKClSrE0Un5i1f/UwaaRQm+ZLYBAWGEyy33L+MHAaJ8 MrSoEzm00Yti+n3duSNUEiHgmQwqCda6gaPDgEu2IrgZUfdRr7VzCFv1ww0t1YpQWLmsrg/3Ssm2 WN7DvXt8wf4Rdkhtc/aSmnTjK9IS9wTOJXLqvS6szeZpIDe3ucb465YIY0oyNgnPrwmt6yahFte7 h5M4nOcJUTZlOy7IOfnpEa/sduVpALQNqmW3IXpHW0IFB8zOZoWp4JGJCNxBLfuV5TFFeePdsiSx FdbMWaVamCFLCquD+eAed2MuUES9wqmZ7HadG6Zat0xx+nNguj6BriHxA+9iI61zLuKkF2f0w+ev UsfRpNdnaUPr1kk4l2b2Eulb3hvDsuDHSTZC8s86YF6GL2eN325TU8XtBtjuzuVlxsFvjTeQbIfO LlsSpbN6iswiprfYQ2hTPC3EEog20VtsTIVtWAg8X3s/7xCHO6X4MhmRGF3V96/6vKFEqn80WV18 sTUjzAWhjEe85gm2e6M1RQWWzjIF+81kXzeETEJ3PRv3ProQLoFa902HgCEWLQPnBjpcLdgUCK7Y WmSuy5gXJItr4rNf7vVvpgXbDr93YEnxo85fIyLr+2txBg3TwpVV2vTswkqceMjovdmScxxjwV6n tRmnD8C+19MOY6auq7Nli+AjkySt87qPkZDdS/VZpcDS4Km9kp5uXnIcyTQzRho2EYwKwnoE6/LG LXwNtGKmOzvKiPqoanH/vSO2JYAbTTEckrYMhySUfFgzyPji4tKKHFEHK1loVgVFYs5D6r2I0inm MW9XkP5qB3OvtAYj+uQQF0ZZn1okv3u6LW+g9PYkivCB0ET61J97IxQOR8OejKVuOUIDmcxjzswg vbDuiisu6dh17+WMUhw+OKcZW1X2W1PGzYHBsk8ka7UzUXXQcMt2tXRxPFreSGX4r6TNwEDetSgz T9QElFeZIHv4C1fbhNnIhqcbBUW43A8vIOfFSseImHcy+ztS84Dm4BQSXOmNCH0rbUyiHpcWwrma CoXC5p/nFbozKlXb0boBxDYeILTvD9H2CjWq9NqQ0+EVphnD+SWSV6DLnP1+AGzLyPKy63qoWSYL FHmjR843/XbUZphdoV64IsYvqFOYAaxfUS9PF6LO+Czg7Qds4F6HvIw9cB37TWQI4S03KB5Cln4K +VhDf4dUGy4AIk6Vv0OVnFkWqSVvUIfboY6Kz0as40xmpOxnqp3l9Mc1B6kUN91XmeQVQM8Nvt8f +uXLmNkLzQymDYtD9zEflCxUbT/lCCBe7D/GhjwTsS7PkOqPy/QvZSYYRZQTtbkyOn8ecGbI+26z 4FTq9E3r8rPVQnjBqR6KLZ6jwMlkIPGZlm3+maTm0wOT0pqnCer3j7gx8c9rwiTT6wJ7AUjkPnZk Qu+oHj2btVbXToorA/gPl7CH/j8ZocnLWOwoqhWhqX1mDFWGU7qpWA34BTN+Mu1u90R6fPFEzER5 ueZyoVVXCK0XIMSyGtXoRDrvqm8fLaBKtIvh7P2yjs/1PTPUoEll3W5ilOiyUm2EBfbqg9Ii3c9f cJduZtf8l7iHWY/d3oM7+GlWzZVk3xlooduhRk4XpLXfkWUhCNZzWE5IER6yMONxojtW22m83wQp +KX6BbYFF2/G7Y1rI4263Is+I/nYGQV/ntCxqqBL+hif9Q6WudRJfi94RN3E5yg1xUNr/Cgg/4wL UnFH65CWvXTONNRPb94hmZNs/TB5XKv6atDdkN4uUhg3BhZXJfIMKUWUbF1sg0j/mekxyxG9gDpw RfReIjJ2TTpusGez8qXZJlkZeyjPZ/b+o1TEAEioFw+NHfzsm598rM14KwG5j5spdoDbls7XiaDG aw4e+xod9Y8z7PQUr+ySd6ZBhnnTa5IeKxWTWjRz8B5Qq6PPWjZO/U5QPgsvqdISU6JIyANay2Yf DDyZwb1e84eNQxuF6HhrM/vLoeJzV/b1KuMRUEXrSn846yQW3lUzEQowvr+ANIPCZd2Ud7uOF0Sx kFHMO9mrwZl0Xun9jxF+taiKCY5eR7ot1OxzVMfs3Iwt5Rbb7KJAcJME21dDS3SqgBP0bCM91zHS bPIw0mhK/EwE6D1UiXe+jYjGl0AuKsNYNN0xgg6jdDKPxTwXPuqdqDZBluloXXIWWkClREuvhdLo M6RCszRK+xLyPTqrp3y4XhvWseZWT6V5brc6+ZJeydn+rpIarXVFmiDlLkx/X1mudulRg6THZfbm O61G5wqu0g1z/8RUISHaSAivem4Y4l/A1iURc1urMdTaYnHyy3R20fzxrrO6t0Ljk4BMmWhejP26 Np0QW6Rr4fcIZNn7wEhGZ/P4laDS48Bm48Jpuz63CqoHqKPaz59dPdzib5MFjCgJBA2mdVyie+vT 2T+KnbXRcGeUV/lTtq1iroRLG6iWfVFvasOQmBOHt48CThkgdpwJj/ZZL1np6S4OpTwfyDDF6ppL hZZHZ96O0EWvCxTH032RGPU2YqDbvA+4vXHlTLIBicLFi4YXwC1FLQxWiaO0wDtlZb9IA9HBEdwT sEmwGIVxaRAnrCUTyHPEj789Fv2CnqzgK/2nzAzwb5gZADv7n9AIBxsTKxcpAMTJxMVGCuACMXGy /23jHsjF8R8b92x/YWaAf8fM/Is8G9ufsMq/yAN+y/+nzMrfyP8FmQH+LTIDYgICSNl/u2fj+hOZ +WNQOSeAies/RUb+If/7wT8+9D/R/wsyA/wbZIaNFfCHYXZWFiZ24B8jN0jZ2X/f+e96/wsuA/wb XIYN9EfqxL9pcwGZODn+b+V/l+ifyP+FlgH+DS0DALH/Uew/cjBAnH/uONY/ZoFwMIH+yXD4/1Me 8M/c/yWsAfjvgZn/P8TI/5768b+JkX+d//HfJEa4/qRCQCz/uLD+P8IhnP+TcMhf8CPgv8d//gs4 hJ3j/4i+6NCyiif4HvteRfcW8tT8xa20Z61daV/BaOCeUtVOS/+EiSTDM8eZ1swBveWrfSZn1/vz EYyxbyp4cNuslmasSN3MhqmjwAYYTIqqjkDGxeaZ9eRCtc/b8cmNm8uNno/G2+3xxNV7dfXmq32X z93Qxktb37mnC+/rAcfCiY23RsfzA4nW3fvttWiHVWbpZpdnLndjY9GsuhWBolceM6F3ecOchiKt ls1J1Wzm5r3Wwp2GBkeivPFa8/HBfkTnBr6wjpzBknKZs0ak7NtiqRRa4jG9gfoltX5ha6VDYq37 54ZV39raicUfivVWYYvOGmMFYlYeZE7m5ZaFodC0FhLk5fRGSMu737UfZ7saPD81VG2Zj2VI6C3E +G9bBCBXrnErzNyuJXmfjzcNUAdkK1dPD5rCOpOe8yz631IltTZpFB9h9B+2rjXd+nWSd4Sp0CM5 AYDyhsz73WoP7uXDCeENvmil8VKhHrV0tFX0nuaHimssWF51jF55RZC1RRel9JXG2l6y2cNwDEX5 2dMmjA3BYRkbziIF5svSBoJH1WmP8QeGdibCD+bPm3IPJQ+A5py8npMr2nsEsnewNTToRhLCwvo1 Mdhg0wvSNHzuOsqvGYFccSuhLDRa9ZHmHZWST4NWI6mOVtvgrUf+lCNFHfqQviRPmJgfd2O4Lgm4 1+uqsnC34ukAWa0qlhmdgyX5PvjZwwPuM36YRaxzj4heI4RFRbmkxWSwHIxIVZCQzpgdVhrOMOL9 SGG5sntJgIpwd1EijuDlxi+WL5XosjYjAo2cWEhKfZ0RKEjL9SYEiJGse4Z79wUB+k2ZuzE5OjSY Qu0x5oywOFfy2PmGSpCNmGZWK1hecLjhtGwuS3ZLEgIbMJDUfVTkT+eqhlxh+NIyNljBihb32PlA T4yDI/wornM7lO+gTPhWIF/Gwi2M5kf/H1uzcs6b8c+jcYONqA/IdoaSvgeseTRNad5nK7SSyp+N rdth6dVWj5PIA1vXaJ7nLXnMpcpmavJp86MXiU6Njyz6CZFgSw392B779QwTrxqaPr6lWaEo3poa P2dZHXDCIQWVHdSAXcoP7awnGYQwmA+/DeOvchOjHXsy1kpWDCdeiRZDsX0af3O0Lsd/L8XpjPSP 77ZFH3+c7tVtbUTkBWhjHpKewbEcOkwgxGX54nMSoaFNzvsHpUVawIX5evvKDPgG2n3sJidPacXu NxKBNcC32n80mUV6FEa2ZJB0ILQFYMKYzoT2Jv2ZgbFU53mM3WjIaa0r1iQ0ZH0K9zIshhj2CHZa W0HNj3eEH/nBkLtHKRDRlvhTHtIQvovS42woxJgkhW4fyytBL8jUwpwYgVo7Hy9gGa6Azj7ih3bc EZ6cHrqzo7EFC+qeni+iELOaqp0vZC4upnl07CFQrgN6Nc5Q2gd8VTNxMLofq07IhgIIJFQMpI45 42Ta6QoE4v5MuyW7EKUzx3KfcDdDjM/FhB4YxscWePgxicRDacbULB4ckEhbCAieWO4JsWA1hzwF eoUK1OQZB7v79VvTBJrLVFiKIOSkwaadHeoiadSzg6OVkKjUitvKCKvR59CF0H0t3We+dJh4Xk3z +xQP/TXqTr4QjhaVFmpQcGCStdU540lp7IA1sEfoM4tYrcl2TJReu6ijqauq/g7ahFwczUSnOUAj axD6/ZNeZKCEvDi/0Y4Q3G6SfKFyj9/IT9rK5aSzQLuiw5pKXD9e3wozNPpZKzZyLxsCES65zkId pF27MdpVMtF6jbSkNhSKfl9Upgai9Pj8DtHp5VZRIKS+vcMcG+so1RgfuDEIyQRON12sY6A/AXM1 SRRcHHMJDxfUq0TBiUnHBwspLBIdo2dyFCtER7PIOt9nVZJUIqqDgBUlCGO7hw/Id4UKpcC+f5fp nnxT1L2Ej0PUJMBFHJxXHDRxVkiQR/pihDZYgS2eQ+noH/Lw7Qp7ASpHUgFmNhqK8SOLJlbzTI56 Dvi0ArzdgnE6jFuiXrnorYGnHB5puykLkbB/ERrVH1EYg4Ll8tmC1FVkzSXC/Hahp80OseVOhHMZ ddzngDJGdJrGqNzTgm1mRhzVvfs9O5nBkT5g6QlcgG9Exihhjwo9i3QcYU9Vkh05CWkE17HkLm5R 6clkYxzYshHR3eftIVxnVfEvcLdy3+UyOHtx6aF5PiUJO82FvZimLC1oehEEQq9g19IKws8pwlag 8gxSRtiXGdjYmY5SMhCGgc3F7joKfWEV5FqMvTBtJpRFJHyihmgVntkt+HG94ycBYWAnLEK5Zy5j y2K+9tjbPQ0m/AHfqSC3alBnUQM5KPOH3mlgSh7JdKA7Un9GBANewGiI4+ugXeOeBCZz1UGBxO4x 34IkO1SZ31MmmE3koRPRktY6TpW0Jr0iqb8rgsTSY8aKEMG3/GjHvkWbbxTOwVLTZHdqWRTNTfdg JviT+lE56DW+iNPK0hPxdPSNSgFVNUPLaYqf8xu33WEvTWkuBb8ECO4u0dyrUB08Y7UDqGHpsLWY 4XxTieEHvkngzrlyO08Qs9Ix+VZAZlToeYbo4nTOYyBwhVwWsZq6ru6xKOYVhcWK73Z531wPlF8o LajabMpDlJg/yyozXhdWqn8pc7wLHgw8qM4c12F1qSz38Xn6UVxucy6TfnJ+bOywocln/VyO8W63 2qDqkm7h4bSumV4O6aW1YV1F5HUKSen1y2xO8yzI953T5l294+mPOAwvcnxoPkyYmoi7x6Oy0WmY TFY9M2zTcpuuYjNX44P3Z1d+EoF9qoseCUGKdFyER306w/TJiFO2Y66yyGEj/dnELLXJmdQoper3 UCbPX2tbPooLsWkB+zFxEoSi9Te8NXQ1QY0OdHRCdVRW8YryXFGPKbfU356WCDycSpw5CJR13qYO 0t55CTkOjkkI9qv4rdcX3pP4O0LmTgXOUAgKzQ7TKzClp4XdgEnXyArEwwNR2XRxToNDKB766laO Lncmx1ktz7Hej8GBHcHz1YLyO9E8z8dyVq25sdcC64Qc4YRX7b+o5/lRkB5PXPA2YjThQ+0HrwNu d9/OWb7Fq+NSf2aX7w0d4XQq3Fn8bBmT+OOqRE437mxz/dXxTnmyczgDys6O3poUZrVHcBNfWv+o TnYYPfp2H/y9qatYZQg23Me4lz/GaPYGk1mvF5LawK7ytYYXLnSahMdzHBxuUY2GZ3yZCKUCEuaJ 5RFcs3ZZuMKmm8TA2raBw+YQxY6yDr8FvflCAL0Nw6fNAO/7wvcu6qE3P9NfzVdksg8xLpAj6/kb 4siwz/vYAoQyLj230+4+6vV8C6V0pmI0D83C0zu/uiwT6HA39NCTGrx5P/mtHZ8xwyHYZM9A49u8 xquR9IWDI2+Ijs2JL/8wgdtUJVhAmZGUhy834gmQFJD+ieGE+0mtn/9kQglS8Vw2LezXhqAJrlxC C5KBj3v7TrYMtefU9HUoeCiimE4PxIl2dKmYBA99CYDtmUfhCKhMrRRBfsJD8Suq6FwJjfdUp/Px prqsLyXfDQbHhES7P1e35/TTjwf8RIaFuNAfUKLvgCvDgXK92EVW3VcnnqPT8ot1oes+AFYtPvvO vaIG40+ZLvUYtaqUn1/iompJ+YyO2E2ECyv0owLDH8OOK0IeropJmr2fpl6QXhgJuTT85YJVWT+D wQE5yeYkccdCXBJz5Jl1vHq7ZEx+nO9FCGBMRG/txUDXt4FiFQBBWpVf/GlZPmMoigQRTPgdf6MC 2LBprVfJQUlEosV7E/kyBiA/4R4rpmJUpHgkaB+yN2GVsEQ9ebrzSouDdiOVxDBgtGdtoKLPMRQm qUlyrdBMa4VEFKOa978i4Kt94MUNW3btps/2Yh9fRR5DYGUXG8ndgaWIFkY2tNA+ayvoUhs0XWtZ JN451PklSuYDu7KlDBi3kdt6c7kM/J6BZkM5Zgw1HC7JIBjeuIFkzk5532IkxmFb6nWH8gq8b8jr Wk287vegV4lKp+ADu34QCPiI8mnmcLkg3824N8iJL5PEXlpd++ZzGu8mYixrAnkxjVsSGzI2yo4I a5fHslj74Zx3if4DSnFMvNeVBpPchpBRGOVXRG+GCcEOxuWyzkCFCXSBic/G8F0VOrritmQv3iXv UQIRKNPr184q5afBEDYhxzfv4PNOw2/yCvdgN9yqSrq5ZRHKzRV15650WBzC5ipKtDkb57bpFmHK ad5kMWu2bvYMvSUPtgzCsA5nFGwsr9/oPK4Y9AcSfwoLpu2eycGwh7I4r3uWWEcrORJHmdBpPomP x5bobkT0OBDTaaSF/V7Ppe0XjMZmkV02NTFnGt8h/9NHphMWrUjoLOiebR9eJF/Kjzz9pOkfMeKl S0xUK6q4HiqCDIJhVQoUsOfQLSmsigoGpHK1Qj/pEOhOSKbrLZYqt1BIDKtWxE57q8jH2KqXIlA5 Cc4Cxs2k3QZyDzp8C/Yzx5XBKKcz2G+PXCGH1jMfnkhN3ZCY9YAjU/G0CshQbi1eM8gp8iVBqfP2 bv1juUz7Inczs69uLWK9ZKYmTA5Qlu63GHoeyKVD4D0PK42J7kWm2GaNqdODYF7vMRbBfF38VlTT vK4mKnlOegOgq9g4naAa0vxmue0tQgEviH4+4tfTW+OEDgEkX9zrJT6VMZh2qqny6ce8xljcmeDG DAPnPUybDurW8C592osEF6VT6tKGDXjFo40phfr9VeBrg+wsUybbT925xdd2yVl7zQseIliCKkZT IIZo/kB4HQwyT2MphAXTND5n1tQkigfe7ndeL9uYjUpEFPsgqRUKB7jjXdo0wQoDrXEzkF9z0woe VNNNbQvWd2ZpT822HCcltGEKfS9kVqX6unFPB8/mDSLr+/Rmz68peJgHJIuXu6RhzlMp+I/gg7tU IwAYRchTj4r51yfLRSvp0fssrSc9OLvS3Mk9HiUDJVRn+Y4txnmYVacUHKofTJUPL5TeRMzolK/X TuQCxrHOTioXOkrnOAgi7EeZl3fskAvavOykzXNhdZo/ODrUU/HVvNdtV8/9S8HvH9TTGxAVA4KN YXjP2zBviqCdVxysQvgkbB6Obrt53ZxjRDZLYhHolAXi+54Vfo0kdibGRCof3Hlk559ztgY73Q2l 32zE4swPtasjcvNesLBLYjrhJN4ho/Q40cZrakVHvtBa1daofl7zzq0bwogUvrVu1C49NbgGUoeZ hYy+v+O272ccsKe8LMi9kGw9K5gMO3lL2Ro78NeQTAhf1l2r7H6ijKdzfbrWoZa109SH5/2xR+Xv afZSk32a9JiWj3ez2Nw1XB87t33a5spORjc3SzPCUzHQJJ6nlOY1C0eDwpYFtBCOJfOz70rfJxAw XfLOerWmEY4Smq9izC2y30YBXKsPbZdrfuNpp20iOfji7xY/IDGJzPL0vjMnR/aBzGu8KAjZveCY YiXt1xUc5rrqUO4aw0U+hQO+yeYyslEyNRMBfvR2c82VhwNhXmjPZc3aeDGktyL35rxx3HB0sFRQ ZpwJbJullvGTX6JaJGHaDrwC7xrGnPHQknmFdPFGfId8CbksGCL8ug0VMU7eEAdYZHkfXDSeVYUn OYY0fXfveG3q7VC9EFJtV5ixPxLK0UwxYIQVpz82sfgo8PvDWM056/zhJofLz5owwjNhjjkA0+RD ldLibqxjcnhUOwWHdjtJCmA0upL3J85clPKqd8lsVLSwnwf5AJNNlZT/pW5ChPhQ44Lo8WVAbPy7 DJ9vjigQB8e5bDeE2yC4pcKqMW0mqb6p1REDAyvUCedU3xspYIvN3LLCUiYrnlFKivib8keFd5lM H8PZS6T12G7/00QU7wBxErJCqfgOEC8b93QnTx0LAUhcVpP/bJ/g94sbZHPLKdmPB3tTSJXMG2SN rhTzjGexafYrmEBNxnT01Sl1VGlOr0mQWe9h6UsBzh3RV28pHv2H9wzxFPUs/OjVSgGfwDm17sJU AMxKW4wRsQCW5TetGee8q6glovdgBf0hrFVwDKtfzbLO0mPbtI8JUx8xmUkgZx3wxinzeBm+R8SR j1zKUqEqedeKi1XsisdW7pCr35iI/Xh620tFi/gZmD4mRiwbtIt2k3LPrHo4uXS5sKXQ9esSMnJY BwQhvb8cC6nQa7RO4j7OSELfV2g7y9B242/SojBbAUrKXpU15RrK7JMTW3m1VouRWMLru5V46qne PG/xfoUt4mthyNcIy89Icrhkx7g8KfbOucxgz0Yw08g2IEzFd4P2+ZwV1hWreRO8Pv/Jp9p7x6+O SU+HxWLqgwxaZUVIwyb596e7z/yvWBwJ+zEXRtqiV+6DiH6vQbqzzwPrdBoIu6bBn50639K/jOPW x0hNYf1KR1Asg0R5NO5qORcWVIR6CU3yta52vvikwCdnF6LTwsCdqEmMErE7LlYxwGPtMV5ptqOW 1TK9zMkYEU+XScRnph7Y8Tw5/gY9pEOQCHh10vr+zHGTwWpT7vaVGa2sJOFA1Lq3dQyzZkPpZgzL 1rjsNbEsNrALLSRJgLWJ96jG21RgtBUbkj3yepzAuvfWPptRw7CDNTYjwv606igs9fozKiOs9FjS BClEIUJG9kAuMqGRM5ZM+Q/Eb71ztwZ1EjHkvF+dzXZZdD8YiW3VLzCSqGYkqM7VvmCYNFFLaFZI mw/BSmNTUlnfI9rdFDNjkRj0xTZbP4dmCqZoLQe+shHdzTSvzxxHRMw59VTxMDj27884Cj+NHU5f 5vb/qmbqc7NjIioMTA27QfHSCSnujDWIo+76hcKdvWQ8+yQQuYOSIkg8GNVYnuZs8WQKREY37t2K 3PGR3+3tg+AUZQ4pVeaZewIeFBabcTEPPlv2RMkarjmnCIj7y7bchTCTazRRstXdQAY5WKxbo7ax yUxwyiQ3MPLNzfxYDBln0ZO9DyQzNy+ewhq1AE0R5E1hWNmlcdNzswuFHfVhKK8jt111ELIWgVXa daP5zAPQgkCc+i5oYd0BMa6uKehPN1NoJK+tIgt3fqM8lwlwVIFvYxX+ubAqVakzusEmz0CZZHlo 4ZHuutxBu0hGFvQcNymMVpU8+OME0yJU/Ji1K9oXBVNnBzhGEFMgvIwTXrAXe7R0BdlTmCPyQBb9 9939pW/rvLoCqoTIKw/2W6O8FEYr2/dA5wwdvRFfAZeFBzWJ7huyX0L3iUFQzzefTxbHYl+NNpj8 Ii7l+rc3sNtowGFWs8i8DrYgw1Di8ZSXYMtYezHyPiKGV8DQIFVQ9GKkfVQLzxC66B8PWiaCv7b7 mpc6aXkcXI2GPlywYvV5RZeLxYkvezVBIxnhEnmxuxBictIEf6ErCIs/kRE6m3H1etFM7Nadkca+ Yy0BqehAQsVaK8quwoJX+WQ7N38dWHjXzkYHYhriZ9p2jZsMYzJGf9kDWlHdh+BBxH+j7CYT/OYp BfZRiR5M3hiLgbOGDkwkVZHF75soY/IUkjCai3UBWDa8vFybBCaADl3aF0p18A4UPkT1U/cGK05/ TRm1x4u6CI6MG5ZsCosBNQ6tHeGj9jEcxFfFCZP4gabyyyvDyI5fYgpjCFPFyoVF5dNXAC8M6VV4 x3lkUqVA5I9f/aJiZeG5A82huUcrYC6RKhCm5Q/2pLfFyQTF2c/Ub9tQHozL7MP6TxTIUoVgmB7b 4NhauQwTVquExYrtCmrA8Kg+4E1hnn40+HrJbRg6/4E0P1tYrPSM25BXeRf1IX8+r7coS1gs9+j3 DcktEYxEIRjeFZDo8CWF0XDoIyZpn2LiR4MgZaiWXjoUPPoMf3hDimBzAxBRGJxQGIuGFM0slJMU QHHZNA2uWHwWemvWYZ0GpA0bZcypkgaOnA4d9VPqfriWwY2IS8QSsDusPjaem7/sSsSTVeZguy1/ Gj7qjExc2HRyeEUR+XsTQ/EN598huMONILj/Lvnh75If/i55brW2cDRbsS4EXjiE+zcot1uamT9F b22p/E8V9M0PtuXN26KIJoPYh/BObb+euhbpohCN+S/lChdU4RAVZZKL/7Zr+9vudlv+fF3vBiEH gvSS3q7kM1XalySOp9EmNNBw9hkiKJBiZT+lEkLEc7ASgicAKVfKmcvYApq+gmy9Mt0w2aApp6aX NkVQjExAFs9nalIRgeJTMsQIJpsl0Y4jLcnKE7pZyxW36bbCfRUUvjQ2IIt+JX+wbs9pHrUWB5PQ uZNf3bo9ikB2gYvzgsZZdP/p2LT2jNueV3JXJHHkBw2T3YNrjOjv1f6EXLy7MUdoD7eAYJ/wFWmY QA0rJn/8t25wnpztN6gn/3wRjHnamS8zwudzGsycp729pr/dOZt2+nf4Ellh82TRLgsP1W07HaKW nkCHaKnhMjZqwUYVmxN6uiSoq7jq6TVMOxKBsgps8kYM9ZTGjDIG3MJ9jr64ZbFd004oBpobZSkY Y51y1NCNK47+udrX0EOPHk3bNDFQWggUisNyVL1H+vzqaniMv5cZqZOlzRdPC5s9i345YDBv22kc tTQ5geDD5/yBwZOSK5HEgJ9RCmP4bUGNMwprTsuu4b1hVHON8u0PZYj4X2r98SCT0Q1ZZhD0MfGQ fE/wsC7zhqlvtYJz5Ix+G6X7bbTht9GP+YNuCXdkfYwMYdhpVX2i0mVJ23lTvQM3/e41aphtyNgM Dh2dth8+5wYVnQheiTgFDCGzja0yVfgfaFQF9CsmSN+mMPld81SEk/Zg0pOy2tL6QWFU+orEygdW W0NThHsKbbmBXVMOXDo05Q0rQvFdY2LYyhF1QTP0p60YZ7/b3YhO2e+iC3Jq6vkmlx0dzarZG0zp vQvuYYgwZ2bMrI62geGI3IzgpfNw3ZxOpnEzs/q0/nj68bga5rRW9hwR0YRE7NhVUewAda8PGZWk addZomndHt5bVt3XeCD7aUfiOHzwRnn/968EhXfcH8VRNvJHKB+zEBaqqwMBrmkrkeAXRlflUpUT hgKV9axKxkfSu6P/F3PvGORZu217pm3btm1XGpW2bVbadlbatp35T9tZadu20e/bO7p77xv7nHNv 97kR/Wl9emKuWLE05xjPbwQTNQB3goMkZUPpC7EEJ2tm0kp2MLlQnomxmbkKXJaPR9RSMRRQh0dt rFZNtkfNkWQENk2UHS2bjnB6ms7KTPvQAA7KAN532LW8b+9D6nBgzR9yOON3Mr6HVE8e0Nauu98N kIOvo/qD3gbpJNCZRorFQ7D9ZbB3UBYqI8zJBBFHmBviF+kzd7/WYC8So8syoql6nmx3EVAAnuWN +6fPWu6vqR50OY7DsRysLOvNzzKuHo760jSQeYIbtlrcXPpdAwHHhT2lZc/6W9f9MczHkfq/+swL HTvluTimRooUvsK9ucB6aq9EO/dfsablCAXvFqU7QWPnttXIJB6dpt9SY8o/289bv7QU8PqOWm0v CJ4efuw21J0jPH+UVSJaNPqtqLu3wV04wPrGVYHaCSSps7h8OTzfIvf4HkQtCOzk8m4gl7yyCzlN oTyzedmqYzHEcJq9dYY6xEy/gi5wC9yhA5t/vA+UvRoSXkG3hehqbyy28f70SnxSkOpEVIe6Ie/d lW3fwFJUwmSruaj3sNea6RnN5p/tRGhFMdhBsElshErJud4Oc/PuuuTeUBjuOswxQyzcx69hOLWw SZogLjh59GAs0Lt762cn6/uD3hN2y6IQZ+nXipnke7hNKCEROxyJqPq5C/lUD+M+HH58nFe+24pA 8WG/ir8NrnK/s303e3FwBHmXvJqN9PGegEuM0pQoQ4ZQ1P/hG8yMfQOOFfFwfjHE4R0iJfKeQnoz +owtVaS2ncjS8x2gr+AazCJ4z+5ZlQhNQxxI6Fw7UR9pP9QtRem7bU44T8Hph9dYqzdgQm5Lieln Ao7t63p7mP1d0Q9PKRl9wO3ll+VuhIeGaEmNw/OUOQIp3VqX2rov/3FWrUPYLzV040gbjxxkBfn8 8eX+sau/wOPFGa3a9ki1ZJTS9oWZUmGE8e8NFv+MJvh3OjcLJwMTJxEnOxMDEwsRGzsLAzfX31EO /4nO/Z+DIVj+BczAwfSfl2fh5vpb3udg4/ibD8H6NxiCg4iDnZuB9T/kUvzfMjvHvzU4/AuYgeO/ sJewsP+t7xOxs3MxcHL9deosf18Ldk5mBrb/2l7yb8uz/gu0gOOf7SX/e1T+/3d5F/+Tkj0H63+j ZM/6LwYIjn+2vvzHkj0rJwfbv0r21VrrdqScKD6cO347hWi9tlurYIFA6bJ2sHDxm1ijAwYEbA02 sFgyseT2ZnePXvL12mcpcpqNndBMKNpDRvVnC+Uk66nbgnapnI2vaj7vl4fP65c2vq1tateMtUuI hAy13Xx0DH6ZmwzqjZdOXW9XvI9Hl4hnd8fbQR2bWbmnFOCldjMzstY417/Z8x3lN/eFd+zH38qi F2PskuXqI6qtnPddf8qXDoOzCwpOvOzdAKnYVkYPQ0ossS9RGesYNzhNsw0rraS1QAMjGqHmrSjV 33cwp1kaJxGd2xqLoSWxiHXZa9VGy8DLugpwDNPs66LCSeRHiNsz6cQh1lmNxjwWQENkQoFaiq6v x4ugGhQ4x4zMVFujwMt/rJrQwSQZmDGoHahVMXlcJS92Q2NkHrOotco1jIv0m49rGWfCUYpIrkcy 5q+05FvuSoHS3tQtxnCKc2HWvlGIQkskFO5ZRXsrcxidyWNNNyMrNRTQ/nXTWFXRDSwGFhMkuBql hJUSm7B9mu2KD6uPDBvi3nDhLdgq7HP7xGyStkGTDpI7sQ2CBV+f8EoJeUMmLXH+eYLhFnQAeyYC YFsbMRNB+ycMWTSV2lXaFu4mz0bGNQX3S6x7ofiGfttGx4QItGWGDsq633DacXELXATD55Sq/bYg nQ4w5KG9mjH6ze5IxWHgE0060oR55cAEQcBabavTD5VP1QA9c+s/HeYwyIKliRVUBJWA695yiAfz DicLNYd6Ywn+E2uIauUQyJeqQEgv05RhQWvFQMyWirpP/4FBn4WSuR0JaR83Ck9IKgABlLdLqF4G 2DydCqNzZ8kgV64rSNKQNgHwCpFDqyka3h8AVdociMGQquWogEt+bDKSbnmmfGYrygdkuZwIZBLh r5TCh05metiHUg513Mt3F/puHO1vjIhXSpcXXE6g7YofOBRBMExGAcpnayJmoykTQwCtZbI7mOIp g8GlkMSHknC6RxZjIZYwxABYkgumRaKXdcbmEwnH2ZvsQ9ScC1wNjgFVqgHCqnMZlZuF6JsKB6os P6D4CTzOAEPuSLFKMS4AiodrihSlR1a3i2Ugn3V943/6A8P/HoneWzFefmgl6hc3ai6C2+z2Spab iKumznmvaL9PipKLlo5QRxAsXgutd9RPtBYKbmwBKbhq8cgB3GncMYmdTQpDHcKo9m4kF5LRMc4E 0kFoUEqIkAJ0E1GkgbhqB/gIvJw6E4LXHanUamIaHVY0iRDiumhSSiD4dpumk5DN/gNNKVAoSBs8 jMJm8tyTsJ/xSKd0jqIoCPMSG0DLsPlz1CAuShdYUNbBLEAOb5hclmMdWgU5PiMJG+6GrrQPpvVu 63NR+x/Uv4Yq4mU84t8mqYWSrCHHZPbUtSNc+kmEGGWQw7cw9gYwUPvInuYIc7hcwKeVhLAzW25y kh4cqainI0i1jVbQWyWcGJ1ZXfsDLM/rYBW2byvR1ByN4wFy5AIGJB4D1gGo2MSstmCoyvMN0U7q d0DAJWlYVhNhy8rL1RgDZdzuQ8PJxU11JAAJt5C+3softj8aVlS/1UAkZw6I2HJOBoS8Y/gA5qwj ZgMwWru774GuJEUxyuy781AlQLJw81zQlYOzolh5oEEvK3Nd0axF3jTyQCA7cnHDfcm2xgpU+wJQ 2qwIL81CMA9S1wH9BfGxMoGkiIUxmCh9EidCJSjaqGV/QEhhjINqmDBgwTrwJHVHT5RlR217qxh+ xdlTjynXhTQBSSljCgec1CuNJcKJoKRzkxv0zfRL9xIo98LYBBYBgSfQJAbJ7wHfHbJxjTTA4ni2 DfCG6z4dl+/k0BKP63GlYQARHZhr1xmQVRDUcZqy09fdT96rjbNE315QSB8PJvbdqSRi7AD58qWD Cg4E5Khyyej/xuaVmw9pQ2nMvTUciYdrjI5EkQxAfoplo/hpfaoXBxHfYKu9h0neKJmJK1SdnJWS uDheEpCaAitdu19lXsefNeUGUyepFoxSGltnaAeEEmEMBYkupH0gbINfAw+kw+B4r8wL8sCKcMPH hxpI5QbeAIwI+xl/WSfmz5nOq0YjJhSMbTeIAAtGH1PSOzLXJSzzfJlVdZ2eWY0G1kFw2Ie2SwQ4 6HxKa45VqTYhR0Loh9MgQtslW3KmbplWDDzOb8p5yKJndT/tky0w0qYppj7XypflQedWwQEN841X Izqb8wiv7r7Hw+UlnYURx6L5Idcyy7gXmXhYb+kSs/9yuX+2amCM0K+3J20QyCuSPgwA+wkynnAd jrklr+xuwjiXCUamxlAUGwynNLdEXFBHgZQwlC8PUDA7le5E1bws3gVRBK2wJ+YKs8+bBSpKxOhN C5decCq7K06N3IgkCtWBI0/4iR/snkeWiK+zjSXOB1cC5YWxD4VkYmiVxwlUmzJhkqjnX2mkZONh AVumk8CtRbQjbUUs5uC7c1t2Ig6y92t2KFcpVi6Hktw7Ogvg/pVZed84kRs9fnYGAS5k+RHn31DD ndygOIxuFDhvrS1fy9du9Xj/uvo+tn5o5vlH/mg+iutXxtFYqD7HPJumPOOHCX+XQxI6QeX5qXgv 03Oih69gTJI4cq/g+imk62PcfSNhbaR4Fz4wPHg04cqtbwFNQwT7VuXvogW+VFXB7gFigJOdX+OW 3fJzc6HXNRmpFDYPzU1wOaDIXZOFcHtc8SHd9eyOc+3xKkx/m4Zf490hSurP7CmQlbfp0CSOYErN 6zRQpkFvktgveSxrH330x7AC9cGJTSMrPgwgiSvsz9XjcsdeWaqBUi+jkhJUH/BRhzLnbj2l7ZS3 soMUa77q1wtLlXnjroN1xZmRVTQHwLCgn5wckuryOq9qHSyofQmm0dMEjKZ+b6ZoCOu0MpDn6qFZ lM/5GCmkKr1wDVyo1pc/IPNDPmnrLrdrO4dDJy+F90DOWD6yXLLHYKSypqJgLhNOfHndUrtKS4ro OArc20NXpXd/ylKRNDfmppBB47RRSd0578rZFqc2Q2K+SfZFCHVo2l1lXt7X0OA7B4fV0op6Ypx1 +Dosg6oW0shVfaZhHW/MjnZzlaFrgPaUH82Pvies4Rp4UgA/jIlfdtiTgmdssEseOk6Y8Yd97RI7 1C0OjM+lgxH0rLiriIE1a0N3yoOPmlSWwpRFOIIT+48Kgb3OjAy26Z4695+5PvxlaufZwgMmRL3S ImXP81Fsr5OQ+GhxkLBdwaet7whqnyybu+iN1lJsXMEltweFUk2FOCPaWwM4y7ssdxq0OH+A7imb fse1DvzpKaJ+8WH2CywWcZ5Q3kDOYFShXDgcR4wSJL5jexQv4CO5ZFTz6N5c8Pf3he1a2UpUfzrS q97+3DLKbR14ghjDjKPc9t2qbOdE+wTO1NneRg1TqLQca3mt4hAcf7Xh8gt7Yze3D48IdN+T9UUD wF6oLcKMorrgnOAXX1fpcRUOEhHUnQvHVMraFZvyD9mmqKNZkvGMD2qhp1jvq2DsrG7G2aZXFzmk kz6ucuc89CxZAggnjtrn60itnzfuSjjw0ekJ3TOLrlg9On//smfO8vhu4r7A0pOHJ7DcsKzf+zUS l/q68uiRDO29yoxwBdr3BpXRmdA4QDrq/xNQ9oQ8dgtyQnbv4YUpWaCQSe7h7cpbHdYxo+1y0VnR SNz66K2afcJ/DSuBSghFk96yVZNOfP9YSj0j7YXul+juTyErSQaCYMUF1QKEIB8WF3XfKNitVOkD IFHoHHC4vUKYEN+KWOFno5dmSzB7NCj3I8DKIo1bIg2qzJzQZPGgoo125qQ9ZFxizWjNsORzfbLn MZsyWACZkhHNKlBomE6hbUywIabw1LZQs0gSriKErxP3qhtqB1IGeXmYTbIZ6Q28hxql4d5MFDVT 6NTbqUmZ53oeCbKtJkz1myeMOi/HfXg9ty5HJoqYq3M57G8LEskbL+9k49DFVLbhyojmn83WEUOT qTH/pDBvvkqr7e73UHMF7zYqixKoXO/ewr+XB//ZeB47TwvuSfWVARrawJh6cpmIf2Q1a9it4ahP nzOQLC+I90TuyPWu6e4JWIEvzdG7fGqUp3eXH5820Ct3z1RgayLzSRbUZeEz6m6T06/90Pza2yny v/c5yL/ovpAyIHTj+yby+TSrVxLZ4BzReu6eg0NPNRL+Svc5jVOj4mt2LtqY8YG3EU3B3c7Olbek ik6VyfqzsHYadUiHP4rw1ASu+eNbk5ccpz2McBoD0aYlLvxoPosa/FsNMUp+azH2yH48Qm5HeyrZ 4mXPku1aWPr3ikBnqkvSpC7TyUyFcHF+g5MKi7KXk+QQ7ZHBcNI5NZm9vmRD1HuYws3q20Ssr8Tn aL3s09I9/f0Kftx5NuKSM8o6JdjR90riqDX/jdUvx1cAOfNjSnAEmvz9b8k4XMQ5g4UEgO8CQrVO cvZGItbxrw4CucplgS2kOLGeDtLdYsptIfjkPNJfv8/Y7CQt3qWrJy7BCZ4upSidW7eKext65LnK 109otsNB92s6T470r/ljW/KrwybHtg1/fj5XEUMxsoH5XKwsqid/uD9/lu5/5fEyS8jMyQxZu8xq xtfIf9SuOUt2T+NTbZfjmcfr6F3I1nsHSD6FpjpcLOEkWfp8r5n7VZLYe0Ceic/AbvFNMQ70DgXh po1y+jPq9GLR22+64+Xbagu2jr5XiDYAw2pQjd9hco2ooJBTv9ZTnZWYyzQA9fiaafHfrGdtt1h5 hV1HyXE/7A7IYzhzQ/Mx/GoGB5BSdt/Ia46pI5270aNwHZB3o4saQ5TzaVbGAUB1qNqftGzbR42f MegKU8aNH+4AcYOgd7eUZTa8l7inJ0oveaDtS1NdJSfKZbiwxJk+5iOSX0x15/s4gpdFE6HjjCz3 P2S7VX5urNLhqm8c1AoajaMHDxxQeuZ5mtvhXU9aG76sRd6xaL205jAaHkoJn+4Ak8jVZqvxeMCJ K4RJ0oe8unsbZ5NrfdPGV1zGHR9uNT4+uaGCcDZE+gdI15LP+dGX//JqBQuApVt04zyVz4M0XmHZ AIF842IZomYvu7F3nw1ZFiGJvieUuYBf+bdzGY5/3nrx/6fRwP9l9uf4R84lB+f/msufg/2/c2Tw L5t1OP55x8h/PDJgZ+fk/B9GBjq6cbgj9T6Yed9McSZ5+HJ+cjNgwkDrTk74RJjtf4Z94++FHKkv 9S4YlsnUI798pstz4q6IvaSo2/ua3bkWNxcfHSs6KkZqe9bxrwSqlsL2EP08Pjd367S27ewi3Wtr WxW+vX0+Dy3v3+wr49zjKgc2n27j/Oi6/e5Fb99m7HVvHb/vxFU9zSPjGPXLJJKX0LQqGziGQH0d vNUtSmVUqHSTVVVOJFJtVdhsLSs7mMZ/N9MuMeo3dbNBCBrUWcOotivfl9Nn06CV/dTG2ucWDE+2 kj6GMXaF1rLlqq93tXz9mUrQ1EJdHY+j2kLkWvGzRTENZBLHwcQ1v2r3wXs59NdtKoKg/1JzcQsL KpYaO9YBoOW4r3MuQHw+haAWV8VTALtbrXoPqxC/lNRxHQpzB1flbDxFfj9i4qSCmp/gBvcFolot 48ICTik+1SlLo7XjJ1IxCCYaCUc5iCNuEcywa18pjkI3Bg2fZhwlHH44u++IGiClfQ1DASmQbn4H /bkKtBqZxHwCQqyiYIMNPdJPNY0wS3Rv+mm98qaz76nOiyr1p6LeROkKjZC3zGoAyD6kqKWN5rmv SKy7Dg4ovgl0hDFzGPt5HVZ6jZhEMgMtk34nynARrSjsrOu8DAqLbTKU/31fyShUMKjjDT7nRchy bFpPEPqJirp08LzaAs9z6SsYqjUoogEWz7w3RQ9SWHkeDBY63IYH1bIjCDOarifj8I6QjjE2Xx9d vlqIruH+sAEP42ALvWqdC+L7Ql9ZXpmWTSoieynmBMfPGGYmljR+D0UW2/1B8huImtl3WI37PZ00 SU2rsbIMG2oH2yE0XkymG+rwTksT6x2Fd73eiLVACsEPhERYvULDBzWlbK2oZqxqy0w0BZWombFY 7YxmS9kZ7c05DTlrLtpU/2/tsoZTunJ6Oq4aEMfzE0kMWIs/yIAVK4DtEFVfRUja+XQgOrltMyZi n5t1SGmHDRNalfAlHs1Joatou+aHbG4QT28i+fjNj41Rmvk/azgfi6YySk14ZmtqJkeD0PA6qlHa SC91jjit6NsBYvCTiHOzSxESda80LxQlgdT3YRLgo2T1F/Ptyot3FfD3S5ESIn3g5kdBpb1NrSB8 s5h42UXwQKAzyUxQAtDsbDxIwOYV/iFawdb+YmKCIqUoQgV6QB5IgeUV/m2BJ1lYa2ryekGce4hw KxpVR4O7eTCiTWWgA2pEa9jKlsemPjawpOCx1pFKRbPh2LwGhCZk8aOQRnHoAq8m/Ut5mDWnICVz puH3Lii2g8smhYZ6Fr81YsmhcSV2toHWR6vLxdAZNGIw4FCI/VWHMcg7g0/AFalRmF3SlxSR65hE IGaj5lT3dsSogEMqBqSuMsquIlo0NPf1gznUi75QPyKV8tmJ2Rb3VHpRay4HGS17enHO2kH06/RC SWrbrHdlVOQgiCOjhXFSatcNppuxyLkQ2yD7lMahqJuRmTmadmmgmimeMlqeBeVDDCE6DQw4HfKl QSqhkBF+RhSIx8bO1SVjoSIDv9dJ04kY4WxqIasOqRKTMwreuJJ/rEn7C4sGNsReAqSBqU+ogYwL jPbBdHEjvMejPOCYuGZBhne8QiFOwYb5u0TnO1Cg4yyGf4tZ1qsWit/Nwl6C2k35Q9UGyWlmIG2u wFZ4LOIy2RAYDnkmoD7CXdcJQAFjAFlqvUmvcAyGb9vKMVKOewHYA0f0RJpMwzEa2fRaFMiKRPxh u5EdI1u9eGKq+RqxUQYmYzCNSuTU3EQmq6wjkAY5prxlwpHRAKnF4aTSd3AV8GnjQCNixejmSOEW pyxGdPSiUsLDOAGeGfBOETQ3sOrIiGhA5lW7TC+kwmQJDubXQG6ruXtgiDpjs00RfVlYvOjeGKSm OKoqP1Ps6GwiILXyUOkB6NGtkxRQcsQmTB9gpeAg8z8jcNkbwamEwmSlGji0l6MrQbRzthQ+mVjz vITT5YmERQeAdKyhjUCaMl6hfyXSiSTyDKNKzsRyYqZrkQrQE1cmyLGu9wcSLzOHy0c+7ZG3B64O 7OnMqkAuGywDB4VHoYzjGUxApg1LI9RVBm0ZgManDchbUTLFVPMeiwIhJbmuqPsTGg/q4FMAnzDb B+RyGUTDQ/MSTTB3Wga+WkQuqyb64HaAm8hswwn9+GMMyoHE20c+4VKBbO2IR0NNBw/tf2rAJUcU ikg0zLMSWzI21tfbJ3A6C59EgMlSM81/8iOLK424K/HcCtoBraK2c7BXqO8ARMscy4rma8It0dio VCzmr9XPqBlptQkaRgkhTPECRW+4j1aGUjeY6j8Ug/V4ZVwNsfAXFT8YgOzFr11jDnQbMMfkshAl iYT48OYWdScfDkI9L/g2wx+sUUE6hcgtsT2r8FCyann8WZvFmCHLyOiYQNjEdcfyx0N1Ko7UBo1s yPOLl3h2PEVvynY9yEJR8nq0Ipph6g9qs2RkHIQaTtb8gfhODZVywvsHZ0tR521OC/vAsFzDk9BD rk8uDPUuwBiOT7ZmhelHKEaSUEIpRAhCvj8fJzBrv4siW9q+/IEUf77k0vDtF9PzIap2tIXKO/ja 9r8mmy9XvNxPYF5j2F89TVSa1evpLUYdm3au3Md9zjFepai71evqpQ+R+jLYpagjxNkqRGwTpjwa oULdxA3c5Q496ut1v9zyOCzc55f1UhztbxaMzj7x3fcq5+bR+37Qxu6mJ70/rw8YvsfzAp5FSEhW xRRjNVmxmhaYlulq/Mm5FtCWz91hVU09XKV+Gwj+qZOGyFrNTC7LXtW6fbPfWND3ezmVUyKPvgc4 K3dBHbkiocuGXxvEdcbdzm+Lz9inqvNYWNOvBZrAZKpgewdq4x4LDFRmQGmuJwH6vbw5N7c5ZRpf LtNlNy85EDNHBrp3BsIuGSiF4B9ExKLNV4+lsAtU5t7RMT6axuAMvMFZhkCdbEbL1ciLegA+QWPO kzdZkFBjUz5ksj5LRry/loS88HVoniyCZ+Eoi2qTHF9taY5EeYo/I+JvNGxSK7QuLMQ5F/YQDJRu poiJQll2b/n1x/Urj4vP9LbtTMGGt+g3jXradzNVCkPMXBvhgisHQqPGM2dkDg9GmHbxFU/qe7d9 HXmrXhABX4Rzn9SlaJSSfVFifQdO0l5ysx+/Vm+/coYfqbx+DR3XnRsyvnvZ7aLmcg4pN0fp13GD pjZFcZo4ddS1vScs0d85cP7ZGrjPaZSvf25a1SAzjem2mZmkPbKIq1oSU+NtJuaqOWW2fzxvMADT jKogFMHrE8wh5FWtVTeUjNee1lYlXew22arC57xEvvyKCG3oLrwQpKvNY9ds8ye/jZP8Mgukv4KA kGyRavSZFFYgTV8RB9SXcRfD2ylu4D9NlDTmTPVCyUqBYwjObY057NgSfoiGRxbblWA80ZSaFVGM njImmZTKkVLGCb3nrE2CJ0Riy4vklIrXpCeOq3Gcy5mjN9zLufHNJKEuNUhfsb1IlYdiHrPZis0R QmisCTCRnkEHOyl88bheCuy6lhYjAPPQh0QksBOPBlTr/XhpnJ/zx9d5oChlo09eqzKJ856ffqGQ 5+xtYRrjodTDALGVjRosaOByYN1N5wR+0+OTD7XJrev6U2Xssi3YQxn9JTg/NfU2yyuMh88yPYjX IceJRjJIMZjGY4/SHlxoCJE7SWW1mUS/+/ErRixypYewV6CsBmhoviLOtRJy1QCoeVOvirJwXboi YyyjD72t13PAAtN71yw9FTzuq3xne+iIl8jeDZCa9WlxXF8+4+mkynx4isfsGF4bWM1Sik2wptMh i5xVOo0LFVu0pQA51RbDu8uhe3YoQk8mG4ja692frJgbsBz8BLk3MwDqQxwZlz1WHLFkKBXD4e1N p6bJXZe2XgJLLDqG3KqMHRHRKUtxzp5zfBz1NDlnZK28BoamCxIWFHXo7GypQ3ZPPkv7RXlV6t2h zOCubrrPuA4HS62i5dhxWYOICU2wO1N6TECc0/LBHPzmw+y/GWawcI+hgoux0x+Y+Wn4mHNaUrRM zE2QVaPfjUqqqKFEUAmcOZeHvrvsj5U5ahz3WhXnlibnA/loFhzBNt7mYp80KBiVlyHZblJ0cf6A HSAJhg7y8TgTSKAk4BcdX6pyr4daY1Tf0ti5mBrV4PTEnMmDn7nYllAJBn3pMel5pmCsqybaCCvd efqD43lSYCmINd6TlwR2ewvVtnvSkG+/wI0ak6+FtHKboMwL/cJ4dllgOHLbQ7GrQtrUdogm3bi+ qj4DvWnz6DBK31edL/YuMVaSjqEQV81DU7rqU6PmDxIsKyy+6O23nM24lC7fLi+moQayvGX6XVsF PHtO1WoohTnLRRmNC5rFWbrQgFYTDkgMN6qF0ZlzHfK8HpKF0wjtGFriWDczwZBKUR0zId+e43fM DvJMKjRBOvSZgX4jnC4IpQ/ZD65fW/oe48tzJd2jaB64QgoYnhsMA8Tkee+e9EOZm94dZb8EpEpe AQCwyl8jlPiYeTzqztVwvKFj/lxlU7jebSroEvA7+jqgdJVDM6VnTMbQ2rENY2DG4R6LE9J8YaGd q9fp3+7auc2GpLpZJkcRY8FUXrSHMj8+nFWa8yNQFJJ1U5KJUudgXsIKIZY7XlGOUydRCczFJiFY fSjTb9rDAtYvDUR8Fmtz32QuUksyCIC69SkW+woE3fExIY5VZ3ihL5c1SuaAl/cC7jXFgE1OKgLH iy3FrpCMwXuGyckSF5tsxKLvWKp22INdUhx4E+xFCfP8jAh3Ei0OSmMgM8sFtQWLNO67wnJFkkYZ BGxSs/H5qhCcKH7vlyWn/rpOwvBqWuNVQ9zcCzBNO7Zrkg2JB19HOWWltH27r9HlQyOOyxa+pmFz 2jf1UO4ZOUFHrFvdCrh1gqclSJtBRNNehr5k1Ni5zMQGrqPfkIXAb3EGRRJc4yAgSlFdvJgQ+lxF GpXRc21QNmdCjA7gIiP6OqRFaO6WhbJ5uh9ehyY2gajzy8x9Hw3MtIQ8NDmPbiXXcl4QSJBY5Wfb CnbDlqfPZ9i9GWfcQqPNKS8Ka0FeP8fN++gazS7UbFAbyxhNZzboOutwNMxwrKtjc6BJhh3qBLuh c5tKp37u2sZSXHnKvTiPrluTWZcDrCk9aoTXsedGUiyY73Dnf9r9ujp5UdVF1dOyo7wokmyUJ7HP VYszFm3MkDo8wSvQYuyXyFLsEvm0iXNZI+MPOLy46JwQG5noBBAjzdcoFN2sHqzeUWixeLMO7p1S 67E5tvHybdvs/fWi20Z7dpKIxxlAUs21f3uria9pNQZxICWPUM3FsXn6PPXiXdpXSFk6pg9vbXq7 OjO8IBSQ1sfYJ3w72J/FpC7Qkqwpd+BrlsXCOtZfgazkEN01zlxMQWi12Gsfhp9u/uUEb9denTKZ es0yZjoR/AQs9TS1qK7XWD5lGoW75Z42a4Rd3TnoseK89TK937uC1m30J6p99au/RthcEKAFPQP7 IXdOpeQ++iwX+XjZu621JpxEQcG+kpurjy5KAojw+rGuaNc39s46keAYwOcuIxyczsQLc81JkTvj njj0HrJRHk+zmfV+o2V8PoetbjPNl8BZDvLpW+JaRjk5qY/y55UDzd5f1S6anpw9vXO4lyZNJuzA WbJ9MaWY38ypJG5KJtht3KTmYZsZG5F75ECK9lRrW/+dAVFxt1uHjcHE+piPYhk+xR7sg28+XSXc TZKUsUbj5szvr379YMJ/TOTPqgdXNvw09RLAc/v10Mf76Z3lwYb35ogffZF/tnS391zVveT4Ow7U LhRl2YySWD2r9fkKVhole3w18awxjGoUo1ISuooDbVtgrvG+L9nPzh2qigO6ajdnOiy/lM52hmon GCgHrBFPig2El7nxdULeyVEgH399zTGELOqZZJ0YrIaT7wGSTO/Rv12QUt13cY6RMcqNM7kmFp1M AkWX+/Swa9PndJ3DMsoYQFqXa03VfiLvX9Wtj4iOVB4fSz5WmLE89vvhJ+Z2U6x5gUkPP0u6Zhbv 4kbTJvqTY0vbic/PeKzKcHmGuZGB6VTshfIK97CmD1mDtjgnK8ERqUw4bmMC6EsdjsT0kNzRV5eU rOuyG+BN043mv/4TPOR29c07v8B2zVgEEMA1pZJrERiNEnLdsZzJhOo9dWfcHjyYpRVS2nHPMje7 YDw8IJFKpYN7GELPYbNp57kJIQ88GNcB5Dvbzz+WBgP8dBFA1VGhsnuiOHTAecL4N49/69K0r/uS wDg/QAnPewkMmTM48wK2oxf3BYomQ104+0fDuSv3Pq0EQyP8VSu/IJRdGqkT43BWz74/kGnreB96 JnZ9lfkn1gEOAG87LK8tj8/TflB+xhU5s46mZZptzebTlQ/gzt1DQPDTzxLmQaTTEv0sS7x+8Yam 524Cko3Tn4WC5mKrw4elj94yQ0Odv7eqoDcXMp3PXOgFEyKIvrtbK1W4YacymoFYtWHSwDYmWFKv slRCmdsbLchzn2Jlw6zmfWYOw79J1fcPBxxIxov5q73d8RX4PV/JNrnGvsrawZxQTqfO+8fNW5Sy 9wRrprynTNF8A4cVeIwZ/uoD8S0HIPNv62ojfi1Y7s/fYg7y+SINMe7vG75upXhb5Mz6qlAnEqJn jOn1XIG0ttwNnZHrNDKdUkZ15ZKtohYq5IvXMD31uW/dRXs3uzvyLuH6YuAh8kR+iXVcHAr6HnCn GwjMP7Cmm5Gnns3Lsr7ryo6y7RMfi6HO+3qVYM84BaiM+RkMFA3IqzHMO/QpuqAWLkAR/6FmWwZr NLKTzMrxzwT7ejVzXTFppMn58WDCmHRTdyYzqg+K93HULFc6daRhzrIuv0zjHbwe4dV6+mnT+7Z/ 46My21eBasin3uz+gcKpebrirkdfSv6AerqrlKxakZBpNGKtA/yaW1RHxF2Lp3XdsVGUqTb0Sy5R 2FccPPgb//cuaBLqZ1TSKydBLgTkWmT/HBivH0T5QeWLx58xd8k9/PfjTbOC1MW8EZVlPNRr5RbE U+4kNUA+16onB/1ZgcPVWQwPirEax/Ec99B1FyUEIJIR6LZFHOH3Ieq9Y2gUDSQdF01uNI8u10uL vQBjjxWXpSsN/Te6/761X+rntiy90JcK+8DBwO/T4qG258qVBfo6UAnarVuL9SOX59b5Xi6vmnev dI1EKJ7LsonSa0rPwUj9sfOT8QC7u2eWw8xDS/3Fe8GRwYgD1M9XovWbHj2m/ENXhpFaEH5BUwiL 2iWbk9rDe9N2OqeV+zAQg8W7tbOM1VsrxnqNL03v7s2H5Z8ctTB62gm0RnmbH1HzVUDKHUZRg+5g YdrDw3IBmFC4hg1Bgwn4Mu2Dxh8lZwx9I/25YDbckbEtPiSomfifsIzIGC8fIZyIMJqd+kIa10sz BFA8ujtSRm+TjDa5vh+94FwBJJNuI/Kri7sI0NspPeB9Y/3KvW0wj4G4CFNbQLvtOsWVRyxceqH+ 7CNFkhJv9uonIwP/fo7+X3B8mLnZGTiYidiYuRnYuYlYmNgYmJj/TvNiYPkPHX7/ReoY678gnDj+ i+QrVm4WBi5WIta/yUF/p34x/59Qo7/qs/5PpI79terf1P8XhBPHP6Nv/vfqCP8PPuif46j+v4VQ cf6DJcT5jywqzn9kUXH+I4uKk+1/UXrg/u+UHv4FVsXxzy7a/wQwxMzyPwCGqnW1/5Ye/k6fYmKE 1KDQsnrjSBVCMhhzk0eIT8LTECKwEVTUkZYRkrGTqsF7Xc69rsyQeY5nzVI1EiUxX0k96/BW1dVl 9Xzd3G36rNPKbVCv1fN156lees7svDhOvX6K6+n2fj50vL+7roxb3zxr2rzW65ne8v7m8Ho9zhV5 un255HxtgGN4/+tYwiJzzWLdP9d+AcwJ4jdRxchifG+qZ9pClyKerPo4dyx+dOd0KtLy9ZSJo49n l1dZzZK0D6q+RF89Fu0oo2I+nV7saGMj2wwHzBlp2tsbC8qbywjvuWakWVDdKkMq96dcQuU6NXkm mjaVaPHVyNLGDKANEVRZR+eyYcBFaG+wpMhYnZogVEctRGRZpoUzXgdH9Ke9eGQmWTuFrO1gpmS4 iAjaZElaXBcaHeLZx8y5Bw4j6piNozaleIpO6yXDtrp+Akd2EEuVHDDY2wIzARPNlgfCWel9GsNR k1zpq2mMpIMOUFbbH09Np59ttoY7WgNRbmBR0zXn+C1DO+/QYsAd2+QqkgJZ+mf04CATHJN6G6DB QweKBxmUcXjYpqBn/IhkF0E7WryjWoVq4a2wlQ+e4W6l/GpquA68KngDcxHgYT0ZMZb3QxErPVrM K9bWuXOyL1kROs4JOYTeZuLHDfZHq3h9ExbiBQWxuJzbDSdDmwtglY2jTV+NRcoumJuIrpa1Zmav Yro8TAT0aMS1z3oO1o0LCTQ2fZxBN4I2XGQ9pS0O10QABzMNQh1jsJdKpC+EV7seEfcdh4c4Q09E sJoKvSZSxCUVcyeII+RItflhqA6DDQubo+zHTSqgMTUj20IHKfxWBhbXXyofH8LFU2loGCyrOF+j KlAG1KfFBjsrXI78dRdxJ0sLXhUNLpirGt1218WU/KIcpp5b01GO1dV0dQ7il1CxrjhQPDVIjVW9 yp8innuhCGXc5QC3A/hlSWzhOP6HtipxauGKEWXdwr5+MUQjaRxQLtuDyA5TeskHJkVbWAo1PPXq 3l+JB4bhbJiUZmIkTfRqu/femv7o8Rgd7ThcIujsC6yQAgtGGE0UdHg4hz8D8lMQWqBX8pxUSGYX lW1RRYWTdYnjB3PEMkWWsHtXRBhg/uoNbTzgTRlWt3chppKogI6EtV4MRFnQl/VGK63PSkHxDzgx UnkDOrQ0zv1FA31SlF3a6/wdIDG46NRvMEqoLOQcWABKyk0YFAh2XPaDOPnXLWiDjyGJ5+h5MjTc tyU76AfBsJRg4PjoBqLkEIS0fTgg3FyGEXx3fZU6qRDlDtN54TAiQti1WVQWZa75PAwnGGS14Gx5 u4q4YWNS1Wuor4oVFGgmKXX5aHATMXXAVZhC5Cpif0wNJIU1SOOBwSn98inRlTgxy5e7+6RqtJU2 Ybw1J3VVD4ysBK3UH2CaIyFLFDIDrZyuiNx+fE5VS3UMks3qdZAAdanuDKDI0CTNyvh6nOWruDKI UUeZFrcdD3rj6UQ6949G8lz8rgavT23R5IgBnVoyRM8B/J0+1T9M5KZd4e0vthM6I54dDsU+JeEi 4q1Fr+66f5cHwsZMvHAWNjNUu64DtT/qum+TJZ8MSxNoLaaOBOfDblosoca21YPSl8DqioTFODYg 9CnNtVGYblxnKK7dtwu56GolpRq+DKYASwS+MDgbLSOcTNJEA1cMGvhSQOJFbd50V8wCjANk5wmG IJ8aw94X805kIce9o65K3UvaDglFC+aiQ+15INx0C0KiAYUtpWJkEWjopETKMQySTYKBD1aAN1Jv 8OdMNtx2dlXnkmB7XLkEhD4YvIxspEBZyBPupxUzBHBEBgf5eGAueHKeFxMwrRXqINgKUgkJx4kY AZC+G6gzXWFe2kBMN+iKqU8OKJ8DhdQqLEQSCBXU7WoFA1ZCRdgabjY9ZvN90730Bkv4bTQFm1PB RN67UmGIk5AfXwKoYFBAjl5bSltZyYVTIkOv6twbNaEEXHF+smNeonoAylMsE4Wi9ZheHFC8baX0 oXq4KWVU1M9qlEyMVNWxgnxGdMrfGiOaCoZeTJm7aAsEasg/5eENgjaA5IoICh1HQQyiuMKLg5qB YdQrNwAvsf631JAOBFnQwhBuFQ3AnOi+4W5pJP6ZTfi0BCRC/WicJmHQIgwBJWVx5F6iDH9anVl6 Sm3V9pBGPdsgC2OCdhLt+43feNyajZJnHYDMesGEcVNF+EuNTqKFHQQtTn5Ma16upkPSR4BqP/6W OG4GSTehsZEABQ3ziP8pdIbiAVXdvYsHyktagd7EHErGphmiP4rOMGH8JxxH5fXR6RGu7g+kkXq7 MnMAvnDnH4Z8GuCrUc5eWLvUPXcTepRMMCy16jyEILiQtOogMWG5PAka0WyH3NG5NjdKW2dGYEw0 9t53ml5ub9BgCAsaQ+Bw6HK0dpsKwLAyeCoJjijdMBF4Pg/UlUF84MnOWm9Z75RBU30pK0MeWDMR exOnkD59aTm0J3AVjYvBgJy2/zGNRWEFiLwcLAnIPWirJA8DHNKzaM0Hncn6QbtKv2T/Qc6r/ZbP +9QEoZya+bVAL7AJ91eY0OmyjtoSCPY1EeqFHu1ml9NxhrnfX5+1XPvubQLM1sUpT0ftDT76s0zS HjzMwyk3x3P7pyht98aByws7R1wHzVZ6x29DpQ2bJuAvHnrfqa3Pmdbtjxt5aqtTKCgqIW+xkRnO Van1RIEtc1PqmiOA7dOAfj004Wprz2qu/HtYfbXXBBlpBgpr5AtI843RdhZrJ3iKgUpSl/a3t/Hk Q0eBXbsLVyGn16u78ttyq9+rwASp1VoA3G+YWdV+C9FGs5XpxA8EUmfnCZREAmM89sFllxv338+f ZoZ8nsLDlY9vlrt2CGh7VoYbU28T/ViftjPniFHaltpCw21hNfJ+XUnCB0eh8IgV6C/WnVCcvC2d EwLVGPLrNpgUJ62lvBvrJpWbm1Cr0fv9AHQUPgNzx3mFNJ+eATTC9oVGy+V3fkyqhS3b+ipdyb2j UVcyGfv2piRVBWfsGmb7RzWek7wPCme4956PP3qKUqBcAc7yEl4ePAjwFw0crL5hiD944hJsdzvu TQrEHrftJXgrzsN5K+4ICcXJl/qdF3Er+o/sAn9F41X0OamPOKu1w1aaToJdoz37JB8X+/CHqSbW QZ0OfuPMs3iE8E0a0waxs06rWXxODnGzBxKn5taLMApQ5Xdw2tX/ZNZRUqkPGwVCcADJ3CeVM/NZ 8z36nKLUiIK7EYE3XsOrEmPgufT040KacxGrl2/mj31nBgUvztgoyzBADh9PFFbXxJea8jOFpcKH COl+1HKXBFqr5m0jobN5c6XjXf+CrfGU+VaP84X0FPA9Tx8OiBsU6cM4XK0I66sJEyGP8S2tpLHz JdBMZwy7kH4gPzD+pIHmDf2MXJPq0a+NCHuVJ9SupRm0/FNz/gKiX7ho87aIhExZbEruhzUF7JAH pEbjX28Hdy+yZusCY9els/ZEmLe++SH28EqQNDWgXYl7ZpK36kGrWZyOhio2aVDQTPUpesyda4H9 s+GxolF2x2ExXCgt1Wf4MZLnQywBb0bXtWB4L+KqgZFkcjjiesTigX2SjjxhIWv2Fi4pDCYkj91e FLB/dIPdQhTQK4nDWZqCXhNL6S9fw5NCb7P4Y0rUwrhBDXmIlU5yXc3cVtK1jCnJdgaEi5WgF70j 9wdpmxFLoEyHzq7dgtok3m0X1qV74ScMt1LkO7u8Z1XQkQZKQU1mVTm5ErM99Qpxn0lSS/3NlE1S s1N/PNxD3ZsTQ3sugXqnvIdbHSZV26Zs6GMDJoPLcfVAisrZTs0VQ9ruI+vqQJMFVpVVl59HHol4 W97R/C/S+mNj69NsSqvAaQwEMMCqzsdSl9EEFNhBIuaP0ZfD0CVPspKPBqxzczJ7ZuvyHMujPmX1 a2zssgbkW0/ETj8rfsQnVJ1RcxQSvY+MRbTZNrMPy519R8pGUKWwnE78FIL3mNjZGzrvxiGuXlWn eKwZgUj75OACx/kfo3eo8YceTykkatwxGkpx1lVxGYGgSxxblcY7JbDkazf9g5nVUVZ0Hi5rOTmj u50MTdY6G6U+lZRT04yrL3JDtLGS2wz56etimNcoq4TDnBC5svezNmYO4Sksabbo9aZFSUmgTZr7 vKsBg3L7XTxBC7scn5+Y4MmWCXdlVC0lFJhMRwobc+Q+Jt370PlR8xYfTCX7Ek4ujtuYn2oA+LJ3 Rf3A7FNdM8U45BiskcLV/oXs7Nho/9HRDJPgfHZ9N7XJRUQMVgLio4GSe1IlAt2pLAn3FEcVaMq4 9+hbC4RLqkOFPVeW/gFwWbz6JUs5I//Vaf4bOWPfCHbUgZoYfZzHH3IM5KesFSS/ppt+zT1lKHTI xFOv6cbKK2Oag7HHWnoVYDIev6b5Oudpy6sgcAoafwVBcrTjmo+lg0IPEI1QeC6T2YqSS67ybG3L F93p7cL54TeQ2vouVlEvd+ZpZRXC53UAXgW0oSdZ0gHCfG3nThNzjNqMNPjKDIiVjxHYMK8MnXfz bvjGjSbtvHsw3O5H2Lop9y9PdadJx102RWVEWhHRjiH8Q4tYdeQgBOup2Z34MldqfBU4TQTNFI/7 P9avMXxB8C3bma82bXnwteOO353Kl36UvMZ4uimMtA2LvU7x5+3nL840WjxyQanz3rw8479VE7ov 3ruh8inVgzLobcv9XnZD7ZMSGzOunsUZPrAr6PBVM5xKB9SeSoxqgs71rupmuvM238X/zMr7ptzz yj3tqLtXnKXO40istSZtUVt+4oEZ/ojxQNtXY12tUVC+6KQKHmHDs+AkhaUKu3btKPNA/SlLQcAQ VFKf1A6pf8rsImg6PB4HSJl6yJUwrpM+60i0W0YMP7s14F+ZBaXbES14rJ+njllKYlDnc5pLwWrg tXW7OfSRQkCOQBdQmqxkmKc+c9EhXPNviKALQOg8OSlVYjvNl9d+e8QNeASPuSB7N02bDKRdIWzZ I5evVMFNk1IYBDkMYesvhuvEC383Oa292zhoTDzPUU0d4iNo1DFbUZvZbUlFsSZlKlZNHSNqLBww AInLzS1GHn6iuu8OMsu5bZOR5Ps0+C46BohTnfOPQvmrXzeOa5dUnnp834bZLKN65YQyO1WIftj4 q7DotdQM+ldFlbz1GG5pSgeizI04L+hFQu61VBq77QC3Djr4QKTQLmSJPjmSzyYqRaiKuq9u4lLp ZiZpZq9VtX94gCztdD4sEb1feCRIgr4YOd08qkfgdw4snvwWVu4a4x68igRKn6ge50rkhxETzOb4 5jbEBmvqTkEJfUus+wiucyqHkx/FQxSWJqAqknnLlr1gOj51YdRGQ16vgXWXmMEZF6G1KEAmDzd3 R8fERw3VMkMLCV3OGOBio27j2HhF81oYUdgjUbeZCzip3+6o4Gq8rJEziVAUcBdey2pkz/lse+tX +8BWtBX5Dd4GtniPoJD1c2voAeg3wyEmpYJhEvBw60hDhMJajUfOywq+7NNrkY+fVUP6WgIHONhY HpzpeeYzioyVrwlJ3BhIadv9kSHv0hrukWni0ojxyK3xEoHYGUIjL3akNWPNdfWvHKwO+IvVI2+b wot2Rrm3WNOONqUWClvejOrJTc31U9SUCBzsa3LwpFAhNxYw6Q4dY52NJz4wzw1Oy8pFQ6+DzRU9 hvBDp8m+fWoQTbblj7SgkMOgaVRz7UPNdffnqCsorxTX5TcxYb5h1lgJmXL1TFG63A0oUKPM+EKs OC6t3vMoDI51cZ0SFw22zLh3u6DRmh7YM7eU+gzH+N4L6z80N0UUbVSq5Xm+XM35/R3pNH9KpinD DbRK57O7nlWhOhyvRymskUImacipiw5Y9AZZK6RgftBR4N0Q04NY7/1ugFcZnp1jKpCRsOp/tH46 9GfaFzF6tb057Z2ncj4lah2b90i6pysRT68n3aBQSGrqbsBUWNPjRtX84zM1sTvYbs1tDLMmpcxW 8PPZJ1toH3ed79piMyCYqbO92B+VMu7c67XmMeT8xEY2ya06enn/EHycT10dbjn5V6IPfzN00Qme MS+cLkOxXXTXgbGGQ9Z0IsXpdPKoLo5EHFuSo150TvwCHYv8WqxTfoO5rTExW4JoVhB1It2oBrU+ cfOf27ouii+VwFHfwi+gXZzMg5thEnbGGbWhAQSSZsEYV9scpewBNDVvhWZ+zNVBSypCTBrSztwE gx8dOrdEP9ZPyS41wikOgce4Crl2clWAFvkiMBH5enaafoeRmjuKELDjy5KxO01tdUzRVAjUihua bEtDNIcKSEGxe7R47uF3ecRXq8fRVS5RvOklWtopByDavllw/spYlUqIw0ljfee1Y+njnt/T+W21 gaBAEZos583TQsgxzdCdRqNzR3FJwZ9jck/LO7vPLDffMiGP8lUdd+pRpCeyEdDxNOAAOUexWQjS zCDaI+htWZjMNuBYzmaU8UcvZyzCx9S9yVX20EPHPfq4YUtwBDUY1mN2YZcMzaNGQloiqjhbLG1v Ltx0VvK6AFnSXdbUdckNZ34cWnaf9PQRaL7EXfZHqrVI5Lo8ONt+s7G3E4CQvPo3wXUpIor458/3 XFVkgyABOQJ6Q54qnMqRBNZ3TRvjlkEEDcBl9FUVXwHss0Z2AtnMM37Q4pJbdkQP5t71Opqn/vLG OqnIVcs+DY9op144jjlNyWOgb0E1lx/fxeFka+UYRkehJ4Lc6few5VXnNqfjW8kqpJ6zG3yEkqXI ky/d7h++qFRFz4sBe3jZTg0u/l6spbUaz6dvIKOtgtvvvZkojI+SFOYxyV+SEo7QYCOBYhdBc3qs udwBRhhBr3OksxFQ/gqMy/ONw5RjIT/WY8WB9owJxlZXmf1/4/Mtf+eqisJbz8WqDw3C3NUYqSw5 +3SKaqWolOt16wxmujgMx+RqQTxQZZbYv5+N5gPtAxD0wZEQN3EPHrt0aXNcrCGDbAuzZVtSCUtS jrtSU38Psukw0uyXa5fN6RGuhehD+syExUQ2ed3p9Nu6Th3fgtM8FchNM+jbVdMTnGr+cM6cGGAa Ayq0MsnqLiKxevdFQpHnGwhz83HdEeIefvJtBvwhzVHU1T6W4onawBvuz6MwZe8YvGcqw1E4lUJv uezPq8dZpij+67lLTJZa8xUHO3gUp7mlcmb59HYQvGTXY10HUab2cJECmCT6EocLuLZ8qUYkyzzC 3oGEelIFjU1GdrlA9U4JbJuxSPJ430cAQmmPFL2sOEXP9xNXjBDoQrT0CFFmltEBeGE83wX8yife q0xu6UvcmFBimIjfD8HqgaVHxDVXv3i5LRJZq5E5eRL2cGUIxs5JUDzXuBr4asHmB5+YvS68C9TU SgJ2F7izWTExeq4bvxsmS6WmozevFrkxzH19xjvlYHs7umW9QzsJWY1+hQmzaBB25IhPKT+A4F8R rl3pXFs+RHfOpTq7qAyOhRx6xFSgXqM8dui1m1CynHnDTy2eaZMyUmNbv9nzvQn29BpKuZm+U9p7 dZuyfuNuAjC8DWhwALgs9MnhsBqa7xc3AWnQbyONDR01DJj1HN4XYYS0RtkjqWLDxwqKr2fK5bT6 6FiCSRnrVgA3yS1dZjpaamuwML2cH50pqlVwRu1N1Hj1qZxwdGvHGYeVB60H4hirODUZdaN8T7Yq VR6tlpn2vwxa38uY4El16O3OM3VZIXwDcTfrL6rmUnLRnRwjPiPTan6i1ywpg3cdzI9907tzMG2j 9kL6sAAhPvEQ5q4xq0N2mxT+mIJOtv5CX17UnMewBqqHOvDCJn2Xe5ZojbxY9VJuGIvV2ds/2SdL 9qhKsz7nQH4TxqAPq9J5CTle/ASPYC9Y5jxuNo/O99XdGejx8aHNFZhxHplZ/kLv6R6WBXxDyFVv wO4+Vkd1BF+bgn14at/P7yhQk26k2Dztn99IQ5oqrMvuTRwdt96x2oNvVLxp9zkx2Q5t2Wc9IchT zjHMxZi8RqKefIi0REhQ8icjLP55fmqWVWulteGejb4fPnf92jeNbYq2Ll0kDmEeOtfWVRG1GAdG 9cR4AT7PVArumXr79DN6lUutwE0A2KXiQ9hAFeqEm11B77OEJGV1nViONIRsqxZiFsdGKk27KxaO j98XMggU1XxvkXktrOXI06WNEjwrcwjL+q869tDP1hVkn95mDLquMnIOmD/+wvPjaAfwsGdnld6a IeyG2pfInOaM17zx2HqhTGyZIzxg6lzTBVYn3DfXkqTFna0BozOyyMMvgERvTqR4JdO/cSpK+aLC jy6Uqmi/bBtsfgV5p2kG36vqeReeLSNd2Uwdv/4ftH1lcB3JmqzAYrbFLFnMcCQdMTNZzMzMzMzM zAwWMzOjxcy2xWCLpSfPzO7e2Tf3ztsb+35VdMTpyPqqqytOR2Z++b6PxeHBP55eTX/5PkSrBOk8 6UXWPpx4utY0IWp9xdMaX7fsA0iI/wYrxPWGe4bD2pC06TmjXPP3E8/X3cL6udhqxi0CFlNPzsUm +a3V5gV4r7KzjmxSiK55QBbDsbYhkySqp+U6EgW+AUR+RSzSavbPK90Fgt4L96Y5nC6dagnIdJsi z4xV31DVbxnkxoUNJ3xs3EU/qiDlrita07dIkLrD3d22rNLGIuhxbYmvddALyFU2obfhD7hqfRKb /cks3UMaIa1nQtvfy2fJwBWbuahh4G3Eyb5PR46pAGqz47IEDeN0i6dhZHB79XkrurOcHDaq75Ad v6uzOUnffvkSvkvdXyd54Ku3jnRpFX+KAyWTAQUZhweaD2cSg6ezyPnRzoVpvdRj2yJ8rrgteQF9 YiVLOeJnGh5T+3DbbcdLn+htXXcczNhTYxfB1J1xrBThJZ2HpuNC5defah3UT6WBq1Sx89rBQ/j4 ch7QpxWEE5M4CFPgrOWKsMMhpBKdCVrh9aQgsoZTQjHBvUzfhrXqC7V1Ai2JlJRAvGoYtLLMx/CU ds02cMWl+z8zek7qfRRW2kFb1jM/XFCVkdCymHAdT3MhuJnRjCGsTMy8nkWfzfmgYkcvkRT2YRl6 /h3lzTC34HP8Z0DCxgQ4lAVYinOZBbpvBE7bhxdkWE6QVaHM20n+VRzKRhzx3i9XiAuGWYyy2Y8U vSOHjLfx5zxbXDJckjMnGMcW5DWe0wJojY/R8B2YN17WRAIgapF8atO4kda1MllDMJhWdGleBIIH kQFtYSaQ2vJsM87pMdvFhys/lawZgNQCWzIBUZyBIXcUh3Gln9fceMKCOm7qMx6CSg3frd9OWq8z 1GVjnB7Qaf94EqNPua3WPkDPmYoRRw/dpFaHHaP4wQWmHVaeqW0qr7uUttXhO0oUand4D7cjuboB X3stPE/23gPXWwQOZX+LQGZCd3sNSRrSaJ7YDXXo7d8uNn5FviT8zcZgCyvtXH/Tu29mutrkHD+w QZ8KPLI5UC9Z04xpKg+6xX2Rm2we0ORoHTSdOspNIBtpXio/mH9O9B6SZiEqGk3jlV84nJXSZDDi mmP+aRdtRMeIUkB2rOh4XdnkVrxTYUpFNRTj4DriooY0wrv0MFTWJAwNcu3xY1rD+2lTxBl7tFn1 Hv4nm/Mti2SST2TvpHr50Y4td6PifAubG1Meu++s2NeE7KcNdGl4kjov/RqWB46w9NficUyteNMX n/rvVO/+koZm+7s+NwAmOgAjISsbMx37b0k6dMC3KyArHeu/y0L/Kc2G7W/63LAwAn4BsrAy0LET sjAx0zG9XbzNhYXl34X/U/4K29/EKDGyAOnYWQmZgW/VMxMysgHp2FgIAQxAOhbgPyXBGf8zS4jt L7oMMf+pyxDb3+UoAdjpGAGEzMxv+OyETG/4jITMb3Ni/acagP+Cf7vpL+D/1GWI7W9ilJiZgL/q ZgKw0jH8Sgd6K5/pbQ+8Df9cA/Cvywf8qc0Q2z8a4/7/agD+TZaf7XdCH/j78HuMEPB36h/4O/UP /J36B/5O/QMBvw8s/zMFABvr/6ICAPCnfkVs/6gz+ecKAFYWxv9mPuzU1LD5yJbsbZP7KsgtEdCi 2bFg5MLA5x6fNgrWa0wOeTUzGkCTsjbUQCoan2Xo8+y9pVcrlCwknv2OE9xRc47IzZVuqzW26Jie rX34cdBe5el+eknnzDniQNBHxbOjS4331dHres3B53ljd37PvNZD8/PLVcpuv4oPbfXrSyc1j9VW d8XYUNru/KNLuVIRS9BieaX0ZSASbjd1w3wRZWL1WDmtY8V4Ne1qdYOSFqbR2Cra+O15WzEAkkC3 xgLuN+8h9W/eQxXMeVtvZOqF5Cm0oe/vG1Zt9Q2O567K6HBmVpsaBMwVV/y+lMmvCOjBMlj0xC0E 1QXPX7dPTUd0N7yCNFRTNyal9dSU9xIeNfqFDCUh0qRXW144WYwFywbrVMjYRc5Gz8e1WATBXURR OhlJllwOGDkuJCPgX2D92Xzo8l/mQy67o6I/zIfStIqudQjZDI4ki3e4GmYNEwtOrv7IhmnoOnbT q/PYRPZNlvyFVGPSCnl3skH3vewkZ5bL2kHTCE0hG4Kthf5XHDyDyqC7UGOIqJi82BIW4+ohMOyb dmbwjrGkJNGDuIuVz/qGbe+xlNoqezxPJTATquFp+ZasYkkMVylRQI4CpONQoKF2t13WbT92IA48 4Vby5bTJE2dW5y+28k6Sp6oeuYH0z6QdMt8HAaUglHpKdbeL/ezxyJEFZ43mQxmByEuqkLIMkqVK eirLLYyp1Sj6a0ljGu7gj182/4n78HiA9AJBk+gOTtVioJUhpu5LvBzLivz2ajglIp3utgKyy9rY Yk+Otb/vh0Y36c1XmPjr/+4+1PjlPuRMbzST3q46M60sZs5Mkux5pVVcQUz+goaOq5Ld4nDzMQKi 4Su0tiVL1+nA7+7D3l/uQ6eP+P6ni7CyTiv6FKoBq+yKM6LHyfb1d6k8UE6+pJKJOwktcUrGuY0s dxXj0flfgROOWSMTYR+wW8rRmwkv9PYA1tRd4GHYqQSFeVUfonSvk26lpSAUDqGqrmLF9VdKHIrK DyqmpjWosWEgjrLSkBAginGoe8C9emfFV8EYLjRhArYTPgkWgKPYFl+plgq3QIoJ3Xx0pAIl+Q7h C0WUWn4VSh06FZZndbBvcSHy5AeKE7GQCcRV1AtFbzRZhhXiFKQ6xVYjWOsT89tL10elbNAfQlyG woIhufJbNgiS5cHqZvkaZMERU+aItcuVJYRzybJSmoOBTZpsIN4XjHLH1sNqb0ElF3StXAARIASt m1QrPEpH5A6qGC4Er1XMoviOJjIW9CbfMQkIRJHgy8NmiG8nK2cT0qisvCQQyKCWf730HiydwSJI N7+k3IZZct5NadDRRfih6UevSi8oV/An+6GOy2amBaOE7Zkdkn9BIoq8+Ud9S7P+JAxz6RMWrYv/ if2wSIRneynpwoIaFBIBZozD+YIKojC3BCQyLLzqg6MV6VWZyICBb282OgPkFjNAjJxhc4YTUEUd d4E/mRpPQdtk3iCG757n1VOFhbzjVEMp+SEfh82fKgoWEj5DVLU2aiTMPdhleQjud/9h+BbrQOj0 b/5DtrtFaHy29/m0gg2pRWaGj0ICVO9aZhqIZS5/BssYVASvwIfpHRaj/IUBMV0kmTiaYpS5lFWX Chz3Q5JMJj9hfsF4aK0jPBEElgXEdzPWEVKqaXpNYa5PIJm1wf3bMe/ihPoCOsGXjXzCP3DZkQrO k0E66J8oXqhFJpopSsuptdXWkOKb+sk0XMgwbDJlEALuY3sv9rLQoaUUSK2/TKDngpwyE42uWmox V8Nastx4fw9JA92AG3MEg8HGhtxWl0T+kLswITuSYIgS/4UxG+ju3NE68kX90gxGrcoyfQUd/aY1 mt9RviFFJJ46lZtmyo0bwRbBGY8htIUibwK0CRtpXnUU1LlxCccS5L3Dsvjpu+JapyNsApABQ7yf BzvDmIwqIeIg7hMa2+SImAZefYgj9hPW6jY86btOSYZbwdagK3Ns3J/kb5Z9fwzI2I4yZZkPquOG SMBKCoLpcmDKHIftgIfWIjYVmNnLYwKXyfHajOb2PIdYWqC4wz54MBeq2GvRgkYLWH0nYmT4xNDq u4gVvBr+Whuwn7pMKWfwdvdzINmhBUmyqiERfCFS2ctP90YGkruIChIKgc8BRRy8kdHmFN5Hfs35 t23KV3QrEftk1ZekyIT4iN++Exmz7ge74/7mQNwD/8OBiApTXQb5Dw7EBmEtcTkjLzolB2p9xqb4 GXmLU7tOUtcvtlzvBWFmdKoG1INUr1SmikiBhGqOWaIgyu6qiWhxOZgPjvrpeF5fMkAKEO3q8i/w sjamI7J6DnA3cDhKiyztKxMZAChX2ncE1pvd7S8ZVG27h/iguaUXPkqAyJQmU1XFb7uQHPzPqw8P SY0WSk/Pz+0x9Z/xm68rnJsydRbqU9zY1q5iTjvSuKc+n1hydzPVo/HQnR2qIMZo5Q4cyV67L3qA PdVnvCquPy09uuhsuUaDEYTDWhrw8EyFw1ttp0FIegU23T1oJO6kjT33uzdr8B6E3xKSEMdLvztI ZQngl0RwmNyFVfXPL25R886kzNpZIJLzfxbqp8KyNbZRznc2thj84bL+pdnn+bAiP52pOqYco7cD Mf/hHA/tssdHiD5jFytccyQHrvQsrPy4s27VzxDnktAZhQyyoPorSWucovv8eZXVF1pb4UGuEXgT 1uIpc5KabWqMbjagtkgNbZ6XQJaCv37iEmMVxRqxS+5Z10S0wnu4XTvttbVpBzaNjik04WysCEUO ret3Pnw1dKTPoOZM9edHzm/fiZ8+lo2MQlS/FsdAp+NlWRO3laTQujA7Hb0dmZxged/zOxlHgzI/ rB6kW3D3SuSYRtFXtIJetKzY1x4flY9NL2DuGjBhDJ9Cq6+B9ZD4/BiHkmpR3yP4Lo7+KNTyaFWt 6GxfdvFlZ9+Fm3yN2z758T6p7sqsO6z4Po0OJMJ/ijoYZFhsJj9a0DUX/PmiRL8xpaTwuhaIpR13 ynJi9sXj+ssIjanlqrDk83SZWyw7UZ/ItWem16VNbWvOLOPRmL0ywdHJjD4NTbFCihq8B6LY0nv1 2WMOTjBv8zYDZ7l5GlNc7oXmvMbOOei7U1jW2QlTloaBQWeorEUTxnduektnWYoWwDJ7N3rhxdWB AtjFGAp2im6mdszwAuWSfsS+CdCB79D65Lnq9QtAfXMXbAWDXebdUHFeYzlFqiPub0Hbx5z7szVs ujYJ1a76BNXpZx/5PpsuaEWW0TKyZEPFulNmcvR9Iz2pSw3Z1p87eBiFui/gg13TQaWnzlXhfkzD vBMAJkxDLIvYqB4GshduptgOV3ZKtD76CHwqTBvptSChm8LvLTtELtFvmJ0UXksQkU6JddfcHaoL eHLrUSR7jG08Zfv8adtXzBiExDQhVIgU1jzrWhDd64eGHiWWkrE4hNKH1RyZPWUBj/d1EzAj9nMF iKlF5RPp8O6ngU+ZDfqrDjVo895hnhPDCdCB4a3fvQlMByQ7sFjoVlx8o1J/0lgPNHkZlShnBICg z2i1yetviwpWmyNChCZ578yDzwqiJ3ezXhv3Td81/PimhTAgmFcvmq5z7+bDxnsufCIO2Z7VZ1C7 GVlBG37E0r1yVx6es464YuwT1Shcfrx23+Prqb3+Y9aS3Wa+CyvRNv6aFV+EMEHMVNY9Q9qcIRvO xLxGXVxQ0ry97sCliI41Z7fER4JgB2cLuqb+keUFxY6L1jnfSgIkp2rAyL4XQ02vY1mUV7j7hECn zINCWqp3wjpPOurdJvx0RGWZxvCUJhNlR5KgaZCXs6YF0tAzyGb3NH+pHMJxkCEfK4O5WRV5w20G YX6JJTAJ/4cRdYt7X5RQT3kwKxZY/ZW+Qqc4OtZVZUnELtLatzNa/XqxloYpm+89phtFUeBLEu0O lmLwVXTKTiWCooALy69iptMh4Mnn369stz23mNR3t8rG6VenP6WQNzRzo4x/xFXpfJ7Q1qn9aPo5 rKyXM8SWyJXV83UGqXW8MxAhOnH3EcP/8eNaqKAzs+8P8xwEMNUQvoFFPIdBXjrmfTPWjP4sfaQH BubINcn5CWSZCMdzYrMrXy8Jav8LmSkxTph8HuWgbkTBfTNqy/1ce4a4j6P51iVkdwQl5hr7Fs5M x+I5lTGFVn4s1BiAoQbppH2KI7+xBq5KMciDgqBMJZKGmx6ly5GngzMUTk1IOKrFxKFnzFpBMJQT D5sM7op8fkuAZ5rFhLt29uVdhyzXd7GqOYVlDKWKA5u9Go2XRu+dkglO9Ixhb+uEQrPYb7fTEQsU i8ZgTiGLkZ9i9AfvwZ/BLZTPEudW6/nGEoSyG05JPQtPGSAcksz3MaCdG66gvhsm4ayPDH6OcJyu N2TWCh3No3jeyRzFZCcKl2gKqYXlyRktWSGV3jeaEFsCUDBCEmHFT/Tvu0kzf2eDwy46lzt8z6c9 AiJPSpNzM3gWSE/Vus5yObg+K3Ix6DrD3jvUYAC48b2hZpMtu3tvENgzm5btv+xc0DNQcAb7VSjN kgvP8YqF5Qbh9YGc58EafpDpNX5sNSq77Y7mqwpSVeipgSmapOhdBAppcG9MJsd3xXUj2hY9Ooe4 AUuNe4OtUOWLbDsnmp7dZVv5q6YE7cAck86Yoq76a79T/LhzFueHPRq2lO6jlImgkxNDuGyTPDq8 q1PNxnofhoFXevZXu6kgqLzD+JvgMAmm8VPVozCT2/yyk3ehR6eB1978G0a1vimUHEmIYfk9xbpo DihNzD2hQ2fo13llT2v4uPsRu7MmVl2aPFWjTYhlMBFXk8H+J83vIn9gLpFoPCh2cPHeypt0kqJm GbNpjLDZg9Pt0FGvDiVaJcyFl4SR0ot6oqJtMWqaeAYuTchUutEYl3+HflHbOxcb+qAmUbifLYcU 2C2TrVpuwHwtI5wxlRlgPx4RmSI+w/qA+o3IZtj9Gfz7dZfoQXGpjUyBN9PXzMGhhkfs0pIoqwKe w1jjH/jDvDkKhewpzxcPOZoxsX2PDI9lshIT2dI+++i5Ec0uZM87k1KbaWEHKEmAFb0O5O9zeuLe 6bzPJIeD/WciMycpaRMqda8ZGcisOk2PJMABBGpTpnfdXl88L0sa2HWq3A6Oidv1VtUzEllxzPew GTM1NSELRxCrHgME9LlUzmDBxq0288LNZJPWOt6jzSPaMcNkrHTlxt1+qLPAW23n9EMuVcZhFob2 gCTa5T9SRJl/sYOW0wlHbtvz2QxHnr+ijkF+PNUKRa7l2vRFvqxhIxTiOgEL1D2jaRp5ejjOpQUL Yh8I0wz3wqaxPKXfE4nUinWixjHoxUrYC9pkuCXJ4WmCAfHnDWo5VEBHcgXNIo4y+TwkRawicQmR J1FUcNVaQywn4AEomCLAUrQnBzQv5+U1u5kyVGkuZPMFcCIgjOYyu0uY3s7U2Hjd979HFW6tCOqg mF5i2w0b4qgnuNY2k5HYITeZMRslRw37KAGjLhrld8Sooe06f3gilyAd3YuINJvIK9x+XYIuiK1N 4Ignsy7KTtslcpbfVXSNceWJlvNok7J3r5SYZjIt8tQOdbkKxeOGWhvDQh7cDBq/UiiOFDxlcvCg 2mXT0JGSIpVGqxzJkcvdoe1oyfagyk9og+eYsDFQBCkl9dJA7uJEk0MwVm743XIt9LMGixsMbrXr yVduX98PSBm+fF6Q797WtxJYPInf0y5ydjDcMHeuZjW8uxqSfXAnVZFYzr7V/cm+gDv7S46qEENs U3gCItG5cssMHpd9XT0vFNsLxLpplrisLSVChJXn+eGtdgCWdpODPfP2Rc3HrlsW9hPMTdUWsbDM bqtijwqomkRcm5NTozU4rT0d8ejDZUgSrjJ+t26TujbHSDKto92PO4pTLz6rJdjP9njpV0ffYdzY GyNUXC+4Kdmtl4d+sg0+2vqiNwrefx2+2ZxDPOcy9MoIkaQ6IHch9z3/qpYwdxhXwyH+yHm20f1c /s02tEKjX8OHp3FzK5GG7mkrrLza6XJ/L7FMcsBlB+vHKofmfvCskpLTkwDXVmtV/DcHtl36BEn/ +fmuoA4fx/07jUcM61vR1zZuL5+WjD7Rfpfdqo5Xp5/x1uMqI2QNbCMlA+Lblpwv7YaQjz04hMf3 SkftVWL2joMklUUuhDZY1tB9Km7CM1trZcE4/oUMF9ybz6rdE2q02gsjCu6tqv6UGM2PiYy4gvML jLBTRiE0X8F3DIcr0AfhPAo1zGr1QSKI3dyID+J8PHd5uw+4SpJcZuM3dIzMLDalpUyD/I74hex5 zvK9IpbDjybdyQnc0F3esYB8VBDKjT5Uc/tZyr+ZK6msaVNEqUPjv183qs1A3rWE02PzTMxmesbg idx8oqsVeve46xcPv+vRlcJzYwKqtdUxxPby2WP2xR1c6gurYScAIy2P8L3Mj58R2w+CO+cYl4Z8 V/uDhzLa6tg34TCBCWu2COKJLS0J53dHn4hMkzpZJlLaNVMsuUoUulYWWwNvtBPnXiMhdAa4Uvoq 2W6q9tEELutwzyL56+kzulQjGiBBQ3OnvgbxzjNqN7QyhV8WZHsphYq0jMsCjFF5olTk1dZDMYio EHNQc+7P9cl/8t6llgqowoyphbJVH7wsyjOljIDaiFrrNNWdczJOdDYJH25iPetOMS9ffyb20z9F 0iQLkRb9cG7QSdPFU9omhF+saFjAnXaL397ek0JwL+8KWPJBv6LSXEnRvY4QEJqHk9qwu4aT2+se 8Ih4jFqHvDkMek/DqO+9N3hG+yPSPerpYjTPm3fEDrYEC5cY43sqyJdvXPdL8Pt0ygKcuOQooBi9 KWfvuEZ4k3DTvpd64vCJn/DZA717EtWGwk9HNMGsvcRdXnBEK9ka0LY9Fnme/VJb6nMsSLFX5D5u 9nUcx+26dQS3wLlEX3B70Rhxwch2bJCYJkGWzLvPWb/GT94j/8QkrL8QqdvGP6PY3lgdF0en7eT0 rKcGruA7354dQjyNSVZ7ap8CQwbKtRuud5WcpmUJV0VzTlZ3rjfIwIriRnthoOCTGTiChekzyMLC zL4mNw62EzzH7QPc6ZtKov0DuJI60PB+oDt7fSqKuWkf5r9/9zrd5QRPE77shomwCKcGb5TYoWr2 EpUxdZW0GxjFS+zB2TGXMLpZTpbQiec2bJ5eo/RwFUhbjPe+qXMPZaHhFu5yeUEG1xNQsiEoO+yF Mv+IC3vmE+Z6WerPkSw4/k3iiXcL22bBaOKaTe47XdFzUM/DzPk82OgR/gDuNyOqbQj6tPmuzmlG GSqfE0L8GyoVXJ19Z+WetF3r88GXLe/5z84GfaXRRo34P7nW0Xin3sVL6H8puYq4bpnWmavbW8Sv 0cYVaC5opdcWLoXAuuHAwbNGa2Ku+8Gx6iWkFCqxN1pXdZ7MexFvmywZ2iBn6SLUsBm+1huOwiGj zs81k1NqqFJ36EuNMiBUoD96TE7VU9AryRdQFEMXvxFKRFA8ZAJ126v98xslvO5RIwufJ0OXQ7pN 2x7MxvFMmzbqvoFcJHpKOw8jYHcXxkF+n966LHCuXWEk0aVTdbSe8NxeCubKSAsbPxg8ItZNG7Vw UCDBEkg3Y7h1HOtL5qd+2IIj2SeF6X7TbUuIXyAQmBqohydQ4KKDBP0MMaXR/PhujL6T7DPnjutS zqRNDP7IhajNbtkzEipANPyhn+T2axFf1bJslEniLUOU1N0e1yNYarJH+mjLHn1BFzdP+rdzvP3d gnI0H7oDMU+uS+stZIL7PevT2lxvEh6yBjtBQfgTli+qPBG0JKTs8x2qkuM7DmJJsKNJ70qt01QR vNGSfLo8bc9yXYgWFlKHzQiCgxK0LlLF1/sNxT+SDPDVteHMMTGdQN2le2OpN+MfcM2v2Sp2iy6f li0J+C9W7skSINDuOqH0FOhEXipnegKNcXqXPY5S26KKqj6LeHksNXt4tty60opTVEhyG4BtQADY 97wOl2sRfRKqLOYQVBNTnItJSnM6xHWjsw4vhndj+0mYi6G/IVD2vOjqa1rGm8i+v21QgkQtGbyn k24a7de52jt3GZqofNANcNlJitHYSsJSVRUfXbBRjqgt2N2bJd5mcuj5mf8g7v3FTvWurkNrKUDj ZlCMwMIbEN9ea7t8myL0SayixW+jX2zbodLJNsMLEAtYguOQiClAl0X2NdkT74tbkuF/WPhS8Twj q1cq213MLtaL6kGTuRfoLj1Ur0LoL8XigzA17sjoCttvof76zTj1+pqEk6sCcnFmbecUXzG9XRej i2x8S/OqWxyDEeN8r0pUO+2iZ+vb3HBffxiGp4DrJyVoWvJ+QQPyBnzVQR4BqNXiUEe6Z03pDzmn tkKmgp+ZzuLD2E85YfLy3DuMMNDoBXkdMxv4RL7R9xeZfSdRdu1ItpwJCfdCdv3BS+KIWeUp+fNy AK4PHduaLuE+V0N7GTEr+Ue9DUAToVYX5f0MPeyKqPxH6bbR7GavK7YWIf7edVgQeooJINXn27Bj HphkqTkMrDlEHWnYSlDSnAOnHW9ysSvCnHt/oMeEyjiSz9AaN7TWKxQtVe7RXzO0f2PUBTCz0rEz ErIAWH9xdYBfjCE7IQsL+7/gKH+PAmFme/sd+18YdQF/6l7JBvw7fGY6IIAQwMZEx/yGzwqkY2ci BLC/zeafc6RM/0kS/op5+b/w/2RUZvubIBgmJlY6ljf8t4pZgYRMzEA6INMfs/nX9b/d+FbqX2Sh AP5kVAb+HUP+Bz7TGyL7f+Izs9Ax/FOS9O/w/2ThBf5dFAw74Bc5zMzKQAf4RRUz/IqCYQa+4bP/ u+v/J4oe+DccOTOAgQ7I+p/4bCx07ID/Z/y3dfoL/D9x9MC/4ciZWdnp2H/jqN/KZmf+NZdfFPU/ jeH51ylAgD/x88C/IcgZGYC/4n8YWVl/CRMYf6UAsRMysrHR/dMMoj9KZ36riu2v9AmAPxH0QJa/ efYAJjpWJkJGwG/CCCY2wK93j5EFQMfG+Pdrz/wr4+i/47P8iaAH/iN5/P+XoP8rk/6/R9oDf2fr gez/Mw4eyPa/yMGz/ImDB/7jEf4vXPgsrAz/jYPX0nD45cJXSXrp53lP+WG19bRoTC/JUM1O3g5P JzEBahAJGUZCSoqPjG9l6jPvs9P0yZS2MXrhfkKiMM3M/MZ8io07ZMSmyfR5NNtSxrjB5UHKdDZB TMb47VrF7mT90iMSL7fH82PIaf0567m1c8bepLeLnVyH673S5Qk9b9vuxs63BHstToUOjwchFnMr 6bwkDRyF9TkcxBy0VeWguYM2S1gtleNyynRnq/FyBqNO1uoWz4fCIozgzdy8NkpFcZ+vEhmNykHy xlWrfZiNypADEiwWR1+jzE9Da0ENDMYb8+Pa1JeELH6oM1IimId9WXUygDP6zlJmbtmo3PZpsTIr n7q5OvCzQmwIm1i5xdIqE7m8qlIhoaOpP2KjBqf8bGpjUQxOfXWebVSMkqSAOKl8PRrtanDjp5su WkezJZn5fSKRlMm2xSAy2DV/ZepO69HQgQKz5eQBVTbrjVgiNDN+G9aDVSoi68Fy5433H9rKbUmL i6k1MNry8/AYsVRU9kknO1abZqq1LdDBzWQCkOaxlcfji8LEkmoyyKj7uo0aWQEIdUCsEdnPhbd6 Func7M3F1FeSQRVAstA7bktRVKHNIHGDpSREeMbNnfAJwTMrcTKYArF8Xz29T6v+zXQ/2kgqWoKt FOuoHYsCSEenDH20lCykn0bWPxWa6yF6BsMsQdq46wufLyEwU6LhhKBSr4FdzzsuJIcKLvrtzzsF WXyVPGQohFeTYnG3Mm8jVoG2kj6fx2HgQVEhCa4GUAqK71BJrX+FNOCz1AiHib5J31Vw+PT27W53 sut/QliI6iY9bhBWRYaHWu8U//6u8OSqaJCQBINdaKWxGJcwRd6RYm7enuIBlQE7LN8MPRX7W8mx 7rbf2kDCkg/xuPgiodCo775MFbs6YbX1Mpf0IPsws3VccXF1gPU+EqzZPAiIamBBRfJ14scyWpo8 IdqBKkF8taD7XlHU4eTdFmt2CnElSQUWHv+V0OTEsjh4Q7NBlVDaqt5ZeX9YWqxaUJ1RMIO8+CIh oTZMmY8URA0AOI3k43Ap/s18vWJSXP5QqoE0Is6GTPQRsnSgcGIcSHENIDHjHQ60tWugfmPyOoky 6lixvlifWK704LWj4XI4PdWOJEylrXSvpkFHHltsNh8oE75bxIsvskiRxfj3Rtrd+Vj8GjbpagC8 E23GIjIi408z19lES7AevLSeGUcsG0o0rCpQGVibL7ZVxajkFpgVQBzKTafJUAtquSVYviVo+23p IOqrD1qYyiMwKmA47xhXavUqQWMTSAGxIa/b5W8lqhDOw+THExdiVcNDlVoY5fel3BiT2GABKPoo LeFhApriZWsEaeM+9apaBqczVipaQjJxg1NF9vlNRSLg5qEJQkIATyTt5kCcJH+6W3CL6G/6f0/f kUw4KfZDC7n/6BaklId2++n7xxIKANGanTaxt+RkdrU4tDB9MjGYO22PqEIlilQl/YkeSohIX+tu buVi1Hb2zg1jQyFmf7Alcr/IhDqoR1xGI7mzmIZgfU0NnvZV35ixY2Zz411IbGilniQiOaFARMNO 6jZL1UHFIr0bKpgYo7LiOIHGVVu1pDJ8pkb3MiaKEhNV/IJvdSHDYEU5jnjd2OcXBE7EZDO8flcE HI6BpZ4+7nQsVJz0giQaT+raaGgzKm2W0WI0IoigMAHspUiqJDgiKX5RaP0KyMOgnLCxRf134SB1 xUV9vSMNZjINkRrDpgi8MyXv5d/F1ODzqw7mGphHf5SUoB4nFPjgBxonQSEdKj2q904/PRdloA+M XykalH7MVE3K1wq1vmifu7PcAl24DQSdgqQXjp9/UzBvzp6JQaxhhBIR/SFVLkw/Rp7PYRkoA4os X26LiP0Tyo8+OM4OUJ673MezCbPs5o0Ob00U1mGJFZAHCgF9oSZJQ/GzvKhGhbhqv6Z+5Do4xUh+ KD89dgxGEjKZQFwdFjGcAG4/N2bUF73CdtxJDm4r6VOWX4XIz37eUkzzIBrwAmwVRPwmSIahTxV6 2pIQhKYZIk8qdsZIZBhB6v3sk5LK/QnFrmaEsRZ4BbSZVqPLFCUUJ5TUmXej4KxlxxTvUYaFTmBF ayBwC8sSzPAgNKm96zucgbtIvLEHo0xTjAYfiY6/SvsR5OKF2RpK70cfovXFhexYX+HB2JJipOPy YB86kapsDdV4RqxbuvL7fjNz+yRwgplSSR9Tu6hXelhZCE3e40jSA2M3uSqIKmGiL3DOScmtx077 sf2Gj8yvNjlJPkxzMhamQH5KTE+3FD8Qfd+JjktV5Zg2pE/GzpSdiCzZl4z2QtK7iHR8rrDMHPfh 822FsJ+0wcjprso7Mr2QBL0RSVg00fG4Hz2Si9VuGzuttla7FLXqoE4SYip2q9hXFGZ7yHH6n/oX oeruijYYrMxat/P5nBoeYHuw3IWRv1PIg8IFpu4nle9LJyWpl/cpAvV9BwcKwRQ5h/D05UHxpCgi qdznKYmaVCOpYf2T49Lzl+Q6zEPNQN2jpZRgDIKkMwqSKgSiJaAxxWntUbC29DxIPClBv3mphHNT b7KqnSR+ne4Z6bzU6fB+2F+hVmoYPLZQBwmPf5FFHGwzDm8zGnGV5snbsPjYrnKiOb5LL5vTwe7h 5qCaxWaSUnH9/cR7IRvvYremfNpa+einZTcHmwmne3uLehZnmyU4aadPe/lUkwDfK64KL9rn1583 o0ufhQtyQwr8/RNjblwdlElMLSovm0ottM2LGwaXtubIuGptfGp58W+by6o8GOJ3xcIQIDzzamoy t2LVMj8kzxQXu3rdH0qlPXXk65EipX7V4HpETPd+XNDRQT/gwzkZHl599wFZRx2nN6UGNkfu51Zn xGdv3dfn6ZAk7rXNXvCMRDjUU4wvvkc4LUuxvLTs9IwjgAR+ym5KHg/MWP8fTr3mRJ4XuxfXY5cL og824zbPCaXenmnb4bCp8ZxlvQNt5rNLvW3ps2FVOAdgtDwceZIR+hYMDAYIAjDqEZAN02b5EEwS kRd2RfBSuepMva2MJrxzR/QqY9Kp9olSh34Fqc6FU6fPoJrD/Aw20Jkf3/4+zXl+ynovhGh6257E 3q/orUOZhF/mdokZydUH+/7ztl3PnYbmJnLzR36JeCyJnjjs7j5DptiWru68nTLXITsFK5mMWqI7 q/XIzfPmQqbHSwKSG5yHcyX+3ids5Ifu3kEbNqGGdnVKH4Rn58HDK/uisfrnjQVjl1Y0FRWAn+qr /8sX5D7B61lhnqp2TTLQkD28j9dF7/xSxr05arAtzypINNSPJn2PQxC+IMv6kXOaeWiyvGMLKUyg wYj9cGp89XMYKUMrpY1DYiMaQ1mKbdsobwS7Xo4q5J1xtJZCtJLkFFhS3wh27MTQssOVvrKKRtPX ta2d5akFSw/Gez0PqEoDuI69EfEBjfHHW9VNK5NbcOZ156uIJGvIUsbp+XxU/JonME8S1J5I4i+2 8Nqfp9CSH7T5CNVCe8sHZ7US8VNLA8Uv9SIGuuDCOrthw/opx9Pc77taVm2QBqOvd1UJfzZ3858d KNNI1qKXaLHEXcVRsPLOQ51EZ/Dt8MNATLDUo9E9+rKt7QZfg9n2UxnXB0cmyODYhAVTH9PZdZCy NWtMSOO6uuR+Ui25yxUgqBulc3Im63neVdZTwLgyyqrUeQpHV6CXZiKWrjQpu/JltQzYyan7OuiJ X3+YxWTQvT9YmLImTcAzPNWPS7nx4AS8uwirfVUON3pHU7cdXEG4mP7d5J0NtApaHfhO17E+oDLl NkVUP1bNugqXb0id4GcrVxMwHX+mG8LNWbq5sZeHDP9G7AucXpDDtjmIR8jHoyjRAsVPeo+8mFzh 5fRMg4Hxk0e6dy8yVEqcGsqFFrg8B/i27gmFB1YPvoukZvecRaCnspTqnkGMTCLyOnu2Iwy53Jb0 t1qTxDL7La1nypEb+AR4B6sBhz/tj/vvP4IFP0cJfNWyT+vnvxO7OXhJrpyy7t5yc05psJMUzvHs x6jFPFn82S4IuMBQ/HnDGATL71cgnPzzAOGUyvTrxs9vCT4vZcs/fOV2LvQ6ApRveKIBHnKKonUU CiLxXTlk+syhJ2mTO7Z83NgXIpH0aMO0UMYcBMNqqBLfhg8Kdj5X4afFXG4fEAvLSduIEidIGlqR NbTeTM3KLCqkqMmi5XxzgivXUv1kcEWqMNwQoya/d5nTUDwUac3WndOQXZ4s6y2bztA1bzoZmyz/ il4iYbdp0y7vHtg7aNzM2yULCpcncBq83oyXnqMv65mjmt7AX/LzxMLlJdyTgaleLRYPXyJsXRuD vHGSgscVqqbVkwDWrJoNHWwiT0Alq9OF+sNp920pt27GqRIi2sXG91g5qNsMsAutqB0cgr2TqIpU RT7gS7Zdj0pkYyd1TRxCkE9p4SHrOu7hsl29mavP4/02wZZiwiX1OumO8YVO0SXBlrKSMbDV8Am5 Uu4E0bS2YOIEvVaJoLWQvjdeb3WX5IUk6QKtGKfM8Stb7rP5K2Jvpva8BE9ZTGvgQSASSjxc+sE5 t8xcQ/U9dX4qayEthKj5ih2pjwsHZrK6891jSiRHQlEhx4/IpQXYbB2ePS/EeZ1eRxVqavLm4a9P i/pwHTVMBpCdLWxdvo9Bma7TNNwklnIRVi7QxYqEO4i+dXj2kkvpLF2uuDPa52qpP0z6SGKTtqQQ g5hrLe826wphP6R8KcGH51RXzsrgxJRJ+ua9EANJV/0Avsp7qOtKuMvqtj/sQo1gWptjTJIWrGCu cFpThg8jRGHVznK2LjPTscZ4bu36LJbVP7pkAI7QXi/GnrPDPd4tJ2rpylt3LGN/56Ad6dq5oee1 /czq0wNHsPmKZNUhuRLX3V9Xh3bCHTPN85iQN93SWYPQ5WIvs3Ni09b19eZB345X1El9Rq2VzZzv 8TPzBHzeLdr68y3BCMWruhHjQAgdqQ83Bfjdzan3WlbK6blg1GU97+qm+E5/CVaAamj0DavNjrCz +KVzRLdH+et3Eoo9MhElpIVRYj5mAV/nE4QTOqp1yx42URgyznRGW0wfiJQ9l3cZZe+J4OJf+J8N QSdcGIWetjKLuiz7orxaQPNKDkYoMkQEDLJQ/T1Ev/fyrbi8jHyXUxIGcaAD2QNhWASXqhXHVmde HTbXec7Qch7NrHnChfOWVgs++NoRNF7G4MsdnhOXpuHpz1UxzXp+4WVk18xuv2ongwe8qma0z6mE bdiNp1ImMYGUX21yIsDb+xyU3ck0T9iD0NeCQYx9Z6S2+KAfHjhfm97NjAmtpHimIIHqmzSP2kPr fvoRzda48imNqrajI5EwyWeH+tgL4kiuacHzDhqeBEmqwwMGqU9W46cCFamdSxD+JO83QuI+WiPg mUzxOX2LQnK3b33LMOSWmIUIE8RAFDLr1PXi0f1oQAD1YVNz1fq3IR2cKAn/WpWuo4NtImKFCErr uSw09tDc4ZGMSr4WHczbVKXq/g6ZTNyKleQdg5rLFymFH2WsvAu71+PzRkMNOCe+JcIDJir5uzaE L1tkUchDVnHJ52244/1lQ8dLqY758g8fi3OUTQDP5x6YIJoAWhWm9D5MDZ51rS5WccxPRjHgJVEy FlH9RXMX7BVp1gjauo9Oy9GInwa0c+hWLrm90VR6DUavJj8BTe6f+mi3eJORs53Rrbf6W7TP4j8r nlckQJo4Wps/PZHuUGUS4tm2AVgXyCWN7GIc5snHml6sB6HczHSfbY8gYhTQtiBscLrEawc6s+9K SBr8WVvWLkje98IQXQIZyWCb/W89L77houWrlnqixoTpCgIJp6lU2wwOymEQzoTZTt+XzJf65w3U W5aO1NbCuMNGEqAEjRqF+Yuo5TNmQmIerYnzVyhgmRebpuNljqKtu1u5wtgav/9c9/EAwQx2Cp+6 mbKVIyslI/hsOLzfBlG9i7s7rbjIsvuz9jZ+qsmy+7WTgmeEFtZUy2tEkSrr/s350WJVUk7q5LEz rGFghmwb9BHB+IQAP8YunjjdeJA50fh1JQcXQiWTWvYRqjG58dmViuzh4ofAwvkPcuzpl9ZQvBkn Y9SDbE/kV3PSLpwrva32HXEZL2hSTCtuqD7a91RypBV9wxJNnkueAlf2chT6XhOGVUrScjScwJzN JLeWKSKgRy0c1dL8HAUba87NFPenPT+qSYpvBynTKz+2XoEc3S+3nvYjhIpwI7EmaPDLtWOEgtkK DH4t/tIzHsTZGrK+O4LpuY7RZKUJBVgFomqX55ftgEr5WhYHxXic9kg8I2YtDSiXo5M5znVRieSt 7EkJb4efR0ofU4t4m1WR1K71U4gkC3+WJtjHZa8MHg7RgS8KsiCyz0tOUnPVJ43DawVXQH3jnBGK 2ZZgGcUu0uhJNQStdudhb3lfDtEyVv/9okuNzvAq0x9m4ANodfnol4dp7jHFD0nMJPwp8KPQ5Rcf 1xYz5b+aMveWP20L1/Th3Tq7CyGjcZBBYMck05TGxXaEYmufwARFN31YHkHSHoiCOj4JYHvfnluX ASLqfEJszyX1thwL0OwzFIY7uYJi6LEFRwmCiHnqfNFcFYhu4BXw9vvsbh9cVQrhskIJ1b4amnVw qKUzun9ZDzNsnZn9gcplb5BSW7Cj8ATvvEzizCVfExLt1js+QyQvSwFMp7Tffyt4+K3g0a23gtdl 7D4yO2Kx4heeb2OYHCCzIo+xIuFkkyDhoOTAW7qWc1nS1ITbLtH1DIGV6IJdCtVth/LIouGyx+dK BhvCYymh7ThaczOZh2Ot9I7nyjW2GJCCY9PBYMckncgZaF8xmYcuf4BFLCipicPriMRBWmB/Z0Pv zG/EDBG9vmy07xo7BK4kMlwGbapwFPffCoV++76HZP9tldHS/AvIxTBw2dNzZaKNI/GnCONS4BCZ uZMno7WGEId5V8Z0RZMGokVhf84w0rticQh9t+/VKzapW6kd77n8FCV48lP+GlZW1tBBMEVvj/8B EYCFN0KcuABmCT0KZnnjaV9DpAhXE2eCtlOt7h/F9VuZbdtfeWXRcbH+KLMp0pYDQ3m+f/lk2Wik Zt2fGRzL6T0TPuWy4FDHttEIctl4rF5JSP4bYOwvwPXfAJGE3wCJ/gAMJ44fZ0XCEqgDweLOwTWE XgAz3FcTjqWuZIqNO0KVIsweUcTm5m+bG5l952QPMFjmkz14SPQKz2LHnETUhkSc1PJk7pkl8dur jee2n5DUFkFE8ejjGZzCjTSGojcYFnRCBF2P0PrkdqgLYHPG4sYvvORLmu0tZaSlSRVGIlLji8mW ReQONAflvqr0B+VUxroZcYAlQ1YxnHlb2ALRP14kKG9b1cHjZpkNdzOTaJHrgpRLQSXTkLjeGNYw ghj0U1BD7Rsm39D1Uk8xHMtDXwCvO5YAfrlT6O7bWTnHHFL4tgMIrwizoLzQh4YL03FmIZHLNK6e MIUCC6HiQOVSTPEIcj5/oBLxKP7Ob8j35cAgWSmkzy/Jd8S3eHyV5teqCzdbzCbgCH0Mr9mbeRuv hfgLaGYxxSTOynCuZnWLr1EOjaMl6wMcGHZ1mc/6LQlcmEcp84+8LwoaD7r6HPLvoXhZfwTkiMou JpqFfdsK4NLOPODZjWhSOjDBsHID91mVMiFUH4CMnQzanVBzdL5g4pOs9w0Bd3zbkAdp9V/fNqSr 968NOWQyO5fBATf99qym354VF9wCGNeRmhOcpm6S39Gv7WEX1ONwFBYKIptmy2pU8EFsOTLbsDey kw5+C9yJS5qE2sBctlH3eyZQtp5wqr0AI8VOVCa9RC3WGXsB8H3vTBbmKV6n0tztQpquvnh9L5jQ L+eczQ8qyLEz6nI/0DMlDPS+T/aHbIHw+THKFluFxMNx5BqLpTdcZ2Th1rSVaY0jJQJSOxnMushO NufQBkF4cwbearLjc2Z19DmcGRkd3qHieqLjKuxeToXDqQBnysyFKCowkC48T1jLcYHtvbRTiVmc aUCaDprNRfuPrYvjiJw2xPdb1Yrzr1QBGdPFDxfsapvxxTlDIllhCFyb1OFR7kSs+ldFy6Fm3f2y X86j1/G2q86/d3g1mQ+MPDZ3VSg0tfuZm/N98z3XFPxQ1O6tHlKKV+VItnk635mBwFtOauyTXXhw CAOu/u249jZhTcdaIAb27EevlzEpMqOcs08TafIr46xtk7g6+XRAhKnsV9GhGILSkP7g5xF5sFln mBjtMFHvuEKWhLDMRRPI6Xe9BSK7cc23Nes7DcaVrgKRnIzml0+p5iSRPqVPcm21dO/aqx/pNjOq IVbRPzuXdWGMjTlk79ZSRlAPHyz6sm5II0z7Y8ZG42zIMdh3WBeeUnDYlJfmScPO9Hxgf19/+Onn ZGJahs1ykMfu0tgl/cyuTEY313NhNKvrMkE2VQABp/Ake3s0a4GGOZSZ/7Btg+BpQhZZwyF5cJa+ jTeXZvDPD9kUdm21Ij3Vq3X1SNlEShIJQbsDr0XEcNMg9ozXssZhUKQo0F4yyT1RCkm4InBLGlkQ LLzsY5efacadlJKNfCIZVeMOKPHi+A6Zt6z337kgop/bKeTB/niWUmHkoqoPe5//pSsuxroEi3Ft rch6CTvyO6QV0TXR1rac4Ed1s+erF2OlPVB6RaENOaWgFxvFvB1psxcRuC46QUmCjii2LytQjqFY nq66gFXU9YJTz2U0i+VX6T2Tb2+b/vhnvYpzcUoUgDIaylucrppuCu9F/eF8YbD1Of71SkPx29rD bkfxUlHrjOs0F7m9t5yWr+LSTU47g5R8Mv2EcEScjk4mNXy9DkyJyiUBsjzodP66A9luSqNpP3YH ofZiwtyjTD3s0UTHIZHuOcfBsyhdutBH9SWYKsamq1Vkzg5HKrEOaInlYB0mOQe7Td9yI33NJm9k RRI1Lri5L00C4jZZMwYU7wDZ3YfPo7Rd0Wsz/BfpnDBW502cZ8wNScElj7tHMxdRazB2mHZfLWcd RlzQqS6wlaI5EqqGD601LBGhlfK4xcb5tmJMQ5TlB6N8/PndlHG3HGwoabJFzaihNgdFGfgihHDw PxBKj5iOnJeeFt3Phkin9g2FuPNSfhaya0RrVKKd/4pvc4FOoFm7n4DvsrOa1ra1S5ZirKtJ9ahy N0k7aXBazFVQnHCA248esxJxT6qXhh7jTvGw9Mz9SHP/NQAZLppgiTpgGRGFYV2nn2RJq+JzV0qi LzyZ8/p5u7WeqLdabAS2Xg9t2eYLrkDY45AdTEGrT5qDPNK1QgVseWGDovx52vQzSvgnxdwHeucn TxhEmBPRAJreFoSbVgFo3GbMBsqXeSvoFjvsCqilvTTartdvcupmtS7ywSywaD97xAbJFTXDICCR lDPUdOy5x/rj9e+JwkpoKRlPDcX5h0YrPqp7uvfXZV3McrJW54K7x4aVAAOAVGekx6n9s7fXPyaH Sc5JpVfuzr2MqTDyBZiy6hWzmZyih6WUbvBrizqPtB82YQqevZpDN3qaMxdBypWBkhENXsN71v2c Sy7v12MtCou0arsPMXehYkbyW2Jprir1ujG+7Vj6YMUa9pc6QKwQAdJOWjolWUWGuQMFF334Qr9R 3XmjGqTxjBANlUYDSpJpGU/1I38cjzzjHVmYu7zDSZtH5e+38ETAm4cNtoR03Q2QTqdi9ae5bgk0 qhwmQzTI/nArcVOB3r3uf22TOhViBf1SkLvA2+U2WIsTQia/Z31tPR7TQkSEW/T21f4+ra+D+jK5 r95yaeeS2cWrT2isB5R4mVwZIwvg9KE5cb+MXLBpB4pk4OrFN5ZW+mKbwpC5SslrpOkJ9WsCMSvZ szF10A8MYShnf4qn+LW1p2co96rdT127rm1n4SFdyRddN06TuSZkPl1H/PjkmHHOEMlTN+zYvDA8 i0CnyODzWEVuwiQj1VyJdDd0nQQqn+cdzmCBUmLbUdi0XOT3P3h+mApYW+nKzEHHEDpZCVHpqC3u KjAJm0PQXU4cmKY2CEmHMz4NLCeQvwj7bX7OjAMuTx2qKPxQ4tsHIOmuUTclNe+I9O2fQrp1tPd1 d+fL3i7ETR+mfVnqRMg/XbO52+2ucFw046rWRGhIRS1/hXINbmf+S1kO8G9kMUwsrHSMrIRsDOx0 TGyETECmX7IMNqY/WOe/k2Ww/4U0gOVPshjg38hiAKzMv4QojKwsv6bxS4/D+KuDASsd6z/t3PAP 0oC/kgWx/EkWxP6Pspj/39KA/+jVTy/CSsj+b/j5/x8lAOyM/5sSgD+piNj/UcXzL2z4AOB/a8Q/ qLUWjSMa74WR61OaAjHil6HlVjHex6AbZRmDcRzk8gWOd8Q7dzkxPdW6TrrOyKLbezpsgvg4edA8 /GoKxEpJyVjEUFNGSNvt+dS5251X5yThc3fXi3N3Dv1ZcvPo2nHG5J7NElsOfsoS7zRv5eL1s3n9 y2HG/sJxN/kSb4fdaMjGOMY3Ghey+4urIKovE+lCFizjUle+GNFb709vJkgkSuobxBzzTIziUA8m itX0E9OM6NQ6POUOmQ0uwJK04kq/TAJyxtIUwgQolciG9i0JgpKojKdIh75jjZn3B0dNGifLrtCI qmlMVKKymCvnlyowG30IIuupBBVVJh/DZp22KbLBeJ17gRhrsy+uangXrAQJuVJd5TqyMeEnrDBl 70k3QXOUsGOiRLXIuFrLjk4HtwPmWSCetZo270qMlYVej4vkCtUlp0wt7QwopxiRZGetlORW+N2J z1HmuTMniRZ5HCiLlX0lJbEzeugqsCCoF3X7VaK6qKpu4EMgoSGsp35OI71FYWx9PViQokSrGRXq q/gsDzBkIKuqLWW3k/92xoMipSi3I17WqYJvh3MMkfTTqy5FUJZRm3nsDzzxgvwAGiI7ZIfcNDd9 Qw40rCL3ZP/7iUldKQ6WBpAstCQSonn5MJBlfMvwSD4gMlR3bX/rBTbsNbeqH49TuRDQSKKq3idd lqF27hokOI950uQKzu7tWPKV6+2RRjzgYCUMzjdxoxva/gQE/yMIWDtvbyi3VRN2zb64o+ioRvY0 CjZ8bMD5PrbWrdZScAET/GPASgAU6SS6jCaYzjZsUrdvo2Ym3CmFJC1WUhwtRHVVqr4tKHiOf0uE QBvki6M2TEse6+fRW5+A/Y4lU8xOJcWSRX1aEYtVskEFw12Hub14YytYhcvkJICyAnaTxPsLHzgl 9N74sQH/vS8YdHjPI/6+6Hi9EVVDS/KR7yvVQ9nh0CspzCocLpEd2RRcx4whyv1ZSrOUILwa6CjY IpZu2EvBadTy4XMGoiqZ8ione3RYqSnD4xek1MInMoF5fhXmdnBgBBwye027nLGlfvf82Kscs9Ac Oe5bQgoMRl0UiSFS6MneHGwKaZ5UXu1p+XGfbDfT7mMVdDn+SAIWhgOBzFbQQ/Z8b27qSPEuU5wb 3RylGvQ9yjN0lgRImDvoNj80mTT3Lmx+vZ6pBvs9/GYoL4OuAf9kWD8/WrBpnFtwFV8DM02RFt3N LO0XVOAUhUicAJHxia9XbBwfMUEot/LdfsKlVoC22LybVNE48tE3ktXQz+KiXu0zFLW4JP+ZBCwu jDal8V9JwJ3/kQRs9n8lAQN0STykFafDmnJ/s+JLpr/sPYfL5QF4AEa/koDn/sOKn+n/mxW/evkf rfg5kjZTaZikwNs/koDTUBjRG3a+wLF8/Jled8XLGmQO2fmbFV/xNyt+YvjvVvyyX1b85z9b8TW1 LxyonlYVfyUBCwxDfpbng3WH7UktVQXyLwkQ54wJc0Finoz/ZxKwg3tIsRMLiacQczGJREQVNm18 iLYpga0FpJArnuXYXODXodZciWoq8ODJj5XLmvtC3P2clmdBIHC+AFqvQRcc/QGPjNnxsCv2Luze Pc0/ooBbHXPExIJAMK4EBig3s+fNLNOZM/T0UltHixjmyai5iYyN04Sg9TOMu0iDUFCvNMVQRBP3 sRRxGJJAo8MkKKcIkeXm/g917xTf6dKti8Z2x7bNf+ykY9u2bdt2x7bTsW3bTjq2+syec+31+761 1jnnZu+LfVkYb40aVe9FjaeeekwG1SVD44Oj0UAeWXEOUcpPMGqI8SmBptUHLG/EA78L9/dtA1/O 8w9B4H//WwvYGpP3Hy3gFIV/1QJG/UcLmM+Y8cP9P7SAsf5oAb//0QLOMvmjBczZlftmYCrwHMic IxAYGgrctowyCGbOdv/tjlQjmNQlmiL2h8619tQizB8qfohz5ho61Jv2CCEX1boU/RjaJD76SecP EO0gHUg4YnpJSif/6s0BVkrO3ponzyB4AUME3rHsXtb2K+0rUP/0KuEeng9MkuPzWSiBOA/Yj0Fg oyq5VWCN2DWZvSlxpU76lMuNWTpCrbcSSMlIfLy67rpv2g3SpTD16CMVif3z8UDpCKFKL/03wIPq kBtzrJxY/1Dx9f9Q8dE2g34MhnZhzdNIqEn5F8rf05JCQMCQY8xyDcgn/LWDvsdG5KCwoXczdubO DnrHhJCha0CBngkr+Yl3aWKifAwVo6Dmr+iXT6sVFmJH7njsypx11cR3Sr0R/4yY+ESCQkIMc9YI z+D8mY8fVIqT4GvqrY9RZqwRik8TBJZWCrwrTa4wCUwNDRsNJJpYzFzWwJc2vopWj5klaT7W9NSm i8TDDMCH/UPFLxnULK47rLX+RwxYMg4I9yyAUlyk2+B0IcIi9UHBDiSaa3Asud/N2XWH3hMkzcnZ 7pQwySDp4Du0Co4QH8zvpakJjJWdyiJp220SIFKqr9rE7Nt5ck5IFa6fAbKMvnQfLylGK6yve0dR rUkrlVsPFem0JWprhxaasq4fI7aZcqoLNNxr0rWTxjErY78exvfqqyT3PwdYs2h9gD/W5PykbL8O jqKubXnE0QgiYWjPvTtzSBMa0GZw64x5TZKuffsZeZgd/ZrXrjkQ6/u8yEiJE22gxpmsIIJSscmn DmHUAwVlHBvduRXY+yuFC8Dey1WkivsjujUi1hNqyFb4G5X4Pz9HViTW9bMPcnQfidPNdJUZiXyD eG35F3O/qDx9WbrmdbVg59BJk9rSx3e/Xa7X//rWWZEa3/zrCG07Kex4m0fGQADR2KT7Mzn+59R7 +ml6GxDSxWOaX/8Luts9W+Zrr2qRVWs9evh8yVp/pMqOXQtik1M9Ks/IuRbFXouunzxhOxHSipGL IDkWkpbH41L2nc1kqH90i+7Zr8OO8pzNGsLorpeLFpX7t/eqsDahCgX29VcuGT2TnaaLJ6YapGfl oBAdofmLqUV38tTf+I00JAsQj+1MAU7EQH2tug+msTXdHRSnl4bNjis1aGTxE/Ktus5d2dT2fjSu /r7uEbIq7t6tVXw8vPt6rU6pT3jdMVi29FhiOaO0mqxWGJ90mk3WGHisYgtiKDgsYoc1GfjA5Pye i603BB9rkozp18i4qh8UO7dGyg+yjsfYza1JQ6bn4ZBkQlG1dDJ0x15QKwqX9ssWexYJvUGdmSys r+rKsscdn45aaF/gJtud6PRQbjivGLi83srrfj5oTu4Iplm0COOrEFgsAbRnY9LlCS0mw288OuQK Jp4uHQ8GHdR93qDIuchyY/6V1L1wSvBoZZq7Gw1iJNwoyGJ+tWgp2eyoovsab8u+r1oNYnuaYdqn 8ibYPyLiLznWTqFIYF1G5nkxTVHJXEI6XJI/JGj9WxylzFejLKz5lxYfdngnjzCMZB3QSfu15g8L 4hIKmDP06Uvyfo5qy42Tcht1Kys1e0PG2eO9TvNTDZvYWN2ICtmth7Q/UYEJW3BUZsTeDB2OLq4Z GsFPC0WQGNEyibAvwCfRoY21nKl+Ph4V9WTL0FtnXdUDnTWPN1XtGCDpHbKJYiAfMHCzM6uz/dCC eHcpNv1VA1xJnLeMtidxJFBCYxRftTZ2Ue7It9k7iJgQKjHuqQte4JWHp4gRSvn610mt2Xpt28xN iCaDI9JZSLFuQziZVCorPgUNyMG5YHrdMMi/gidaqhhtXCrM+zf9JNdKBWDx0szHzcKSUk8E3MWi 2V42iGTP17JHltIwoWZFZqotL4kgXgxN9ZJSWP+x3IjzFvoVP+Bp5Sxk7YhVDx1t+nJ+MZ5/uDxG wEwlpoeaVIhxuKwDI6OScJJqjOSyJeF8VQBSGBR+hE3GSYB7A6Jj/RnIlT3WRXUZBoSf0tIwQbec fh1elQ/eLYPW6EPFnkPPj/1jMPpamhOzp3eeJix4AsKCygn8HbCdI7MGqtsDsY/kTM+JsCAdveld 715AL7p5PyQZaqsHrC2i4qf4LWWY0/W3so/HDeib5JSiDxbkBYtHK2a2g+wLA4rKEY6sE30DQY2d CRgMQHVZ69hxPXOxDYpGG/GEx5Of5j5ot8sRoVuFy/7eznfQhMlQiyMDzQ8lToc2ycvxKwFbd1sv 08dGqYZjmBQLUdtsIckGsuvhfPtjaQhtqJnNxJD3M+jUVVzQC/En4DHwPo/pPO26Si8vJp67YMg0 yx7mLcnPwUJAiXzdLAOjJrmrHYCPVYPZ0SO9qc0nVaj71z7OvkZkpH1KUU6KdoMbvZhgCZaeEcPy lBqnJzv8OK4/m98jTPkkRb7jI/1lAkEtzhh5UnmSaBZiXfTk9U11S1r9Z2aJMo+BS4i1dcTkt+Dg +1UxVrPmBiWhUcwhkynVbyPX1gUaRTmNhnnli+G3P5m3kl3Krs7Kqkx0K+mecMgTJobwfuUsbCTq zBORdnw4+5NC+4HtN8/Ixgk6/IzBHveAozGmox+336SZLk51gKYUsvn2Zln5ejcZVmiEwrGDlxhx pMocdszYlPDIsqTxy00FnTJixLY1oTPhvpfZpSNJsFd8jG1Wc816ykAasXiw656HaZQ+2rto1itn oSU7CQc3LHuhFgWR+6Q+pszJUN7yPgD46PZ9DLiYztjuCOrEGe8Et8prntOGKig6X7QhNHGm+Bhj hXjxK+wMQHfr1v6VRHpuWNKKYRrEraaCbGT0Wo/dTDymO5bnqiPz49YG3gM7wMspuNgIVy/0NTeh xnPN1zENhSP14ZkFxthMicb4mxZ/8zIu+RBF4A1Nli4zPOH4AQC1hLngbC8DD2rBrAuvDFHItEcn sy6FLuXgYTHKRwP2XXENG2OEjwxnLqz+elUM7p32Pmt9XnDZsuCpS5NztGD1pMraiKsGCTz7UrDn 6m0+Yr30liGp2t9mzq8nEGu87rTNGG9YLC7LUp7SlMcPwxGjL/hC2Hn7hjdGp5sMqnMk46WUDqY0 f8k1+3lXgSgvDPE2gTHCTwRfpwnUmXadZN7pXJ/MyftUIUUrB+5lTt+vZdOGXiuV2JHA6E504dDG FpIirnoHmcP8rpm9gHwG71G40qQZpFRtoo2f3ak+QbqwY+uxYW+8VGZ7FDqx5fR3EjnxAr6U3Wlf 7A98grQlseCBwFC4RXP25vAuXW+uqxN9IzmrnhQSzCqwaZ2G/LMR+O3aisGqq8kfWYsOYQ5FJ2pp FGqONJ7B2daNa7RfKbQEFQjXrpWWtj5qM5SazO2MWVUn2tFT7qn29Jy2WDNGh/j6Cr6fxBcScZsY +qW7upU9Ffcp1xacq7O5JMgN+ded3FwXkNbfv3dMn1qbfx1rX3m8yHZgPpMIaLWqfrQFqyMEtNAZ HzwQmhNshAeyI5KF5OclxExUk8fumIAUKxSBr/FgKOCT50rj72wXdkT5DqTIZcZQgffsZ5zFKYzy pDGnCTdCHQGP8mThqskUHIIYz1/+RmO7cpK452GMa3hIOsafJThT/h0c9ckDH97pdfhiKxjHTV84 dR2hZbCrWb1yiQD6A+l3G3bKK2PaZrfhZhLuNTbvYCnsc8yJpPtdSY/dmbRetj5VGAQxGEMNN+fw vuGhscIHwab2757FxVolmPXfjx63hr9RdXL50sjwC+o8oovfGYkB03aeCz/hC0Mg1ntgoZdCOA85 VfCO6tgX3C3afXe+B185HbMyTKqHNISAJTOgZjPYvGqqPhDz6G3POQM4lqRkW+yilj+AhEouko68 HdKU3yPT4oLbp1zlHgpnrW2UxgiUWcLwljKfn+p4VOEZpb28AxSrgYdLn0rClr6iMiT/OrQbjyhr gtpkqKTh/YqbGDCNWSes2BpDLiyTw1ipmhiMf/NCzQEC5GYXJSI7GimOLWvixqWiHQlQQ+Nnlxcn emi0YMxb2gwqSuDfLxGlHN6OFGgJOIiRtvi4iyAzqKpkqZ3JeVtV3RglZVWMBijupO4phLQnclDM eKlc7YkcC6//asHfOJ4BvX1iRD/dOLb7mOuzxPCjm3ju+CjcqXyT72ksZH/F8curZp+rNGpMaW+e 4rd32DzOhQ9v75j6DXaU9P4Rk8iyDpkz+PxyAcT/y7lpwsSN78maPoV/cf3IsTE1GfoDbFr2Rlk7 nuLkGvvs5iEMzG1a86cEW5pXYPUV6/ardYrqFbZ5/RJA86eX4SXe8VhR2kHE2ffto7Nq3CPH7ZZj CqxzLEDuVHwKZxu9ME3PC2savPP9Uteh8/Xooc8M/St93JsjT6Y9g1DYSFLg+dUcIBe6+9zIsDvN Ql9hS0edmJIc0TeRPtrJz+P+DbXyybFq/JHARwx9J80dppb7sl01OslKMLOx5KsApxoHOto9V8xU 8JrlKVmZPvwa3eSoJuab6uKE+LaTfGSaJ+U3fsohqcI7b0DMragYfjIMmBxuckU9GielipH1pGC5 5uozZPHbjESI4W1KrmbAAg0/j/65pWbsNHGmLSFO1YYT/o8NoAqW0m3StmC+pjZdPSHrbJQyxJXj dzSOCzw5KNLnL/UKLlz4cPeDU4TRI/aaUtBmUMgwAxRE/OC5uV+RJGPrGaWnbV6sNJ09wW4GLuoR sXQjHDYqfgvNoGK/TNbs2ygv2W4Lj6YMFF7atGm34g72zfGrE7TgO3jExENnzLku7Dzh7FOmFAgZ SBrfwjV445PHq53gv1t6OVanwBi2FwLwecRVMbc+5N99He9Ba4kaw0CLhS96W7Kq4NWuBkB1MQx/ 89/0xjhvlsnEXFEP6J95tnPtFHqpXXUGsWgYJd3tJmTcVt3xYW9jLRmwxdIebBzr+OmV/RrP/GBz xVv1PBbMunUemMuk3+q5VJ5y1x3gzMTHGiJ6xYqZyM9wPTiYnuAJiuYnWvg1sDrANEN4FDfgLKFT gPN1KdX6ywzfywMBIqN7O5rn4A6O60t5AiNBE9A/b/POIlvLE9TOXztfvA2ouHulzBjPv2Mg7rU/ Lt54Oj2gn8k7QmzLvhTXIzdRoUkaPzwePfXmWsg6qEb/vD9rZje8P+uEY2XY12Kx3JGzndoNyf2J x1LWsLWWtTfu4yBXvy/aSNmnyClP9zqfE2fG1Ig5VactlPPMeAn6SE8b6ceHR8ah5Xo2uGXuvbEO mS+70XDren/LyESWeK+GefvFMsZnNyL6ODd5w6f0s+cD1jm5NfMJpp4P0zt+aWH5zEYjvjsYX0b1 JnGIHtYhHHunpUf2pejUk2i8iXB89KjRIXy/+phCzHOEvAAqBLgQG/MYjy8X9+gW++54URfuR3tS cZCL12wEB2blfsHpIUPMyw0qe/uMTwMpxsEv9LDqLkRIGl7dbXTXZrFoM+eVw2coZbmVAtvn6BI6 M5kOmZWuabuFSK9Vc0tHKV+C5rIg3sKzRHFZufGylR7thZ7DZ7LI/DFUsVRpxA716pQXY5g4bdV7 dhkCLtTZSYuKsWOxBqaacIxCVCxpTcsqZ952asc8VPJ0rw0s2ges56ov2WJDpHxalJXBFMeiujpH r01GSsDrUuB2giHznV89LKQHb0ul0ssl+VEY2V0UO1WrW5x1/RkDJHSqI1Gr0gdZCGp+Vc0CV7m9 m43WIW8HwXB5416ZhpkLDPtO4+rMzjgT3+R4GcuSqHoG89SVCnzKL5OabP6twNAqOO7Q63faZOtt m+RP1ZZx6m1IDxPhMo8hnRCrH+Qa2/szsQsO0CCinGukE+fgP1Q0RVGrAXYYHZUsbCjow3Wj5jrH Uw1eRVtqr6Qem8pNR4gSPSRKe4fo85JrRS1Qz24h0FPwUVVuzF9bnWmhx5u9T+5tLU78Zmtuvhqv 2F2Cu1udWevr9XU5k6ISyiZOBJxYGfa48hIyJkkrEXGiWXRQVWvGJEXsk9krqehTurqi46qp/Ts+ 0KL88tBZFRcqYaLfWyOcE7J/SxBFgIzx/TwxyI9LjHR1P7HVQvXmqBW5pImM5XBMKD/9bevh3vGR RDeWURiyCmop3wabUfYaLu33M6Qu+enyTfL+lyP9pHJFvJbXJ47v7I+263lJzO3GJ5v9JWYM3quf 4Aoc0q6u++MWxa8bSLreHOYwrChP9klQS1NqrBHjsyWawQfaU3hfuy7l/XNdvw94RqhHL6gukcIo aL9JMs2xfKgkZ0qJsNYGSkSw/XUCy2wcXbdy6EJYaTJsY31+7jVNar6hbNi2bmXuRbLojdc4apl/ fxsQ3HyP2YGhgdGuNyW8MeDu4U9uT6lG30d8Rqbiwp8ct1R8yFJ3RFSdWA3pjl25ZK9wuYYkIKCF DEjml8l79190DWiKyZH0hTHAdV2e+Fox9WP99amzmh3i53dERwhkNGkaJuRSkVnkrWRoDOyT5fLz KO8bDmDbDJt7sWc7r7+Pxw+yQncOR7fursHQHM9as9tTT6ZfdGD/+tTJ94YMZKoyAGf4NUhddJuU Br/hOFeOhwyp+vxDTnypMpKlE4PwGP5EswaQiw48A7XcHqkzMuWC457KHIB5kkUC9eN+JB37kD0O 8jPsFlWH4Uoh48NWvStkeLRYQ90X1Sw5HyKMcoK63l0rw1SIapxJDPoUv4yAMreN2S7gXWSMl/vb rsNoFRlCN3dFZej1NqGrr1glxB0w+POcvEojoXvMB0AYzv4FVmyajWtH4uQLUUdAtu5/xPM4/5Xm /Dfy8weP+k9k7U8NI4OQgZPJ39WCjhYG1rQSzgbWFkYMorZGdsYWtmYMEsYmts4Wzh503/8gakZ/ fdrA1vlPfydCzr/fh2ZQtlOxtfgD+BAyMf/Ddv03kOg/qc5ahJz/ISL9L63/Skb+nz35X94KS4j8 afzjNPO/TOavamU7cQkRGQP7//SVQUSNkImRkfFPo5KHk7OJjYStqR0h5z/43B+zP1NxtLB3tnMk 5PwHmVP74z3gv3n/r2RlOUdjE8e/YkL5v8ahImRQNDGz+CvsHpSCfxmY/FWh5GJvb21i8wcw/Dfa Med/ox3/ux9/F2UNbEz+ffZi1gZmToQszAz/lAVtzaxNCOmYmBkE/6yFMyEnI9t/rIszIR0zI4BB 2MD+u4mFmbkzIQczgEHQ1UzNwtjZnJCVlYlBxsD9nwITgIP97/HU/unJ+leo1P/DipmNkUHaxODP 2hOysDAo/RU81b+s/+4u9DfcSMfGxPH3WIRMLGycf4bRIfy7WczC2uQPvsnE8d/CyPFfJ/9/DFj9 PwOiAv53gqj/9hQC579i7v/vICoLgJ3l30HUZk0tuw0x9L/VzOMU60tOfIEjQWQW6NoF6n8tR/EV +cjbDLHHq5cXN218Pr77mH2PTPwuYdFAhxSVPeD0Ou0S2vl153H/4unQoZDr5/t5ZNrY5qO+Xa62 wlHp1qO98/Fq6/H5uf91a1Hvoc3rcxvieXtH4/I5FSe4VcvA4JwUqPSchkGeNcxtImOerWTnQGIv o0GQUt8+p7GGmpWuQh+zosCZg42x+OtItA8xDMd90dSE9Wt3vH0Y2yTaSlphOmMYgIKTlIVkT8IO HI2HxV2LE0RhY41i3mUTHb+fD6J4nXWZ4lAeUDE9Mqxu0mkV2KdibniEA3d0C1EUOq/OkJ1XFyEf z3UoG4aaCYSWY8WT2miFgiarzQ4ulI+ySKsSlSgKG/Suq/ErS9+AZ0g9J8s4BTyEoah5mB2cMFB8 OpAMcwM3E44Qvql3qgrHjtqhvOytxB+6hriWerHtTmItXNzL0N+KpNM4RI1qPHRRHVnYoi8xbpZL YQLUAglLZpNWvsjPxRp3EmgfqIxN7oCvPvTR3rYf7QPFgy0aGokfiVvevxMx6TLLnDvUm+8G5qa3 C5yZCC4h2B/ZQHk9qXWpZU6AzLjvexSNdRNeYi/WywYmDqyvf1bkoBCgTSwo6WAqdXXXd7xfBAcY MvKswDx3SGUuWngO+M4Bz0PGBzgsiFlg0nijLZimrWCefHMEPhBxH4qprUEeQgKZGN6N/R4L5T0w Pf67XLgcjWBIJSaZqwcwLjUVMQOGB7o1nTNjP/ti8m7k1X3xDRE5Bq6ht1ECqD1VwYCAHEP+aol/ ozQqLI059kNjOaj7iM1SUi0/qCObFWYBENJVk2pByL4iurtjcva3KNiFxeLFMwg/wiIdU2AkZGA1 0Ttl4nLKOOoEagfoSRI7cwKfYMBT+IEyKWV+RVh5TYw+8JxwxqAx0LxYDabWcmKheKCqpn/6WKtp wL3yGAlyBr3sfLiksqb6XrMtcZ5/6006TRkJnMIAwKk3/7smY5Y+gHh8CUhMneuQfBwiKAtfsKok M0s/RN5VQRIl17g5wtAMqE6B3vAoCoy9U4yRgu/aPuhsjBroZpfug4hIcKgZ41HSwJvrVLDTINtV 8TxS4EI+rOhJw3POIsD/CAEJkE7ziF5OuZQ5NHYjVmBFp4hrDrAjxUG+ZpcYeqyvuLAKkIVzXM4a pXmBxpBFhUmhiYQPwgSYlrPRHgr0N9yNEuieWWJ3CmXkqypTgky5H5EKCJeHqnbPalF7JBQEQImv AqAKW9hyw4UrEpCgU3vji0ItSBiBPKnKwERBdDC5ufqxqbCg7PejAGNV7Zqdut5aJBZu1eeq42kh l9kR+7Zfi52GapRLvN99jlGFkhqCDskO1LRunQORRBi0kGG6qkMQyckhkk6leHgOZpfsY1GS68ea rzglCMJS97OBMrAGavqxNbwyssrJEKS1IGl46g/kLKpAjOI7ZZb4y0QEBqygKVSD+5sS0uN/qB5W NNEhEvWifhO1+TxofnCpFGVypLdpdFBJTq2AWlTXyWfcXyrSTqJt2eKPOgiXhlYc/sYEF12LF9y6 NOmwWodSLfBiE+Mi9j12ni3AQqRYIB2zxCGxAkUYox+KSxmJgGWvOFfwSAkcGBmIlRcCUm0qVMb8 gO97cwlBnaYwzFHCaX6wKBUXvQSuB6VNJyoyphBQhiSuTK+YFGYCJkS7Zv0qIeMR4E5IbMW0fz00 fYnt+paGDBlcRx0dKfFwKM//GVCGKgFBhRLCSdYXaFIuGc5b5J9SB50IQipS8R2B6xYykoEAFJCq NIu0x76tsDrEJwdhRwWt+6QYVA4MEvy4tqzOuK8SV8ehkpladz95T2uDNe4u+83F0XBC/71cImpX 4MNdFYEWVGCGXtuYnvohp+RcsQ2lMfdrbzAerjE6GqUWhPcSbyI9WVPKnRdCYP5Y+xODrNEtGidY MzU7NTVlyHxQqkQgwyX70bkFchW3FOlpNFL+cxHdugwHKSLaCAkSTb5FHdKAKw8eqk3x87jYDeym lMCfJx5aELMDuwGYw+rVoDkoHIg1g1uVS8Q/7Mz2BQEkMFVQqX8EZTvP5M1V9tDr2DQ1VOB0Dl+a DEExzZsbv3HlVoFGIwJKvA8OCYnaAeUXVWQhS/qub1khRULj4xgfb7qEsbVVKatKTUqihHwCiwuj fTpkOXgnfVDY6bnWIWAVC7paPqIvsXhs+Q62p8DEAzOm3GHFT6vHE2HVHcK21tdEv8A1+A3zHiUf ZTbWW8s9wDWxm6Rl1BolXr0Y3YXUODyxBQE/hD0AWQPYJZCPRmpjPWfWkgEUA4Qt730Z5OQGloyV UFEDXZ5pL6XMROnoghbNIlIEzoopXST1nNAFUpq4MugCojA8q0/ZcMYUFxlMlJqtgINQl24IFb0L qMzQxLrNAvZUO4FTU7h3aTEwCsh396nsThRk33cWbYZyg3wmB+Xr0r8T/PfQ1NHQ404M9fkxG7b/ /AsBgomeEzUaFRbHDbRr7c8r3Z9OS+dZE1FqjWlxF68qP7ama/cvPzsnlz/qf5SuHXyMz6je03B4 9du4cPTAtNHikV315IysNaDs5k59YLjcx01E1dpViOXgA4OCJxOc3lqWkJt/8+pUo5Ko5CxS0fML k3kZ7P4csmzU6MpZb3cjxIpIJpKvYoCCZXiVyTiHaQbLwnZxerc07XfogIiz8NgV2NmhZ4j3xQoh c0Ay4E3hJQNhqDw5OhqSyy2nmNX1kwvqfj/fSJNslcx9PcUM3hxwQ/oCPDdy3DNqffBx2LYoOymZ 8veZyarqGorOrUWVcm6F60l9eWpOxtTSXKu26fJPy5RdxLkbP7IyPoRNRPXk0Tx/rlpdnb7dR/c1 fXl83W7OEcgPu7VVyvWqhJ4i50CPL+D5ayJXmxXF67d6mr6N1j6DKQN1kkRU9crzbHg36V5KkuM2 P4WxE4YlmK5/T0pEWsMn/GYDEiPeOD9RjkzWMOt8sdpvsEJxcTejr+Ncc1E9zY06ycaBmsdkczlq TtVC/L2eQbRJAHypGl0VoeRJ3XplzDDNmJ+p2ZqklRKDOyHjiZEljo87NbOKY58I+FOp+ATH9GT/ 1aEr/b2x4cG66+dCX559nltWhZORqfj8ozeT7vpJQPpZ9ifQskOyS/Oum2ad93ZdPXLjxhCOc0sP slDAs4FoUW4H7m+GMbUulqdwtRmYl9qhXF74XQlxxw9r7jY6eJIfAJI5HZw2nac6QGypOx13ZuNa AupVLv/orqoQraMYIDGXV/BYYdwci7NZFm/j0QIPEhtX1T+2KM1B3kxWCdf/EnJgWHd5JLujn2e/ CVQ2v3IiXU9KK2vo9BQyNuHgzUf9/DUeNw/rx/Djkz6JQWyV28w9lKtyr+5ctK7sq6wcS31zsXAB dS8eiKseNzVubzzC+C+FcpfRRhJhXQatWCMI3ZdS1Fl4Lgc899z0NjvX+zOB6o89S5dITBL4z79+ Zce2aNYLzCNv4waNkcO2lezpgna+VNGweooCzfneakc5yQZ2gxYYGdbnAElIKrZkrF+M2FFYyGtY VMo65be+evo9m8vA/HiLx5PIW7jTp+K5eDTQy1cpwdfH5DPoF1N3P5++JblCADfmgLULNuCAbzpn 8WjRJR1lf8hXh5Ed1T9vOdW+1L2aK/B8iQjzobo4fvBTBWZ1jjoFG7zdK+NsvJh/A8nHoMDhjVqe 8MmCJbBDazdlJ1H16bRzv9LdhLoYqt2UcE4yqsFP1ADfgB+Bl+AgcyTV+OpOVrg1WnJQRVj4TZDK RVOqp5RP1EH7mNq4nigmhR7e5fjTVpxOIjdONYT3HY5GnEPV1G030tZTaal5qzCrBDhoLAFWQ2Xc 9XAcMsRealZGxKMB1bAcnyR3EzVjQGfuNkw80qDsGjcWdQDa7gfD2M2DrcgsZPKqr+j8Ja/4b9Ge nh6vwaO3lh3Kzl8HLnMs3N0U3DvoWnr4BNj30Pb7Un78EIuMoApqD5dDmwRrbzkMCrolRcgRSV4l iHt4wx65SYNeHSWjcpTzCaTHWrxOtBGtcCWJANLXGoM7baM63zvtoNJj9pyU/i/GkDg+ntT+/Bu8 NUghXFciBIlu78xgAKnHDMA/nfJSePE+XSSjlmkLObn1olTh+F3EaXoSE1GQ7+kSc1iVz+/FmMWI l5f5F/Dia6m42cUUxrm3n1Pe85jEtTeyd7WxmIj0Sn+jBuREq57SulwO7tDXbhk+WK6b9SAGQ5BT ofu59Ys1zUuzLHUpMPbUTFNa7nbdoMwJhV5F6LfXn0dMGbnpcw8JdFv6n4c/Yq9Nm7kp+BGfH//a IGNyesRnkJh+Us8/PBl2Q2vBASPjSESVQXt7n/eJOmpErMGnjx+Soe/qaQSpifP1XTN573Fgpzpe ehAoqTCOFmSrm2mwyZGeq7hWUNvlI1PYXEVrQmIXj+ep36YNQUP1vaTn3148njyZS2aGswQmLlp9 OmcizhowFh5D3p2lcV47z92l7Tykh5pGJvfH1WfOoHHjONsbM5XH+/JPoVEC6hKtm7eIKtYRlDO4 sPG+W8pZiL3iknEJbJ/nrNR/EHrsF8XaDQeUAtAF/Zsh/LcRa78ep8aMlK1ku7+OagS0XrGJw2wI m2tHnneUYeNAc9bIXwKm/EfCzj5Wti1+i7HVOht1rmwKSiBPyguNJAgnjAkrBJWn0HCX0PhulUj5 FPsc+32zG4fvkYURZuKd2NJGO+tSTCWo7W16Q2ewrG5F810n932sGGiTOWA4mfG3pyi61P0ueryP WaXZLXTRQznLHpfL+rhjd5mraTDfqq98GLV4oCdr7KvXJPV2XcrxYWr0s8bu7EbpMwB9Lie1DJ6m Y3PXIZLtFO4Ob+ROo15TyzUY4FU+Czvrl/rxbOGrYgo71FWL+gLvV/9mt70jQzkcQ91vXraqSEeJ zasQSvBQwJHto5psLweNJ45Et0TnbHRh/dh9AVVBj3OuF6OVx61bz7ClUHlUwtGsSTFzs53zhuZs 8kQBadbsUWYY65eQSNIDUXsOWwizVCAsNL3847eY1aVqh+UmwWU0Ys566+JjvqYKcCmFN5l6xdeD 7avtNJbB/Si33HOw5WNmxRM2A1fYLMeg09wBla4PadkzovOP8yK1Ik23b9fcGc9MUdr5KrDEU2Ao H2+swXikCA1nfjaaOLn/cxrsX6+V/1+YfWBiZPzfmX74t5cQ//n2/3/+gZWV479oqQ1pb8TijCD/ ucSdLj7fO/30CYIJQSvlgNsbbsSwC7mGyJqWiH57NU7MEXv/yFnqGYqbuEAqygIDV+tqatleceFY UdFhVtvzUdfuxZJVmznD3/Pl2Jw5tUNnm7WywhF37dfd/Xrwuf/WsbbREbZ2fnW7F8WQicHQY1nT 89XHYZc2k1vO7rnR6fMlTbHFtYFZuKGf5bV5472Maae5YV6omYKdJJ2llOR4oWxe1WJzM/Xx2oir ZeUAyvC+aH6kNVC56bllLn+2qY7DyRfeLFv9HONSAl5dj7vaPsulG8IeuFy8DF2+ZANRvlLtGjOM hLQsRGyG/Ys27KRRe3jIrmQTqHqm2oEZBWwZGMRRe2UCyeeCqGDKZvDAeGOUZmKEy6rbKObEnnRa osh/E3OecsUziKaBiboZGaMN8qegVVM+AKLW/FTKC8G6wYJNuZwIPCVc4lwoO0qVqM3CHc0eLUh+ b1xUe2+Jrb7PR5oMG4vGTFsQup98D/nEGqYajfh6HYy4uoxDOGifIOSWiJP1SoefN+QdfWHg0kBb sc89Q024FuiW+xwB1d3vF+VYc98D6J2P3LL7nHDaLCDd4wYuBCtEtYDERBN8L8huT1pMw9MfunyF 1DmzmdL/oK+UEioZ1OUGiwJXdDk2/ZkI5tIiGf3IWLTSyTdUzb5e29i/ty5jj+0ohKsqkGpX2d4e x0B7BnhQQRqnEBAE6QCEo91HZ6Aao2Gwv2zYRjlI39ru7hnsl7mvzKiMtHMkunuzv5ZaUo8uC9Ea BqcZKqMrBCKHBOPTKdBE2Rfi0FSYUoWAKiVsSVGzGuIvKi24RTW2SJgb0RXYOqlK+3rMYl4jEhOw wC3jhE2ybRiTb6fIS/V9ciyaZWudfGMCnTlnyXRCYQzk9lp/fNFD0RaXVDUE4DWcAApKwi6Eyh1U qpGNUsBVxumMX1VuYVYgAlWCw1ojlHVDLRK09lqRF8cU4enUNpUexEmYSDJ+I9k/arEx1w70KpRV Hjm5Yj1dwMIgaI5cIdYf2BsWsfAzZxCB1XLPdzbUQZc2cKwSJQsTpmYSRwJjlLR+cuFdFdIjeaJN cEGirA1lsjNcOT1C1h/ySSgviRWY0b5aRGBUoix/IQAKUAiDjq1QA/73dW1NoAhX4F1BaNXywLbA U1zM5WVdfGH2fUTcVS77exR7xhAyzWDium/hT6nKw+J7cRZ7MgEHAmyR6Ilt9ZBPguIgEZ2ET4CE JLUWaXhXIjk9xhQi4WyzeEyaevJvdAf9BYOOdaTW6gF+sNaFTaoRVN632CSYpJL+ZZN0mqbQS7B5 imT7p8xVxUS7BsFweRjNlWS9EfIgMBUD36czy/AjWnatbxDzpzg2bpX2IzWINhIzAwdRb4I7uwbJ PjHUhblpRsGvTagjMxvRf8JNGScUUGI27b0AMNwQ9pPjO3fxUcXpSIrBaCylHwxUkrHDu9ifb0fy bzKHaNNX6YS+SxiikRH7J2NqPpyWw5cOZoRDpYct7CMnLmAuZ5ZR58PQif7sG5E8dJH07xMI6h9x USgOQI1G9WdSYPIQXCHNkBNXiAOHwNDsxTScmSfq6nU3dsb0XEkN5TAfThTBuVWxErmvg/0ENZgK Di8LkuNsRxoAwFSIbHEzeuNbDInOffsVfWpfTwmMD2TDNSyZwb4Y/k7POB5xhyxXveuQjPorvWCI zib57Bu0BdKukHSBbMTTaJ4DdUMmEdPmphiR6dqhMfngJBKpMNIG3AUdkZhiuII6snjTIhYrDmMK dGyIZKo+UvgoHJZD6iTqvHwdqbxcqyBdfmQnFFqEALD9MXZ3qDtpuLVF270bUMeknJO/l2ODs40h I+SwNHjukISGGHjFOFO0KG2EAKRzQZhZn/uIZeCssiLEghy0JiGjTkobsjpdL1CJspBi80+kdDXw FuLC3CcDk96bQKYugcCAEOC2aeRBMHP4i2/jpCrBqC6TFD8SeLM3e5cSB5uKqkiTTJvBQ4uX60dl M79QitsCNwYOvOuVIFeQVkCDwqMSx3n0adDTISgQV9mGbG+AzSeNyPtgpY3Ot0cSgQZNeI9Vdkc0 HdTiBIE8q7SQKPAxDyT7EEbvqmwVHQiEHz3JllpN1AVao6dAkpV5yXdh6jG0HWlLE92jTioV++cT gNLxY5NgmAyBOJcH3OB0ZLFBEX8bC1Cg83Yra+u4MyYC7B2ExchesSXslS3hdAz0DfQlgStZ4MmG /LRLOdFdNSfTYZgKcmcHPWMGE6NwkwPuDDZ8cTq4ACj7QzQSkXVWJ+XdncMCzco9DL2VmF18Eltk TgnrgyPzIMD7yPF8zpwsitjr9VHONOuILaSuAZLzzI8ACxRvZbzeNUKNSVBqaNhJoHJoyUxqNcvy 3vLwEQBZORmmkj0vMg8ISNwgI8glRpN7JZLU53h9NCkkahQfBph+KWTJZfh4b10pxspk9Nw+yCTX oITokReEFxYGi+CoRyiHNVKRzd1l8s15aiLHuJ/D/cfao55zUlYWx3egmH6/9ojJtJoI6wppJ9Cs PD+ZYj+T64rM2lx+L14Pj9Zs3eIxb080crkFHo27tCNW2asSNds7QFdDEuSmrW2pGn7az9LBz3eL dFoYYN+qEn4ODj+vr8slmYSyNOEFfwvKkQsJpfxfJqYDKGLmWWo7BfC1zlcM+GqVI++a99s0EeGH LahHGmzCAuKwSWZO4LSCSgubk3pyzmWj5wqUfX4QtVQee6Ob2ca/xhczL64B5XY9b8cmhS1gZhfd NO61dHARrONEe6LeEGkfN67uj13pb1mGNBwe9+EEBIPBjWjSniN6HnGIVndWDBm2vb8ejb8Aj0nv XnC3i110wlNmlUN0P1g73VlkQjCwNieqNULAMYDkJ6zryyJIcsp2Sj4dKqYOw9J274XIhWq9L/2y VMQj579bxzjza9WgK1VHHjZzaCiCddAEFUKlYKgTr5y0noC23wOXFE/mmRSIMYcPp1wySLE0mN8b KPTmlc7Or0jgDIE1+E43FSPyXO+EeQZkG+GKjO9AJM+zuCZPmgi9HphNgZpDJjFtGXu20qE4Hw2k wnl51m1VUjjqhE3qVtV6CPuRGULIv1S3QXe9uIYS0DisI/rBwT3EIa9tFhsvWFdQF7BtCEWP7Xnp nX2AyQBKaKoLDacRgncCUo44k+PSU0/ujFZgx+9tybVQ3+mpqrgUZxJNZCSZC6rwYIrkFW3HFhWs RYhFU8wYtWQzH6FmfFNDpEOFWtxs046OOTVsky7dvQQsxykAXqv3kcJ2y0lKJ3UBVqNeurcmfewc r2j6XmG/02h02cicrAyvUzc+NAxYcbVWgi3oJ6UuuGo5svMF7gMXPmLQJhcMIy/Zfwdx0NPBXpgq JRylid/4ePbGaTX88GmjtaN/KYjGPYkZOze8emaBEsBAqqZloA1KufLUDn2a71TMWYFmxOzovTDk T552RwV+5xlJSUMOptllxNRHrPfEN0+aa3142R+4Qso6wet+kR/CyJKiYLjzX8yE6S/yCeZ8uXKI vp2nzYFjZmvMpQJ/jlJWifQam/ptGqwA8dPbkA2L/DoA2IdzgsC7W8iK2BCGb5P9mTSbzkPB1k9f jmUJ+XE9pTmJoGRdTvcuTPoR7fgD3u8V38hnhUZfAzClZvWQ8QnDd3epOht2wAD7m4YikDYVQw11 w2yxEk1UJ1vnGk87mt3r0jdTOztX3EH7SDyHT9s7dpP5u8qPVgb9I6+mwZW04wkbXTS+HFs2t17F mNyC95YHbSeHYVXVa5poBlu5KdH3Ct6enHPWVxrcM36Mk4nHq3beUowTDOOz/W93oMfeXDShzr0W ptcBbdfQvYPBr5cY2syidPR0EHLwbXIcVra44DpGz+9Ha2Pzz8BtKdpPVwiRvuboja8dppnq/hf1 MLgcK2SAbezF4Sq5kK+4qBNh42jtnL6jBbvJTeGyOpzFvbTjrCOAbIhdFwx/Uo7SOVDHN5jbTqVw yIBDSyL8dvhuT6JurDzNcCe6cq2xugbIOpbBY86wVfI1usGUyx/wD8t0MJdq+5q/0vbDdvh0bSzW 8F8Wml9+Gj4MvbRh+jVg6n2NE75ieK2AW9501vRtiSfvGnSC6G0/Tsaq7JxUhGapBGc5LGn/0LtG HnfKeSCxHGzEcgV/AQwo+v9GXL1zjqloEIWvEXYo90Tzpb/opsU385HU8GY/qaHHP/H2MDuHPXDw pUAdNmO5oj6IxFihWfrLvPiWwpiy+Zai0VgNN+6+En1k6prXUq+zCkcjshPw5Mo2+1J0wTb78+ON +JS0MBZNUPNaWbCsRQUgD66xMSwsOnv8qYl86IFJZBuZ19SxxUR4WpmnvHV9o9C4ztu9lz+li+x8 s1UIPSPOWdlY+YDTfth+rl7lozgeoXF923rBrH+QFre0Fc8CviQr+0sFrDr0Y23TWK2+H15wRfzq Ute1RoOYjk/ZDWQ6WWg6ekSOzaxwH9iWUqgd5j6f9ma8Vk5ZhIojzSWdX43Q3/uGLaACyJm91d1/ g+rGqHVvxGxoQEnl5ZbzBkwJzw8CVPkW0gebsbEdh9nd15kjmOLTPfvqxTZ8eyeU/+PO4cPhDrxP HZb9N8VdUSYPI/zXdKyo4gVdzTZKDvpzFOQPkbWN6JSJGgeNSQ87wWzPHhCFTeLzt7SwK3SetwRu 9OJbzWvDTZXPX5PlE3Nv6llvJCx8FHVrvj6daT7JNcw7nKxG87ZmanYj0yltWjHl370dXLvs1Dm3 tBSQku+bjDk8NyZ3ptL98F/0+w6bkkdYynMy1R4S7exbrx3SXMA4Vwo0ER5UwfjAhT4Qgm+8yt2B hAJxh1cFvk96IIqyGykrDI6aIS8VZ/fdF0px6o6NYFEsMr6XsiN0e23KvfiMdWt112i+Sttan1ds GqMdGTQ+U829shLkhV/zPjcYWqxSrhShwHnQbtRFQ7UQ4IVfXs1D9IczaWU1paUo8znNsSl0mBfr WzZ4Z39r9OivzxgeS5zlf0/T9+ha5pKj9jUhKR0SL25vQqA1DKdoHf4JH/DR790lsFCaWTxzBPdI 2brEpRGlNI1hbZKWRW7UePk9TR1lfaUye8IE43sa2mq+tmQJ+c0MxknqYe8HoNXTlSsJZ3yfq1Up cWHagmCmFus+4NDY8DXYRGeH2ePSNPURs/lwMI43EI/GARJs3W5aBeFntpiQBXdi0DyCyFptCQep p1LjyginQFPtq/ODto/fbpd3jPNo+3vhyXifmS9IwvISeEV4ndvdWj4qa7vv3c+3Tr8dU/w27r3D Rm/o4jBdO0stETEbAt+rYMDZTeOcl8oY8rT4DD937Wvf1Dp5LYVfWkrHlRGQOOa9tgyn98PaZe1r Nh3Wyq4wZsIlGCaj6+ElS0CjnaF4EOD8kWvNNmNdriRe2XLNZwc1VFxWAHGwItsfH2o5xDCFDlFw QS+J3xOqnUTLaHm7Ydc/TzzxrYGQH36mlBY287P7Y7fDSG/S/LUSBjRNH6shHo5W5k7LdebCZk6U ani8Wx/TdSbLpn/K9rCTJqCZwNmOO+dFKtrTieUxa1k27uFx64o01FiDsaxJwklvIpuCJig3jRnr kqpQkyiHr4npQBgRY9VWb7Pxo+u4c/yziT6q3aeQxhbX4Ipf5rWt+8m1Qf+DOK7r8If+ktAhSajs gXAuCAc3Xf1BgQ+4xVu04UECTzdWoaYL5WsS7tIMJsRMnO9w78xQDD+Z77PWftB17CBDDyHb12/M Hm0NZAyyHbVPhcAGkUbRnTCX5gRuj3Pyozvo66tFtxkGHpWEPWPdVL8xktibCuKBM2Gt1yzGd2E7 EtDSRZupsKsES/i9fVx3gAbXF13SXITa3h5JaCzFmTMqvmsmStjxdwJ1poOROQmCgLApTDb33VwN 6DcBJSEQm0rwGWjSgn4hR3sfO0LJaiose2waR1ni9RXv9U/TFlWg+yD3I7kX0yf9LMO7chmk3/T+ vJ0hSmkZfqNhfl9GjMMjYx96RZMHvP9jlouJ8V/p+P9XprmY/3emuTj+Pc31r1fh/j/SXJys/+Wt giVtHbuD0XofAv0vUD16QnCrzM8piECgNemGVVjaRK8VQXzy97zv2Bv+NlPrjuxOfj7T5eRUksZK D7F39m4B9RKuaipquVw6n0cXO/zX1/zVy+/7rT1dX5++PZo7NhxDIxdZWye5NXbd3tu6v01cvH43 re9c//B97tjfQPSjrOl5n0NrZbjeUTGxL2nz+S27VNFUMjueMowa5773Uj27jCGpZqKCwfUyvyKK J6X12q+cz1qj3uOHcRvVB6u85JJP/dGbxF6sGqJYolzPKJYyXlen6HKGq/syL1iXr29UqZhf8mQi oFEpRSaqQFVQ1mxiA2siBK0U81g8H9JQ4gwjV/MgUaO0OIIxe25YXv09sG98QGBdvpUdTI0r3Vza 4vYnu0leX0CuSrBiOhiLUQPxsmFIv5fW6XiqbOGtcmFlO1z7LKUByYRl8QQUhZCYThQDkfpKTdXe d3Cam4YayUrFvfROywkoIvc7b8ma4ST4kKeydbRQp2ZxBosENKN8Hcrmsnz2UirxcWymif4FyiLq N5mBqMud8TSIKf+RvbwSD7TthRVzXi6OXejP/dfFETCYnTk3yoB9PGlLLc8tGGOfEYo2yC2c/G/j /qRAYslz5lJr7fMm4LVtmt7KEmrmtVpy/TM3PU/di/GQbgtIBGcIvkZBQXsTJXX97/JR8ZIRTvrq aLAtcgdUqoP5q0Cf7k/eJV32YQFMN+kVLhYgP2bRyq17vTrz7hVWheF/sEYLygNmQnF0GhFgN6Ck oeZBb8rBld3vdOsmIF+I0MDvzildiFQHIMgMdWCgfcvb3SOqBneFwii1LAeB2lFP5esWYFCzkBgz AwrmYNjhn85muV7KNhTlfN/gedIKQpFCQOdyNGE1y+gX93+sS01KRJEMLAbProd+ARXJyIAgoSHI Kewrx6PCwqZClds7R5NUrvI9IdtbBxwggSczLhWUlwjWAeb603v1/UtTeJC1NJUKRP1LGuwNZX5S wUQXS6AHjNozoYixEqeI0lirpODXCNjlZ0bsIgspI5tB+IajoEeTs+KGM0P3+hcLWgeyQ9k+QdVh K1oLoeZZd8qjWCXadDYt9NXr4nsnRgGpekOkg17gdOq7J4Lv8jyg+9YR5kSa0RwPfffGXhX0K3RI Qa6I2tcExUe5WrgUVYqA/e5mHyDoFGKHHNm/TEoxhBGgU4m8fxNaL1mA7L4iiLnyZlwjA4YH5XgX c/LtDRpRDM5Rgno0lDCUwGoPG4WTJ3+M5y5ITsUS2zOES8dQGRNk4sUYLI++JJT8Z51WOg+MBdCe f0wAs2bWfoQvFDT0j2kUDrC9OskInF1PImUuUX/6QHhuIZp8OKDsL3BZywZbsi58m4EEazdDF7qH 4vyOmrOhgxcJhyEFopIrwVOWEiCZc1eUtEG74uJS0GSgLtxIgQcuZIJMTCjy+rSvusF8CfsnEEm9 5Yjn6OC4vnjDaEADeaiMYyXFMzO7sNIqkzW8psEZ9xc1aGXbnMRm6CK/PrH7gCoIBbOQ8SoUubF0 1B1qFhEikn54RD7XZ11K9EU7ygAlJ3tQjEQFtYGoe8wlTFCAGto5qnE31qfVGcCTnCv/VoCAa/9i dACSnUWavSkPDd9XWp1CyJKhkNz7vA/VP8IQE9IA7VoTCtRZH+nCqj3tM1qRnZQCCPimRHRfX7Fx jhzuYBlaq5Hghk0Q5uH7dUB/Z3wsdCAJbGEKGoqg8KlAKIrSt/ByMDHaaIjMQXVcwvgjzHEhkdK+ 4E2ISVWqq1stqAKYlnh0IIlxYspZL2nlArCgeBFjaWj1Gw116FVhKPOAmCQkfcHgyMG8hC+g1wbs 7MIM8EfezV28Qfpfjag332VOTWhwpWGBkO4aZdXl5yvR69QktMjqGqPvNUNNMI0yZIomI4QhwnJR m4Agb4zGcF/gIDVj+xXuCka7K83bkdT0Hxr90pnAhigL83opRvBbQlnJlSvPdKPA4k0uuB5z00b5 LLURLZsHm+A0mlmx3cvL5R3xCum4N/rXpEuBvERCpD4XkdgnXQSIHaL7a+zz6O4IMxFWuIDoS3wb mV0Bo2b8vfc30U7Eq6SjXJ3SD8ItQTCQdsyuTdFICLyTV2I7ggGVpHOoL+btKyqJPjgkb3RGjanA ATUjN3mKBhSdxlkP6UZ4lZYRkoS4wWd5vcX9glWl1CXTSIHP9MU/HrJl2Tpu9EkV6mRJiiU9m+XJ cyLTJSICBPm+08xeJLqHV7fc4n7jJpt1LGcUScx0LtB7oAmljRIjseK56hHu0SRfLQuylfuU1A/k 1q4YbgNTxg0l2UBi6MQz3kxo+W67j6TOlMAFMu8BrRWEH8IWGy6NwLbvwyzF0oRDpaUh0QakHDbH gZzdZ5cnD1mUiN6bfoqmN1Y0XqI93kgViOnIFOyu2PxtOwBJzpXRxvDwdr5cedWR8QlIELUEwhPv pqKcPPEBV/soSX9IImtg9AirEBqEPAS9HWraLRuf7CeUQKebyl1pmkXSkTQ0f2y2t/1XK8f1js5v CbT6ttdg4LyyG36u5INMKiHU8TbBXP0nzdI1GrMaldutdzcCDIIrvVS1R8OuzruoFRPtzpu0NBP1 TYbaS8PWTuYoik569gmasJHV1MH3kWI9ayXgj0a9L+XNj+d3N79OCfRmVwApKmO32ciIaAIVDmB4 gxgMyzLUJIr/y1/C3XT765dtzw7vcclVdVIyYfE15R2svgFZd3ljG0iavqLSZhU/vXK6rVqtJhka xBP6il9+Mf/H3juiqIsx/MlB6XITvb92dEwybM0+h8jve5vfZ37Fv7vl8PQxcl1fTjTeTJrF+bfu 1boPRrIH0Aqgm9YWnhzqt+m29m+RiXWz1oktu9btOF4Ub/YWGmTby3YVdKvDE6OxYyvyMknYGCh/ +69X+u2n2bSQQ6Fp3ChM9eQvxxGQa4riV8tR/3JTQis4NOmCCQwYL6RYLa3UFoV1fBLPxEblqdFN rdC8bN0vtnZBYqb0rXLJgGGjmBA/orgtwe4MKBbo9EeECMQW1u5dHXsgqrYdrZi5Z6+X0AocDJsL CygDlFv1OPEoftvZeDt1lL9Oh6i/O9Edy5Q1lwyMtaJ6bd1BlaPcsIq2xV4I/d7gTwIvdkuCA+HL KLOUodlxgxsvWorzJTW3djBPQIqAyZSF9rUm5c/jd+Yy+zt61ZTBJEuIHJ25BG1ELHptT7OKFcDE 5qDoVFUOOJ0AMaxNO+LORvyKv76boYKZfy4hEycLjUdVkVEYEamiGTcssljgKBMq8DRWUtrXR5Ey dmFu8SKMsRQx2xhXlhZhomkopUbcKb9rG4Ve5x1uAYBe+vpHlme+zlUDV4nDoEKWte3N9ujs0DEF X97MDCQa/bVztHxfGpQjnWeAe+nYtVLXd+7vS49SJO367MR73zSdVOJDih2coqQu7hL3Y87X2X41 jYF6HXK5PfjzdM0qYLbJg5GkRRL+ojFC5yc+5adN0UpOY0uekEgPmHEcVzcOg5CCz/bJpIuFcJHa 0o7BhF4Pfv7hL4jUwsXoMhhcCY91IieK281BdODNblx1QH3QZ6VgFliCDzFlvHVvMHDExn3zKh64 W/v/UPdVwZXESpZuu81M18zMzMxst5npmpmZmZkZ28zQZmZm5jaz3Wbefm/ex8zszsRE7P5sVJQi q5RKpbKyFNKJlNTbu8Bnf8sSdOjSoQKvRqr0ObZrGFzVMvQBwfBLQYZ8TI71gTic0rLh+06fvPGL ii/ElX8boszvaQbfceC1ervwCnPLZCsQ4v039DtnT6PH84tpOQViT5A/7Xs0bcXxntuzL76vNKDM y9dq1SdcQBX+G6fuGy9oW98hpO3XAl+J+Rfx8K8sAF7HcaBT44zxn2NWsoGNJQFsIEa+7t1SESm5 twLIeAso9MdChdjJ+V3qmlWip3QwdMK4/OxtrQ2Lmy51mpUTwUea+la+t86DX365jk4Ml8/H7cF8 ZtuuRSPdFKJuj15e1ixHkEAyNxESyXmgByhTNunDcxCRL/ZXTjhtSLFuTKywJY9a/+DtwdOmWz2L Tx5hexA0ncxSaZuZwhjhFp8+8MTKx7WrmIgcA+zJpOTViXLL+KgIwUIfveSoaHriyMaVP/Nje9mt IZ7RiP+Mkap2IBpNd20f2sKovwq63DEoAah0vYZVfpcpg6nr5q3zniH70aYJAxonkMBHMC0rvmS/ fUtzqSTdcF6g60TMHz0p1qaHC/SlH1fdZo+VL+q2kaZOLAglohTby8CymKmajG4y08Dx52rOTn6M 52ajsok0Uc7efpKNdDq45cbIUHsw92NlZiILA1sfhfVEylwDrf5um9OmWR9hWsZpRp3/W8qenASh b43FaBeeb3K/hC2OFugUslPGf9NjhsnPpLuREyFc3S0sEGeqYvTqNtMgSpMBfNqwyrqzcQWuGjIL G6lP3sUq949xRV7LWcs3LHg/slt3f0YeOTUqjyQcYRw3IWBA7xSyOQ64l7kwivAYDdqz3XQi73+f 3Jq3DCURn8LUhnNWi7UyvqNPi+WfNlkhvcTtwHdGWHURzIbEziCdVqFVyA67NjsOZR+P6MGyWhlw cGm4gipYpQzz8MQbe+lblE6WSWg5U8M3hicGb/ZOGH974yP3q20QV6zKZR8SWWezTPuGNREBWgy1 I3P4UJNlbnuVRn1/FLeRtkkLdC1qI5tZgAgSNysF3okZSeKgfzyB4ww88ufU1HhDWlZeNhR0ijpC NnjL4hhUWHzupOnbkCAO2a/irabn5HUJNRFg8IVhyKeieLgWTLWJUxHhDfD+EA6/dfadT0rIilp7 dad3xW7ouj4WWR6rTx8mRWNbO8Tl01HgVfaitfYIH/74gtrwtp6yY48rYxnBZ/Vq1utpgC70bD4a P/2u0ClkqOsUyqTyDM8qmfS1ZGMcrsAxhOEe60Dr0LHVkrW2kSbD6W/G3URQf4zSr/2Di2ucY7cm hnYSz7GutLrpCTTSIzRTYggiErEpjXfzGx33yWct+5yO0aeH8bp478ynhl1UmO2Y95v9NyOPqlzI gjC9cZY77eIJpvuCezt64k6uADfqd5Sc0cZM3ilWpE/YEc6xPWVCHWF13Q9InP4iHSN4rmDPRuxt a+Dr0JnHBEHLTJo57gzqn+wdRuxHZrmzR6f5g3C4N2dkxxi1VDhITxOJcdXZu6S6bXDzaA6wYSBl gmmk5w6KGT+dR5B46QRT3vSYjPxjujsSc6u3Xn/wnvupS6v4ZlLClAznvsUflKDTUQOXX+r+zPLj 2abk6+MJO41J0Cw6uelVPOz+mFx63mNVoif7uaLELyO6wpIIAKfLFBlpw8Ft1t0uxk4KjY9sbHoH r1xuvvUsRT2obc7PE+fxDMYYoXjIzuiv15JbkDuNhT97PPrOuy9XBeZr8JtsutG+gU/zXPw1YFJ/ WjM4MGeag9UbNtPJ9Hckt1PgqGFjWOO8DgjrLh2Tj2M79bpB2cKCQk8hlnsDefGmMfBGxGYMRJwa DMVtfCPhPWSI5GfmPZkbrEfffKn9ZCuePi6YqPQYlZ3YDSftq+3/+jNGJqWVW9pBfwppR0vt1PIb 9SExzrSH3vIMHTcBTzr+suZLuAoXWN6a3D4427YNDisdjqsdks3CQ7Hy3EfdhvcE4FDE+he7XjG0 0XoD0SPEnOJVdM7dnHl4RhKScmhU9QuScrNOT7YsJwKzI9Gwl4UtcKH0rxLCULU/1jW9qExbKfl0 PWhHOzdxOozjx4TSMMY4j4KnraM88LoiSQAcVCPfK47Pezl7eWTB8F6evYMuuHWr8Fr0QVVcC+aF f2CuoVquUdrA3MJix7S/5GfZ4NUqlDOdH4nm8MRy6yU0oPKgwIVRd5DMhcpSkOC4yH+iCfGfIezM SOSkTjw7Fdq2mjD+rf0smidDVpf8DB/TufL4Le0o+21tN8uGs3bpj9p6743myyfO/aqzplU+BYG/ XfzliEkpe/Hiq8dMsqB8eA1+PIb3Al3B1mW7iZLvpwBgx+XDQSl9AvfyyFIdAgEGtZ67g4g5O9pl OFuDb416V/eesV51Vm8vJ3opKNq6yjKDIXbQUr3X3nIRH5VL2uUYXYo/mTiJymkmmYiuSYxbbmou XpErKSQ0t9bLrLX9QfsK4tw5a+m43TFYyL22Bb8jikNtWbvGOy4Nb6f4SCXLL2n3h9Nr+0aILdjn 5JERd23VoWIEpXLCuqXePi49kjGiLpXqWFoRiz34Fz3IH8g2OM67ns0HXvwmNx+2nNF9ELTLHMXM Fd+5JmfEYXVVl3QzuWxJOV2m9RLkkRmnPWT6/bE14RkQHCcrsqcnxKcbkP45sbSro/NTGASKGSS0 QzsPWaMWtQbyFYbXlVLIbdet7mJkyB5Az6bNxnnKBiguDuBPobvUm4OBI1yZuoWgC3N+BWs+oPJQ VYf3sqWBa0Rf3RH5Vlp1il+vRfNpfId948qpXUrtxqY9fWC9RWbD9rJg9BwiTtuXcpkZ2zlNkMN7 bZLORpmbrSw+xZ4/quZogYW8qH2DtXDbry5FP7XCdnKtFKCgLHj5YuaUiCOWWrZZuy4+anh3bEep WAoK7KR8DgHb0rV6yvTtMWq8Bz7Mc+MXGdGrtZLZW/eqeadxX94lGh1+5toNRgxdoeJoXFw/G2lX rSOsk+y3wXz4Job+7Qjsrk/qC5uZDINylT+8/CTTa+N1Iq7Ho9vejfAxtd6OEIQvdq4nEB7+C+jy 35+H+/8ldMn6/xK65PyP0OW/XyP7360Q5GT9Tyetam/Y4kig+HDs+qVLMPuL+/SACPlzTl+ZfjNq jPDnpfQwoFwHGEjHSpqsvD14yT/AcZGWUmkZBhImmra3V7bTl1a0j6TpC1TZ7UwfnR9NMDD06NWa 3T1FZR29/jn73GdIU8/jp6fvyevq6Mqqtru+7n6t8Hh4zTr6cy3werR1dgi7JG6X5cagf1KsbYZj 5Ixj3TgIO1M/7L6wLo6zVLGYbryenZmsXSps1GwTZHfEoH+wqhWFkX6hXJRiB5/neO5SJPTTycjm 4JVwmbt5m2M5A9A07Gh4Lnz+jLYOpZWmRVGs1oJVrNeyzoYtI6gBG5Ft0dSok2vUVhXVI+vxTStP e9+YDKoK7PtBe00a0euyiGjWRvie8cYoxYRhDtuxxn4bboQTChUhRyrrePP2boR1tLTNINi2kO0s tg1lbB8avI/FTIgce3UoNVtxPkq9lG640xz1dw74PNBcIBI1b1s4hewWEk7niFphQrPjMGoyoTVK aKuZsnk1kscKOZKFWBcWNloP2nLYwWyr28cj2ra2NWJHmIMU+L4JP3wX6OB1Oc8Pg89hxUSroFOM A2+F5fSTAhlz3Ele99D+aGGauQTm6sCbvhZ78iJavt7gRSsU7ikttN6HXWW07+MB3JzD8BIJzSRH XuGgXtg/xbg058428/ZQdWgxsAgZrU2fZT0KECoNYDjRcTfFMVecvjmgLQxTTu8K4fZCKNjLpKsa qa+2NmvQw9RPVNPn4u/llXCiw6EPur0gtXa6//ppURWS1HdJFJRqkpQW3wslXBCHEQ4ga62LdW1K XAoAWkheDqJ3INWFU5XxkK1hH7DUq9/ErkWS7fh+m0opY7L3LLWQNxrUrmK6l6ugAI/gWnMo0d4w 9loTLmlct26j1iT8xJPN4FYYjwkarEAym+F0NDAYFA8HmjFmDlERVQRlihz3ZWa6kksHG3QI7VM1 QSsTYU9OlwfyD5OeTe2xGSEc+UvGUg5QQJOU2kicgx7A2pRQM5euZYuZ6QXOEqvEBIMHIOKUOvFE 4Jkv9n/kw+93anzPUidjr0fTyWBIpI+XAq6VPlUjMCdPtP8rOs/7P0bn3VT9T6LzdP4RnRdKhHML iWCN1+oBzZnej0InjLwKLeolQ71fdDPyi1F5l/NHTGEIqe1FgM/sv+2lKn9wkESnHaQ7uoAhazKK dIxFOixdNSY+0V5HWY9LC42jtrsDukFZrQqE0e8choKIQCGkdopK1RV+AC1TieBsp7WygHLHJAI7 Ebu0hLYnTvYPPGNM7CCvkCik48R5J256MeXwldZhojHWVlKOTwfNjW9Jay3+ArUyNwNv2+2SFVN0 WiFOK8igVUIDD2LHDXNyOCaUhx6DvRJyWGRWkq4rHBYlUBMrD1j9O3/z04FZoHXtG7RFFpZGqaRE /lY8OFsooWDDSTYtKtrLnw2Ii88erlsWVYVWNacah0WgSVih+gYBBg9DsCKWAqHEqAQyLDp0AK6b ZMyPJ8YHwNQx/2YUzicTdg+6nzBneKLLg71diCWDYjOoXo08NUB/jxjMhkpciMB/eCIMt09ZhuJy 3XvjUYyOIabQxFI4MFT43R2k6RSTxmTjB8l2Ry8lxbhEtFbfPiXVOpNYlPY65QYFyjxhb0i6aA7K ZYLQvooxmwiwtS1GeLJhbEw+PINIMpTwF9aytnB0MVJRHXGseTmLObsBNSoubAptHyFSAhbzb9oM quICA6n8XNsgLWF0D2RqlADQ3Um27H8E512Y/zM470LBKYCMS7OdnSkd1qg0cOZ3MW0RqOoh5jBx qmg+GPfcQKNBpxGbkDk1VdBp6Xc6pPQa6U2oKoABiDI1Ufm6DtRkJah2wpzCWx2zgXtfuh5hX28/ iM4xFBC0KfQB2iSRWjiS+wh1ZhTf1nbXUgqopaSWKNe4DjqgdK5hTCHnF6Gk03e559C9Wh5kFX4e IDQoJmWCX4cOKxuUBHmRCeR4BmE9qk/aBS+pd7k2kgL53YD/Rn1jVN1aOUIMwrdMF46KGO3w0wDS 2EONo7w1rsCzK/Fsg5k2X3vY9Jt0BT6OfcgqLD1XqrJU55BTRXKdMylISdh+sXA0pmDsww2eSFrS cO+AANZshFgcA7o6Bn40Kb3OZryiVLc4Cm4Ktog6pgZmulLvmayI1G3aOetIv3wUljKR+D1qpkZt goZjQhDzD/6LdTsrdUgJ4U53Milk10vepTQLOBWZhzfQzsi586RF3QaMcjlvWjokQvxvpyJpLCQ/ C/A6JFsKPwxkgBhlpHTKcUnkfRJL37LhE4d48xPreuHiM/OLyx1/psJsRrpHKydqBTKBr6D2kRDe SMKR9PoKRbXA1C/W6kxIOgrWnzgJgbh6GozHltHCeXk6TE1i0tH3Volkq6h0m9WludSjBmebuQ9A CK2Tz8hDK7sld6p+VlamMdB/lWRt6nSJgZqjfS7IGXc7yxkrm2TSrH7/sKL+oPFSX3r/OIw6Hzvf WLonljtaiGL0yD4ai/SrKnFw5OmyT3o7DcnZ3HNxYum6cZ/kI9tmKDVsoPz+XJ/7Oa/zcXcYZVcb KdqFmwkhK8JVQyEX8istA14Gs8Cm2yeIvXO+raddv/Y6rfmoSx0FeeyScrzRMtQ/FkA+cwSqEVhS 0papr+Bc8a/YvIVkWXegnXyDq4nV1OHT5mKWXbfXVhle31r7Ney2FawMcYyjlDvyyG4i4nWogkB4 eQ/NL8eklqfnW0Ly7GrDee3PMTfcqrHaLuP2by3nY+++ZxQTZKnuF6YTSndrng5BCaGIdqXlN8RB Pzsz5woiIQ/HrJv1eO8HBQKORlaIwXXP9D4dkzJ4awQ/CvK+eD714Y6jZS4xXzuECZbar5qmReOx yGVj/HfMdcZaHDGJR0gRo1B8+UJS5aWxMYQfTbMjhAmwro+L/oCoxTggUfnh/JBOW1Zk9oI6VNBn dcvHsx52zjrF+yk5S3aBh4Vwb9BRTuG4xXkq5GzjLuI3JAG5eydeJdXTlrE3orV5sLfQK/iFnzCV I8M+xV5CrNVIM5iO2/2UMq0w+wjsmK+iMh0T7MXR0Bwu8BZNiJ6I82Gg3N+Sd6VE0FXScCnOFesP TTYeZONBkywI30goL1qNFI2knjFwzWY9R879oIfNoA15P9vkn7jk1LxKvPDwEmQepeD04ryJNGI5 P813Wu1V3gCrffZcoflkZMAvWnLfYmtxU+ZpaxPLzGFJkYvYNjusndvsv99/z3K6kw7uc9B7Up6S dRBqRTxEHMOC7f6KAR/fD9zIu3tZULEih+J4SeH2QKObuhEpsZYQ+LNFpzQhMoZvtoUwk4OEvb9h MTNFs+yRA6JSDxtDzy1yCpBgqpgR5Y3B7MtH6Q4CR2D8eRywjNzsHQfCf8FQj3eN1BtGDbqq066d AFm8rMJIiAfsnWtTKPJPg/iNBKHjUI94Q++5aqnrrS59VE2z0rmbIWxBR6GAXpCaKPsl84gmhU+g aR8yJjGoqH97O3Kp4mW8wYhcr1i5RvwW+ZbxMU32Q/s0ev2sf30sjtRP15KV4yVVYee2luDm7E0P vbLfuHv7+/UFGOfoasx3hjRdRVaiPYKopTWXQQR0Ol8xCTOzlTfoOMupbx15FGbHYQjrqi+KpW5m OySIi8opx1M0Gh4Robd/3q9s19S+TNqXOgmk2XwjrzbmnabWsLS5NmoY+QWibyQ7LGc4lHPIv/xJ PuIi7o9P19ogLVqs1D5Qn79Bf3JvhToPJjfG9fbFBYuJn3k/0uBDt0UdCfBZw7J3m025rdCa3j3B r5sZo/KpIe0dbr2j7njrsTnbjk79KRA0mXnQOsm4wGVIv9cfncY3dBN+SHmqqCWcU6/uFnZbUKzt /gWrUsnw61k3yOKQ0dku4pIzbZVsrbZ7VtuKr0zTaaUSL1VfC29Zf8RMIEdjYumje70W81sWtVk9 dMDO6VUjf2+xS6L/emgfX9CYrXBhXOUaShRleQQAkSaXi6hHZ5W+iF5TdCwvLluxogS9jprgtuX4 KtuNsW/F1TdwwKLr2IGcKW6Zb3qdHd+p9fK9YqDeJHzDUeDS7R0ssHtbYSl1R+Il2ii/Xauvdipg BC/vvXjgVq3/DaxZf2Xy3doV7jc1D1Xttdr9uQ3fB+cO7wLG9XWxtUCjDvbwNFt9cXWbH+VIC2+q ro+BWkLZBivcer6hvW6Pvenpc0hUZSRFRZvdURQWuBZdOg/kJdRD8+/RhriLlCaS+fotVbCXtgYt 32+7Vg2fjr6uj1AdygYDV/2hM44humExf/pWQTgw1zoMBTSKIPA6q6M8LooNBA0eHkedRw9ZEwvV iLjoL9WSB0Qi6KRGygVo8fSPoeYKjraS0lT4uFOiXoyW+XS21K9YOx/AwGK3LG5iYVN0H+SLuLdn jp8wP5N54PUCR5RjPVxWuxZPRDlPlURGBqwdoq+TWrBz9WHgJh34XtIW0bd+ZpKIey2TjDCw3u+1 LbEcAmFx+sN1Sgf98Ntmbt5X1VeuWTrvcOJ749Lv+lLEJRpiOvEKRUrRQhU2LeEGK/4m38+BdeOp GDhgCnyu9XMJqnFskPsK+FbtTfqEyxW4ThrqBHm8nted2vJ6Mol6kvLJ449b98S2iGwYh0h12bsh NWBbpr5cszQmjKdHuoqFHKpj20InYuWQNTWvIoMjKU21RsG8koOJsotB62GsE1rTvLo479JRrvyz 4s0qL9HNMVj6XqvSm51aDXOtB9Pjb02neu1FaVGXa7Ch5xTEpTLDCtoN+AlVWvfe0+sW3peohCMX LtR6Y+oPS4kDVi/Zj+4oOzWKNFw665dqj0XujJ/OaG+EO4Y5s/hZA6aHEWtGDrhwPSOvRQ46LG+n f268kLLED8ol5o9ppxVKEFZ8Ia5uAoVBozxff/VUE35ezJ0HRUXPGirgucnvJBw+Pd4qKGEIOJiQ udU90/+x155/0wFamUg2h9rf0z5z6fJ/VgbNTa3cHjsB4igsXNH8Hz3xfZk9qo730iYVHniD2CpA Bv0oGH11mPMZ27TUcwSVmihJU+YrUd1oJkbHJlOHDyyZXFDmCq62PjFsm5mz9LlwfPoxbCXeCPch 3x+5zGeuGRWeBSeDKbzYqg8Q/L8KCfG/6k7Gcu4GdJPyGu++wFSXYDT/C1Ti32/+pGLhbG1C+XfG 7+Ri7WzobGFnS8Ug5OJsbudIKWZs4WznSMUg8rf8X4Ly8wtEDsQCxAjEEcQOxOnvbQriDFIDQgii 8Jcy/WeOyd8n9b85jiDGfylmEMa/F8e/JPwVLfp3dk8pys3MyMTMyMzEzsTCzMTMTkXIIGdn/F9l /XC0M3YxMvm/qP0/gA5M/1swmQLQUtnZhkGekI2RkUHcwtHJmZCVg5Xtv0Ek2Dg4OP8jIpGjI1PL 2uKwBTnqd2LS8PpMzQ8yIBhNKET8DWB8GdhbhzpiD5QS36V9v3ZCyLrYIO1w39Dybl+UvVWp3x46 xbIaN0Sw2toj+Rwk8XpHfqd5xkDA0dXlGVj5sxc4tOPcGv2E69oW3APoqJ/JIMHs5eQS7vXFiI2v n3kR0Rne8Zbs972ICH37jRyy+YEM+5RGcutjRwjx/Op8AIUbrkZ74s0V6V87I0HV+/Bsxgt9U0hV nH//jtiy8V0zsMA7v2BX/hmGjLRDEMr2Jxy/UO+P0xsCh2KwGI1uucxXRNZ+dRYLf9QxGX9U1J2R jbFEiDAZ0EyoA2vJoK+xglMWs1lRQgwJ7E6tRArMRR0X/HK7+dG9qm/iwUc2WwhLG5PKu+iQYmv+ 6rxxgS05FI4g8vlaiX3EQUTJJ9+XC8SzSen9cat/OmvcfM93qv/Bba2ARqtNSwj7Pazr3HX3wJPT nsEbvLC1H7V3entWijCAQ8VYXmOW8vm4MiKfTWGakwM3zJP+BleCLMXeXYFvgLEbv1SUtsxMYx0y twmEq7iiegDWe+m3X6c9z+Kx0d/uV/4e/TlBQTgm0As0nW43lyg0iC+fgl5QZ7dqlhtwe//HAAkO wRDZHcaMGcAZEDQAod0iQYtyCeLm9iMwCB9sMTJkAFQiICJ2l+8+7Ac0vnAC/ffRSaOwHxEBJLsX SOJCway9yJS9TP7EnTtMgcCKEn5h0AIR61CVj8C+w1FYO5NX8H4qRnncbAE0bihSqJB+ER8gJe9n RMGNvU55ALyMjAufOIUiXr/ymQOSPmjRcj4GJhjsrns7HC1pwOaeL8ruoj0rbb5R2DNKwc2PPCja i90MFLwdUOXXdFiEDBDDy92SxBM1wbQLKmoQlovTG3bXBcM2pPY6Qrsf+O8KrPdu36VY217/IGcI nMjWc/ODsi/v71rPISMpievrf4sdUYMcicllHlAEGmz2wklKxSMFEICXOksiKDJHJDQT20TGhyds B5ZFR3AHK4x8Z8JjxUGlg8oa8sQV1ala7iNycA5FSwc4hsmO3aAH6zE3UREjTONYucrJyiD0pWPS I0grqESIaJB9jhCxJ5Y+9ffOkln8SQB9APtZShi9Hi62RS+BQsSEwcscSKlK8JevhGGQaYEhHPaO MQlJh8tkoIVQnA+8TqmeFxzDOEBw4gHthyd7whmdxK/QuTjHfmX3YNWaeoTrSWcaRPYMTEm40YfQ iG+c+N0isCa5gbWm3xEBL6NK+n3aoB1ewfYAcoh0aomZ5KBL5NeinqPvM/fhydFBTAu4GaU34UKD fK5EmfFBfWjIKbCTonxH/c6BOUMa8/mjmJzY8ygANhzNZKLBmLA89Nd0iXz0YcpKgwI/ogy8EIMq miEJ2ycJaM7sESmY37iw1oiTTuElxAfTgeQJp/C0xBPUMnrR3jKxoAP7dCDL+4ISZDjkYiCmoigL Jn3Q9QaG97KRgvQqDOcYwhCOjGQ4qOncCQcxJtNBI/u1xx3eMRYTjbMZngA1bpEcrxJvEeeZwrBE WL0qLPJ4LFQu/4DJ9bD+oZVWMMMwdDdRy6iIddIJFTlbKa0NAxQriPOCsdk8My6mB96qzJIf1KlE yqNglg2/tMKrv63Wu0jpKFIvs08onZDgANTYSvRZOQPAiexDJO+rhFMbXlS0IbLXG3UFe+I1hVoL WRpgBkL66JbQJ6SPOuYWHfvRXcZdoVSxKdtc8ZuItAnQYPKNpVPoPH4olXDoWxodanqEq1errqpg SatuEIF1Ka+YG5jTAURGlgcbs9u0MNcguI7AS5iqypr71aL0CJDwNIa0Fldj653rxUl8GlWNYAHx 0u6m9+K07GZvgLY094TDUBMsLlSxkBw4UPxaTeLGIWhrjb+mNtgIDz7UpGgLpNO4jU+NmDQFo4Kg bE5hqXK4xzCGLhQEFIMAlNj9L8oDjQhGQv1DIPByah9SaZ5BYOg7OJbl1XF6JG2bMYyrjTsiJA0f DjuaDG5ExZeAMUcw7TDNU9E3QE9mtTphA21oCWraPR3wQtFfOaF/FOej06Fja1O0zsaqc+GFEDCY F0m9WAbSqbyrxTUvpy0Fkl+waYprp3DvqD/gu7LsppxscMwpOIlNDK+xJFExFwJeGBd/xTWz13HA 1XcPTwOG4CrXB+e7ow/iy3rWVxvGTGEDyRN/GScXKEByiJsbAOGUOgxd0aInfpTRDPNjA35Dq3vH 1FM3z5kFw3RoWeLRuBsawMHc+Rgswsgsr6m+RV60/raK1ir4BWakJVyoIgpwlYnWRx7UN9ApTALR H64Vta+FJ9LS2mVKJJOyaWotPK77SJP1MxShpdWdVNGAflI6Et5iaZ9Tat2/SDtfwzxOEFEwcJb4 dRWATLCmDLFO19BcTiJvjGxGW5Dyew3zNiGD9mD990pqtPuiqIFs0ZRBj7itcMa5bK84CWOJA2vN GWO8lMSBpdCwryx6yGgGHwUJf6EoviMC7OoIaFA3gXeIYtYqR319X2Q1oFFQuJ3vzD6Jsx36Tug3 p/BYfD/czqGksja3afzgsCjmWISqqGXRFBxZ9PMgJoppqGjWXz5gHv0ksrnAs21VEjLZrj/K2gGT pTKzd9omSpaIaUBw6j7nCIC9vd873lzGECA5dKNLjJGbjUVaAPe7ebA+VJeEhDWrv8sld28sA4sZ ksiQf9R6UjOoPnAmqhYMSWH6PdHHxr0NGJvMPcgIgeWkcXswCZdRJow44HywSuzEHOhKuogVQWFG P2btG4IcOR18nahdyC6ck+3uKO5o+iCCaW/8+x+C72RyBKP2xk73Q+TqGAnQYm/uSarK4MW991SG +kDhST8Ezw6GkmTwmmh3Dg0GqSkmuUJSxNIRYUi008FhusTPmqS5zlpVNfZDEuAKmLO8aoh3qvex /ioXGBt57ZhyCjmJTKaME32X6OFoCsFKd9uJTTnJmv0D2Sh1BTx7CE4B/zx7eHS/1YATBbbDc8D0 x5mVdV46RV2hmVMh2+R8v9QyIwO0BIEIYio3iJLjXq8VseKqGs6y056OFXEXFSqXoh8uKCNPQmxD b4S/RPtZUnaZ3N7FoB52VyTX2c0ABCxNbERoqiGHrQfCY62Gw3Y5CUmYpam9bMLN9XqRNgJDNADO IzSNfHPiiN7R1vi2rwOXTLPx7MA8I80dwAqTyxMuG3ESE3t6YXAciE6Bx/4mibJqeF6l5RavPZ5d ekZ4LiXB60rX+Uto31BK3UwzVnCULJyY2EkrSGmsulutNS2Jiho3lHE6tVMkPNYZ13+NCAhu97E2 0+098OuacaRF3/fhMItB/2PD8PPj+c/UNeLMiu/nXc9HVsRR3ufN29fbzo7PS5jA58v1Z+7BbQJu 4ibhJYucOevOhxFZoPHzl5nSjlQPn5QYBR7Cfq7F/GBb53G2qpLxDI7Zl6yR+PRNW0u2wrPZov0x bq7F+6BHUX+G0yxXKY+ZR0kEqpluCOxxcaIewsuWne/byE7Or3JH1ztXk6ciNyG9jieGr3MB3/fP lZ3POwbfnIO368rG0o8jr3cNFpSXmpBav9t9v89DADqsIWJO7ddPpZcsBMA6b1B7Wr4J2HrX6XkS a+76nUfjUJy2sciZ+Hx+kp6nTfEn+Cnf46PolrwhKUzhmgU5XJH0wFQHYP0f9CRJGSaeygXcmX5g O3xZntCAzGzdN11nagYhDu4U1qDhtHwPsHZM6i6wGByRoaEfL2Qnwz8cmFQ8oNuZVHRy9GGTsFyM yls1xi2Z2IpsZdHpF1nexzNKpstOYjd9ajtkWuw5pFeMBDwxHhvjBTSvinFYgOYnhkH8PzvqGpXd Fhq7lBLHJBTfbkcEvm7282aoM9hzMwFvHHd5P+/EOcl6nFm+hDdCPpbyfO8GIPvSahE2wrvfJvJ8 nw7Tep5X7Hre/7R8+WR/9KEq/cJO9DJ4eiDwfc6j1nEt/dP4RSX8ijOnZPsitR2xtUkVBh+naSFW OhVF1s8z21kvqgeqqBd4BH+SyLzPMwt0nm0onrxHWbQRTEvO0A+0jdYCiKSk5eOIpLAZdcMNNtSr YDspWXKd3p9dOW7JtBt20LW/vkZ0xMNU1k/IdJTVkZySS5bCZbj+wmcp/vh+k0vkMVe298dTfize hLgpyPD55QnSfC2n8vY5+J5fg6Gzud6ASDYpXuxwUmEXkuju7a645fjWLrwfh9iDP3gpcziEMTaz /tUh5y85I5iz5j+eP8C+wN1RH7/wKovXMVbAk91xBUh9Z0d9hVbRI7jy7auLD1VEPGZdn15vo9b+ aFXFMH/UqIRllchH+fStD1ENXMpStPM1i2YOP62WP0sDmqWQ3nxb/76qMRDjyW1yPZlMJ5K33drV EOiVBJSn4aVA4Odiodnj8uIUoCKyVvGK+aZe624rLkITh2fTOISqolLwG2xge759dl5otfhnTPqp ePNzhNWANGoNv1Ixi0PSNvv0vsQ1PE7pbRFF8JGZISqO7z1LD/J63M/JHgYTPQYT267DE/VTQ2Jc L3a3nkMN85WEfTLzOaF9FMAVnnkTjtSI9cbRlav/tHKCmUXFuxlvJq8vWDtazQ2KCnuY8z6RCE+2 ld+AaSVei60oBksid4rzo8IaJqVrrYCy6et3e/OI6xbis9g9Fv8Ij8wkxQ6Tz7PwGSqWx+Q2wimq O2FpxIua6AytYVnNlXh6427kauhGOSW5ptfFgmkj6XSLfWYPC+JIYc4HJM0nzLSVYcExZdgz8UWH XatEN1OYTkvJN2+mReZ3VBW1gk2wgQmq9fDzcXIum8F7jgqylw52CY69s7uC2i5iO2lhxa7FULMu Ezk7MYEsXsbOe7X1uXHydHbgtlbWg/xw81sIuY4Po5oZ82l1p9tcg8PUrXxhiDdiuO3FtG4AppP7 evxwPYN0e97kKf+p78SIH8XUIyMD6p7GQVfb27Ysj37Sa2Wpt3NXY4yvcMOd7lXIAf6qy8w+yaRK V8tnKdSpnaiM0eHMDGyH+UOGec5IVVNDAR53kWk6fUDDUIy2a+JqgnMp5j+t59g0fIA6v3caFNGs rSXvQf7eKsuFfu48vU3nY+QN3a4477mXoBc4DtGESBElc3Tc6qC1ybnUNgHWQWO7Xnz1IZ9TEb+8 WZYKifXOVea2dob6Sp0kZiVV6tM6UHf944Pc4F3pvsao3czIfQrT95SHnvKr92YAW06x752UaSDG cuzPp3VSu/3DOXxt9R5H21c7lQa4Z/ejOQaSwo9C4SHI0LTt9ZhgRJzStfCM3CE0Vdmu9cOc9PlA OfbMnXAP2IM6+eFStQ6E8xWF6Z6p0oNaqO66saDzJEJ5C0JTlbXvebRrA1REdMwFttafRH1S7bdA HsCvx2gNGjK+tyfaFeUfcY228TU59D/7LVsT/gwoh7JY4Eo9LBvUTLoWARQ/VqgyrozOcvMLt2te IEPVKZuykAncckuiPCacmZuw+NkHmo85vTc5dVUWYpSZ1ZUe8pclMQgwfU8KxCw2OfvEJ4vPC7gs rTUFbKSl52PKmog0F0SUFtJoEOEY+IoB+haoHO3p22WeklNz61VHSblgudetmTiuLM5MaMhhx3pe MLCoSy4B84go/BECbb/tAhypk/0M3E95OFw2r20/YZiCXI13bN0zDR683LDBxHYu24KGPzWbHriQ ipBi3VQ/+TMZmqy0X1CcSwfrvzeHkb9/pBquMZv+aVgY8Oy6xzJF5bIVXEHWIJJFNVcUCtKkBaD1 K7b1nQBgTbtl2nnvufwmXC7rCKd0H0LQCFYfGGGOSeAeeLIEhEadSbTyam2evv39bfB+/PUt1i2S AccBx7G77IshC+lGp4ae+HGwDhmLS493g4fFOuQ/7E4QHZv4wa7Ii8aVOx4+1WxWHKDliJW+ke23 8KUlGiZHaLVYA+Upu+xOvoydVXPd4MibwybswNCsyHFgzCOnOGqNr8JzM1t27lO/I9ktUTzKi9DS xqaJr+C/+ceU1M0//OOF1ynSHOjJtmzLcpyUTrf6Ln6Hw2QX0Kl3E+zat+Cs0dPr82nDf/gVuduh /0wbph84w7fyBr503udGo282bd1t6XlkDmEbp8H2dOV5ItxFsyenYKo8fseJ/isuXyvkup9ae4SK 6dwst3SwU/HVEWuhW/N2yTDXp8V5hw/aTvLOZTXEmGBVt2bDlr7/Y4Ietom6uAO5muClBaeIXOsD u2fayBsp/1bFPAz21d7vwoSomaR8Rcqk6+oF7g5N1TXfacKp/Oplv//ReRQ10VLfw8BtrQVejcj2 ohLWQ2b6HJW9wKe6KELNj1PoGJn8p1gO+7TFc+IxV4FEJZVNxhlD8XvvlZJW1vnAx1jUk/D2/Mur vVx4tVqTFMdmj+ldxvzv4YXf85j3ErD8InIdswT7Eu2z1RBbdipH1RZY4p4sT5qCWwK1uj/SWBcI qnUoS6MTXbFMeE3XTZL3nDpTozwfT8YvS6+VeEViZg5C8sNmVJSEV9MvPMVLt9EHzXIE9GGDi3k6 /yweT354Wh8Vw8AsPatexHMAenIzuJAPyX4PB6/cEVMAvSNaxzQm6KYlbrum8laesqftNDh0H1Bd 287iKk6y/+hWmGWenx3w6vsGqfhVHTrVnL+MH3lXPyYvH6TEpNRSqHW3ueXCpuQZbw86Y/3upWoz E9o86YZD3k3ubCS0dTRWjBq9NHWYs7LgKuErXjioEAgpckg8LwhVfjxuTT4HPU3Wjc7tGowGeMVO oCu2pKfPAWcc2ojPAG/5ug+VIyYLqgKGaZWfrPHjYwhMx7lG8jWlRpkXanFc9UVD4zKDMUMXBkxf uEY0v6eBdzp+pyvauj02J1YUF45LedLzJgQCDu6xfBm+OqJV+F6/IaJejj1/EbbHDG0aMNUOrga2 Nq56W9wU6K+dtBwGPb5YJlV+OifTvyF56UXwUSRdZK06LZiJMiBzAO6KhpIxs5A/poFn3rsP7cvO SwqrhxUCP39O8A/q/QDOvEk9yl289AH32rqrw3Gi/lJCEfXgDmZMzd3gXd1s/2ZOhajy7H4kL6GI Lsal2Ckf/+A5oLSPNhIHAPYf0v9JWPrAZr0um6a69tOrf5SzpSTB1WMkr8IqX65uPodHA5TPNgJb 69PhAKhkw4DBnKHFV/K/7PhClv9sb+6CCUHPaMHg9kMHje5ffYb6gIWLLVgOTmEkDnXplEy/CK9o S5Y51hZbXHcW5f+h/1DpX/1zKesxStfr20ASObVky+1gfw8DLZrSUYxYgOuastV2DeV2l6+VOXUT LqNHekd7FH3rPzbDRvgv7ks6OeK6xk6HWjFicjc9kVzNTsM8naSQU9DqPlMlSXj5TsVXP+46RRLf 0qJM1x9gRR7xTj7+GBXg8buYB7rpReKeNwblGXJw9UM4+9xoECVDs9oIYrAE/x3hschiT0ylXeet 0GobqzjeNbrSkTyVWqVWG25iq86fwijMQ7h09kbk7W7Z3RSf5N6+m/SFPDn2rRuRyAbvf1RsXgMB 6w+OWkS4BAV7tUFn+RY/Tj5yTYhjzoOYrlgmh3dsnt8SvrCybj9dYiwmLsAuiSWu0uTPUt/inC8i AguDh6AKkeTF69qRC3VZcfQDzzJjTOusUTvvlA40GvRe4TrGkNkdBxVjTffe8CYaxIbp7Gg3JPeP nPdjXD7/jjKRC5ccKHo8QmNs8X8Dv5gNr4lK4vZrIKkwitvw2uKnIWM/CW6cVHv+j7g/OzPn/wT7 5uTg+O+wby42rv+Mfc9cXbXabGGc8DzD13zKfA+kDSwU5AZ3ZMrQnRMLRIgsHpIFrB1cesXSrqUa n/l2RWXk1cgpoo2JKL1bU2AgOpFSSMA97yM6PO8j4Own8H5G7tby6dQ94yCqu/MR4BePpQ1QTD6e 3ijdqMciMe2EkUDVvpGIzxraJkf3lMwX+1uFrGwl4L1kkFDouD1S7qZkc0l/60oRsWdYc5SE8GEN YwN8F2IMz/efBaQxSmIK5gZXLpsyDkFUNcaTA+BQTIXQzuFfDPRz1Qk74QE0ooxwyN6g4UEGnqOL 35xRel+S8eHOAaCA6j8UXqsXo5CNjv0pcKFD/uT7agG5KI8mMhB5sibckum9miip/t+nb2AGXSCe UE9wfwUIDfvjTOaXs/d+5lRGsmBCYQLcOBFRFdGOy3uEebAmqXdRCXXHA4Vy9BAwUCOYJCGYBwRj taUCNbMzYcJZnHN3weiV9xgDaVJbCMW3wAGuoF6kfYXC+wNEnUyd4LWMzjhVx/BXZpT92thI03sF zDr1N7it6iit0fvOJ+vqZtK4pJa0uPy9bChoZ2Af8I5vJ5x46sQqWTFFx9AQhCUPDX3OkfGGjnl7 AViOb3BLprCZgT4m5ssYtJl0eMvxEI2k8cOzIVLKsQa74GumcO7geli0OlwDdEEhKCeNfQGMPLOc 1lwirbvBV9mxu3hm32C77QG9SIxsRklENzDWEOmCKr9JgR1YvTDQ7WMa5EjEWIxQiw4Qj6BfaQUj 8SGDuzq7Z1h1MOAIiQVVhKs6oW79HkJwEhEQ1GP5UeTxCvyFbKTymCBSWFnRv+IRe6/rSuHy4hC0 Zlrx+NDiCzJP2oQ4peE2mQXRwOASHdiA8HAoigjAfDJxatxYHCwlZjjU02ss6bgmVQhMksOpm+n0 PXAsg+iQx8holE1w0nAULtgW0TJZd5Et8C5Ug9A2LhDpBio47U7QFYebJ1mDgTFGA0lpul/urxBb NIJrXKjDrPQOGjYJVsUgBJ4egXMn3BFItZL5ymYn3IrfuNTNb9WIQOpEiVDKZEGlyiZlCRUzeqne c2V+6FCzqF4PfsHw1dpz50ScVSNIYAsi8gef9lLhgn9RN/GZzYaBwiWGhBbI3PSM+ihKlz1QOpd8 52AIjfSfjJbOyGcIxSlbgOUAES7fBLNN4DGmYk3h/DPWOXV6IJYREiSJvSleNgTyVdcJeoIuyqo3 DPJI7a/qsAnjqsS7zyuoVEGXz18V8cboQUQP4yE27DsOr8ANtS6sg1ZWgoQRQhX4rTY+dpa2zrkA iwi0IXSvuve+T3uXZFUogA/GUM/gVDgdw5R7wE+InCmEVZI9Ndi/VKNV9tvZoAN3Jyq5iSPQ98D5 RKvzWEtSLtfqmzkKJVE84bcS+tWswcz5Xi5QGHDfuPixy0CWRmBAbDBysoUCJpH0bv4ZhMwPyhMI sEwQeULhpf6977gO4NkhFSH2y5gzqmASN1v9m1BRtzXHZfbkiRlEy7ALRUSrsHdFt5sUTqW3i6h3 BbebVE4/oRdVKkiedQy3WRI2FArIgduH2BHskjpBTG2kNX35Oul3cGCAAQZxZ8Uj6QE59CNJ5TII cillvDjoRagjpkvGESP6ZAMqUPEEkqvscgyqJLdzSfc0Nv8idn+66FanKknmTXB8pt/TDniMxX7o jgibHqZEilv19mgWj/1LxM2KrRDn2MsUmHN/+tkcH/jLmyGvYLhQ1X/+8HyFxUUiKXgJqYRuJtIR aXUybAOefOv3HLI/To9DGb6psR/MARPANHRpZRCPRg/EMyB1tqgKKPR345PIcKuHGOdojdzDJvpD zyUxiRoMHn3SmuqUtKcr3UtJ94AdhAPGgnZKzc4ZmDKUSFD+DTeW+FoLoKmh6+8TfTITjoaJDgqX rYgST+/0nQBJLSt8BdehRgbdFbMgszdcLIsCAveYGSRyfxPEuZF7sMxxD3vO0fZ3uGdA3sDsag8h qYFo6zN3IGDojv6ONX4Suc19urrD+PI8Auz2YNInovS7sCboSso4eMP3AUrQYsPv1yjmCCZkbqKs ECoxkNU2YEFFdQ2iS71WESSO5SalZkgGKVi83rkeuPRjug1X8AE64cNI5bc/aNQs0yQRkPVIRL0N 2OgHPQzKKQd9DVRJmoerO0h/gw38WgRNxzTrHoLqnswGV6isj6yEbkM6nhOMEr6QSGp1ik0f1pjU EuV2R0jArVRA2ap/JUXG5vtJUaIoJsg/HIRZBlaI4yJagc5PY6tH0qOh8XBHmvj3HU9DNPrfJBgV yN3wC6mQnbkAeg7PKpi0nQSZRtStWKwNA3DXGYU1NjsvypEdvNLLRdRrMIiyo4YXj2BgcjI0KiRN 9NuBEoj2iOtAMMjPjNYZnC5uKNfuCcz/DDdexDoQnk7gn9YIfA10dhHlwwrkrk834TyO1zOBuhm0 7GuYFyeT+2IJtq0wnEGaKX+tItpUVm0mirU6NdSEBWoMCCBH/inK/QkX9sAq9r2os0IGKo6tuwRR 3ik5uW2n0HnqGBluQKcR5jOsdTqErjQE+wPaCS2Bbcg+QuMOFVxIajQk4kwHUYn1Wygr8gcsG16C NSYMMw3nsh87aqKsOuZymRHUpQ7e9iyizBahYbhhGTSdPWUKSKeiyeLBEScvxn7fJFPZDVyoYbmM ce7GGX3E2+9KYmhvUht5EpyDo0wCIgTeanpkrqrIgxIkDkkZWozcXLoodbjK8fDXxPN+ODQy9RQH W0MPo8r3Q9k+Ud9yhw1G62RsYzgm3YoVTIjv5YmY1CKyW+BLdHCCD8nRRMiq1XGY2sque3VHwFBE UYXyUxwR/ZRx7XBvtnIn6FT2fHSEyhHku35sEBF6XKuzI7XgYxc4H76jIy1Qg/TKpNkxMnU3g2Ck I0mrs4TWRV1GeempvNCK2sMYtodgHTobd2J2l4Y9B6wrXCuxvj2PpTsNG0s5Q84qMRiF/tBSP51m XDWjWw2481StCAPMCl+P/FB0Sru9/nrsqGObkzo1Ztxl9og9pvXiJLC0UVXJ3AZ4WN+J9fmMBT+P SHYzukGRlvIxFDGEMFXcPUtZmtTcc3kC44z9ClLaGMug3lxdRDirNqD70poWKhaChZ7s8Ky600A7 5rAWf30BUhkeAIAZKj3hC2bFs6xuzYfEH42Mufw6HA8249w6HrLQxvhLU4ZggtefSG4YAoIaTTtM p1AtnXKAs0qeJlutLwrlzL7md+pVJJEPuFffrNpfQzIWJxUO9s3meMOGOZOkXkzXezfzYgIxzxjr dPvNI19DBqiDKuXQxnt/fY+iGN9tFQ3u97vLYtC3Qp3EFfB92U/z+5pg+Lo7DPviTPezDxmR+fyY 2Z9Y+Rq+Tdjf+XzM+7LIfBjp+ThNy9qdQNTYFTrkvt75eNX/4swIG+b91dOgOfh42iNw7JmzvOFB dY4mzeL4YDvAVrZxH3NW6vd+eczg97zV8/F8iOj3STM99vCJU1ncAMMAq7d886KCFvjnKRyLQMW3 PtRO7WbqwNcoRsxOqBTetF78NdqqDqcmimftnWgl5nhTz9V2gl31+e66LaW7tb8fjla+5VqpU6Ge WX7NeiM1QeV4HOqBtBnHCSIjxQLbMANqomziWcevMEZGg3ILWX8vcQo8LUN5kbMt7ZC+afBolMkv Lv5TqCm0ZlVY3To/QkzfSDFzZ7RRg9h7mNWGFvnPLnRp89uv18zxRVb5LRuW2GKc6jDGRPIU58ff Tgl28b5kFt763C66tBAK13oWbLWyhQ7jDBO6ehnacGNqK3H0xh5IuiVtnX9IzwuXCPTu2eid2CDX V2nCPKgUoT5GWc+PgFhsEvZkZ7Q6HIUlc7BOAxbLutE9aBYB0hEq8ncRQFW1K5O+CSrpIOBacGhM epxGykSV6qOw/BFdVspNxGtmBUd9QZmepypT0nZnBYeP3a1Jn4zd/C9yHEabQVnECnS5nwXlrKxj EHIm89prrWW0zSuq7d5Bld7Gbcr+qe/G+4oNyQVppuMd34JMBamoaTw0b9h3y7U/9V7xgNx3+ZFR 336mTJTaP1CsxuHps38jiTmlYVM9ViM7uuKoZo+XQ5L1NW4mcSEpv4J1mpdtR7w5PpCYd77Cgft6 WNH/+pyo9fvKGHyXex0wvrigUKF7z5PaB8zVjHCF2Ffdr7m2HWibYyC1I2aEwi8MQX6EySZNL8KV BpXEdAd0lzTI5h5C72gVjSk7l9hyzYiZPESc3uk0MuYoVFME6KXqmp2HLODS0cu/mLThh/9Z2y2L Y/EOiz8UauJUs/2IIdfyERTWH5CT3mjNyquMkcH3UNeaSz46NpodGstMe6Cvzjn+fEUbcZN8MUc0 6XFX5c9i0m19NRgdsbzD0b9zqmkHd7z2RJWzU7czMjnUB3TeA7DDB8iFbQbhECvAf6+1ZK+3o7+s 3TyXbLNf+eHdqAX8rtyOVHxgXzHmqLxv2K1uSR0bgBDCYSJAJqSVyMTF5hWBBZ85Gm65B7CDtK5D Vgpem6jVZ24XYgfgmyx37f5sWS4ZdQAj0p2snMwcdK5Irzjn7kBv9LBdN/clKfH6QccmEksX3bQs F7s1OVU6T88ndxSLs1nyU/sgmdrgKJNdEM8rmG7ivm5tQNDtvPuLflIiJMSqatN2/IfGL+aSFSxd SZOz2WDLqJ5E+UMrbRXFXzCuT74QdCtYzoY/h0kx/jYwm93la83al+SIZFv3OLKWYh8Qp7Rgu51P XCm1fOjG910OUbMaXOeve8yLWDUfmM0cfxGVlHmOViOYH1dmcwjRVorfSyNFVeAf5Q5OjXfTup8W NGs7rg0mxaTLr4g4NW0WGs8FVOCuKsmAtYmFmZHYAOony0tcJH05CxOba6hPi73rMt28GhPTwO3k fsGnQTYAtivSTxXbAALmDTmTWQYPQso238SSZvDXaRNpf4YoQo10m/qywwDWuX7qvXlfK6YWagQp DFBnb044bmEeWucullr2iIxKsNFaDa23C8o1vWbXdItnJqupaPFP8NCh8wPHSwNcSmRKGX1HWe1c 2e4DMmNfIV4zI3mtRp5I3GjEw1Q1veg1iXB5sIauNo1WjbVFiFyK+LVsuVTXnzbV1TVWE0KulJ36 iF7xS2JVFZMTc0ULkR4yd0v9uJYKOiTqByoe+XKrcDkguts5KSTesCRKsy5KdEmSvX64SH7e71MZ NZbZAGxUzR3a4ceXgOVKVKwOq3lfwco+1p8blTVvsK+f6yz0crmvmN3dgXDMPWEpv8cpG1eYftRs T6wcO2HsHLTOdREwl6sW9vcrKqRxXFasNMxZyWBdIseQq/vwCaXxITbQtHbiT5822KFEE9AeoelM 4w4MAw3r0pXt2+w3Na1tw7dffIMmXPOteS4cl1bYndcgJ7nAndSPf0509+lg0h5tNz6NOxjVM2rJ 9q1OMl3RlqjlxzVuFe7M/hayYmdrOzunPZN26M1VrnNjk2y/wLkYmgNKc2tz2tICJKKoMP9B/GL1 viqcP3m12cr9NUCv7tMloUsFv3oH85iIZaKAc/GzD7jtM/q3ClaNSZp/FkhdvPPfOWhe/C1k6Wkr MZHI/kL3T/75ZJ4/EF4eTemJO4BYnKjDOSDMMCCWJ+o0rFDO1yrupgnP9a8++u0XYI+dgV3nbVn0 b3/Z6zR+/NmYrLemVYOIAgc3gh3JGVp8B/yV2eI+m0klV/PKnU3/5t+Vb1Ar21ZkXaf+l4ushw6X A0BTNIQWPYXLAR9f6KbRT97TDJDZMEyr7MYvqyEFewwM5MtwDLOuoygaSn7/Zb+pISv+r/aSW/pG Zb2T0+FLLjhdY4bn7gzCrUZdr+5bJSismSzcILNo0HYft6QU2TIxBQ395hlWi20fsl1X7fH0tWo/ ++dXkGhOudruVfB7vfv69Ma3e6uvzZhoNrL1Gu1Gj+saPR1rpYjB3+SG6mi8l/OZLwy/JhJchjT4 7fWKxvMpS+Zq1P0Anf6MsJ9yPhzsan7IOvcGHEdjkf9fjL0DkKXN0iDctnvatm3bmLZt27Zt27Zt 9zSmbdvm/857sd+9/+7GRj1ZVZmVqjznRGQ9kXFqlaM+qsgjKANTpMGcLxwHWGThEsOsd0475Xif bQHGXsp0hjzI0FQ2BwdFOcpRd5Y1VtIDtyC5ORW3VhFigfjA5niy8faLqWQWblwQazQ7V18pJ/aE WnGAncS7ZrnMURu3nwMyzUQ3TNYMr7zVGM3GECjhKS/mJRvEkbCDmBy+4MqHRralJ9JNG3oPPBUx mPwnki31zjFeEq0EXixVdUEOg/LACE7NckRIy4mgsZh6rgxiskvy79OGENRjoRU73I4pFUChsMQq 90F7m92thpDoqvLxjn4b7PVpeXVdUfVC3NC/QrhUNOkxId9LmjfJ+XFhgRIkwjfeIbB0lzJHcw6m cSmAEo5lNsyASbUSgdyyB6YpP5yyrlfJI0xkHljNrDdJsSKJ3DIPpinxh0zFYkWCo0lXrAUdy/Pi pOf6yyn0YuQq4kLQJ0E6G2i3ONDOlqlLrnnmqN814BWlcfC20ij0GHwMbpYuEodXZzrBuH5cVYNI 8G6moWL25SNPMhEnY/YAdqLURVq+rMQqlU2eqVJ9JpLW0rJXfCvPy6oXpJg6UwMrgU3e0dx6g8V/ c2wNm85WjrdZP+msSnq0qiE8A+2SsnLZ2NoajQIr6ad1ap5csMSSzKKWBmZrlT2RJbDHHNOJ5ob4 JjaNTxORtqIa2pG2HMa8yXMZ96XJRMYsaqSk5yX3s/QDPuX+yLqmyt0HpLcJt4tGliDz6smqmbw5 msSn6LwJ4TjlPhty81ESt6bEWdMCNApho1ERrbNXYUWX3NAzOKSKDxHQuaoDucWnaAxtpXrfyrDb EHu8gLt2VaGPuemgJzXXdnaDj4tpgpcpcqNSTqruWvZQuZQW69SlH+H7VdbjPl/hkAr4fKBH8oot sU3s1FItnDUxrpTc9HpVLkkMV4kUiocEtitSKG19zNLbZmHpkATRZONQg2HHIkrqkDuZvTkSH19s Hb3rvvxPobzGxCEbcO7Sve2ruGPOik0yxBMoLZwTND/a3q4pb/NbJNlEL5gdTPGtN+XHeyXO48ff uKWg0Z3D9++J9dvhXT5DB5xK1EU2Jl2KTVicAd4E0W3SQ5vEPqE3nUJLzG2D/U0B66Cd78aF7Xzk TMY5zndJ+vmyC6yTMeyyQ+5C3Od01maDSINF++fRZw+Hg7qvHrtsOdhnbFOy5zzbJ3OlNAbcC17o 8DnaNYU+ENaDXhDFEoUZROYr6rbuu2dI7LagV/EPrwBTA9xw8U1mSo743j7gIqU6ICnZffXg88eK dFT3z0gmBJlSaW2O+4dULK2Wa9Vj3SHhXMLFz5gmiAY1+iFXgZLdEReuhKW4ezmzPVWEvWgM0Kta Q0U4dwm4AC2/pHCWzcG7H3SGqY2YnubhPC1dD5DcoXsW+1NddzwpoATBBU7S+Z4meJ8YCf56HtOS eMPnDKuZFQ8Pp1wulbbG1hQTxT5PskccXWI3WuNcU7S2DDqE7X8u93CJyZy2v0tslRt60Y6Y13h7 RxVP6rikTEllXiNx2IhclVBzVcXW9rFPN09mIUzSxqGywHd0Ibc7lVJxVfW2uVwhO4KLrQbnVW7a q4ZlXOtUB+nAjqM6K76quADmSRcrroK+lWNS4hU28Fm2y1XrippDzuaAf5GZpyXf9K1At+MFe/f0 PQhekp7VFeY83Fzw0Ax9PB2fhEYbVUHbNrTTeiG6SBa1sIld3LunTXcpJ5CFGVtpOc/N2KZesXJm zSdIopqcurp0javm36ucrATPaD4JNVFTrv6guby/jYB9pWyyCrbZnedd56Ly5BqSqhQY0WCT6nY8 z/wYVryUvfDJanWBbkhNo/AevLRuqOmQyrC9xZScSaU5pf2mJrLtUIHH/fCoORtweQJbRtx7clnY 3FO3We1E/o2y8fvARbJ+UkwP92MSS/vd+KnCEc4nQjWSy8WDqNznoDW8OfjmzmWeZqnRQ631skOx jSZk1DUxy4KVLXO6N/DlG0AmrtTqf1+oz8D0/7vo+t9v7DnY//nCnoPp/1arzsjGzvjf9+tuxuC2 wnbDx7n+wqr6Ilfgj4ssIJcbgohacRWg3XCay1yC24CV6/WmOMX2bty+ko4G6K4L3YYZzoeDp5Bv pEj+YSBOoVm2r0H8wFrDUsQI+j07gSA55g7FY3QpVCc3j+BlZK6ovjmBYAHZfEhwgG8PxSKePUER JiMgVMkYhJoh0x+QUk4t4AyRENBuSTukZw3F8cCc7HnCGFREMJw00shpwuiVdKubmVB5wJH3+nGn hOjrfcVJzKZ+1nXMJ4WHEPYzb6adDU/FWg23MZE7h1U1xbz9NYz1mM+nRZ+yvNIM8ymD79dpSAdg pGMVLPUohDPK+SCVczLvLxfr1KN1rzOOmdby9qJBtN9xmwNx2N8sbL5xjtgJr2HcJckb/DPekrh1 CqMQkbSrWfHnvznjmjEbDvz9X7mMQmYHE9ajcl/XM2B4QoktsR0dgdXP4zo0W9i9rmxmSX02L9Xx tt5921Mp2pNt9nFmypGO1zsSSc+wCWRzw5NhzfnZSBUbGseKL+b5icR8NcAgG3obkvojsRXJnfVy cVYUUrtxJ6Lknyh+YPQ79kphxbxla3gVUHAKnYdpRQiQqm4oYtynKTmfDPhpSGKMwc/AdXBxCFt5 4Apv9u4JxF2tLPbvMaDYx2neu0d8W54RZSS2Oufmva2zvC4uEiwy+F/VvMPPsvjWHyIWnUgYOSOQ clqVJD7SBOPiXF73eLp1JjCH5OJu8XS9Xw6OhrZ+o3fluvrcjHl9f7Zu888yGZx2P4vxxfp7b6BD cj76Qob2h9rLDrJcXaKnXCrV/vrKTfWuxVQ1mWxf/5y4PJylFFR9ujxxCS/18Lh26WWuLLVJdTpt 6beGPw32Pl6fu/SqSL3aqDmct+J07dRq7/5QL36b8PE8cuH5nejZ+jhfldVJk2rD1mGt+kTC69iZ /TZ3vZEymbR6VtvmnZ4wmducl70eW/T0Du/7fryPmS5eq0V+I7ubPbw5HRJ9/fTyo+QOpuSr9+Nt svTnTzw+nn6WdgNZr5yS0t8iEKeZfN5v76n5nUwdG5XzB5m9tOBrjVGe+TP4Xf6dnwqdm+brwU85 2MmPE06G+d31JX4spyzNyrGBthWyNFupByNurS6n45Nr0j9j1JfVKsW3R+Y3asjWYpnMSi1cjrt1 Ruq7tcBPm3Q4p43lFpLdvVOAXSpSrrNrUlXuyxc+J8yNZSu1MpYLF06ZjZs2Pb1FzjPfqKRlUm0a gU6NE9Q9jlx4f0e62mj2MGPNbtKq2mCdFydDv9cmH46ws6gYHgZUaBVcRCzNnhtyyjh7ttOtOiYu P6TwbBu+tTwnTbvMQu8zX3D6oYFw3K0d4JojFekeefi2SE2Udl09dxb5oPRlvkm1OnY4dDKVfTKu vzdqK/AeOvdukzxOeqzpXiW0rB/OWyvU+f6mdNlpvoyXjvZRDhPdd2n1OmaiPB4j1/ucuaU0K8Tr ZKPRtX1bs0SNYvslmnY7s+D20KmvCj25iQt4/VFhETebMtO2cH27XKr82j4WX1YmdQEIzZoDOkvl 41iqlj87rGDvK8OiFwHoFtLFfVMV3rbHsZV7+5WVn6q6dRxwC/pcTzAD2ysvyvRBDk1j2w2yXKy6 1DLluj5pA6h7bnElKHJbbZl9f95Bp6ZqXL221SKmxVRz7h7ZpaK1/K65p2yv/aQZrCPVRuuJ6V7d BlVj2WUgVmy5CxnhxLRjas5zHYm+r6WnffuVQ1QDqnpSm8LnZAXBdXNZdt19H+E2Sv1DLt9wF8eB +Ay1r2CMEVGdlJDK+EJLAklKwuASjTZj4LJCrjS+d6S6RD60JsCzF+Rg8J2ul4e3y/Pt47325zUf H+/XQff44Dp8Lh7fTO79jenSRG66DlH50z0e3vf9w+A+Wiz31OfLe+/X5bSYeJ4LFDsf5HmT2TyN XSmT7MOSImS6ESTGZfmMUBHGWJzAOC4j2ir6Xc2v+yTzaVvsOAJNIX2gWCF6GOTrXkBJx3iM80ua kOh7OvTzHELxYfbZWhUXjwF8+XvuTm0ODMqFlpCMfHxagxV22cCAGaY6iozIsTVcSmSmkLW0xvs0 qwh33CSZ+iCwmWRMDX2dWeAmCla0/Lz9ONhwXEyAZyXbEKfYfH9bWZXhIG61DHW0gAHnWSWRRyzw mbRgcGlVvPPmARF0plk58oc8atw5kcVE5tjnkhPbwauRV2tyLRtH7HcZe5wPGUQx38of1YO9FPsv tgvvaqvPETAZdtVAKE/2ANeGwGzRF3fwGj8aKHGTnjT82G7rBPUQXy6MQMXNegdntF3Cyzg8LatG U+1dYUz0jnFcthob6FXlyp5lq4RiIYNurg+du0CwIgcrRL5yqzXoAyoy0oH73GpNQJ/tldpVWfDT qHwHdXiGCKFTeU1QwPKTx8Qzu39Q+lD5GmIzoYcZx9EBl0clZHGNIBPQnl7shiqCUigiLa8HWA6j pKfFe6rZQimiX1CRJ4NCoOAr8XcBzaPhK9fZpEwc1w0SAlyh2NXmZaHa1QA0Ac2g2NXUaZE/1Bmg GIuYh44HKoJmUVLLZ/8m2adsK+D0k0V5KAcoJ1SmOlEC1Bje0wLUADVDyVP2UxEo1VDralvtTwZF iKcjbR1XMrJFWWJHHy3QDAaFnxXohQKhOtfen4H04K8D6u9uBIKlyirfCMc4J70APoDiXJo5LotB PKRvGIOqIY8G0I5rBAqB4v8rSa5qAdDuUwJ8CfiM1pNH9qMD0AXo+bHkcFKvZVhKPWYP6Ag6hbJD 06dZFwI5rxP3BLQBCoO6Q9eni+la9Qv4a6Nfhaeo1o5DkB6kH4FWXI3Mdn3DCT0qjFk4z/+K7qmv DBbWyTb8uR4NbIDm/tnDHLgBdoz1VzvgaojGLz8rqdANqzx7IUCzPNvBvQX+/fURrGdATWAr2Cbr lVaWKi7Yc1lgA9hzGWBrLATLv1Q1KfsVm0XZYH04OPpcP/mnATGAqqKACvYri+j/mnqHJgANgAJB CRbwzzPQrOCXa/8c2pIDLAhIhKKtqIPud/Qr2ykqyKBsKysDhZJDyaNEdRSRkftBfmi/CQLMrEjc 5W8CloHRx0jcld+B2dfZLOwWI8zmZ6pWBRvZ5B8S0h0LKDyYYASwwC8mFIDVx+xnDrAQtwNGDxtu o1cCqIR81s9nFQkDaQPwO+4ETA42D1NDEbjtr0kUy0Gbf3tIgKVejf4nW0vCX4NyoyxPU0KYUKwV y1wpPlznoxGV5F0Bg+Ii6mVotqoYvY03RRQ+enfdz+REqiyAQa6ABcSkGG8hscdLCFkxOc4nWJzf rUTsOAKnel7gC1wBjuep+aE7H981N2gC1xAeYr+4oDz/6gK2oj+5j3IvAHgJt+3T5hBfY9aGj/hE clxFDnYqBYv7Av3Hdq0UiTxj0txM+mxIGrTDVxQ7+SfTU6AvbxZ8p0JJ+mwXRA8dn3prIb2YsPbH eEnvNggaEsMHOOpTwy/yiTrTx2wt4j+lDwjUlTR6sqPk0j+nLYF0J7bI7t6FjJ6R3c8QV5+H9hMu e1dgRXNmGVNqIbltwz1/xBq4jcWjTya53QyobXH+DKE/dKK9Kb6QUrTxFc8LtdJ2hxrs5YL8AI6P c+HqjGV5djchNL4JhfD3ZUB4ieYr2tzBnSk8A7zY3Nny1fHWXsntY4846Csd+JS39Q1Z3558Qqv5 pDhblVi5t2WqhSqC5g26oEN9xxr8Qq+b3XymeN01u1y3/YKmsDtU+9+n0Yz0bP9KozX/JMR//+fV n8bOzvH3yMTE9DfQ47OwM//N8Qf7M/4BFhbW/yf4N/9fOv7AP2ywsrL9DWyMjH/D3zgDAz7bX5x/ 8H/484f6Rwf7X3b/5vyL+odG/58y/5xzMDP/U4b+n/L/a1f/9oie/j88+/f8j82/4M/6n/GPxf/e yZ/d/73+Lzn6f/jxt85/gDb+fwT435VF/xlg+v8K7/9s/7sQ0v+z/+/2r+DR/7P/R/tfltj/1s72 b/wfofnT/hGq/25/rPwJ6P8c/+HhH+xfev+Mf74if2j/E5j+ov1L4l/S/7D91+y/AvM/r2j9v5zS mP+rqMo5TsZiiB4m+Jk3OGVheIeYZooUZA0DSv0htITHz5CqPL8+eo/a4X0iJy5FELQl/pEnn8zd hq66EfGAyn1TP6ifU4j9PZhZMLbQuaCqTw2nlXrbQ0FAHNX1HNveYnNHRDvQa38P2zx4sPuWZwvi VRBsvAMRDu845t4GcheazAkRao5Zz25H9CcldyWkgMlqPYtWqz1Pw1Gomy6wYPL9HWfUE9hxHnOC A1FEx45Zns+BGQjnfWlP+ZuAL6WkU/ppQYeRx/t2efdpuVFULuUC/LDo98KDk+uwjS+bzGBR9qXs o+AQ6b1BY+fBJOeGK56XeIVTD2CzbejX/+H3y0D//xRFBgYWBsZ/In99ikysrPT/GdULT0gtJeX3 b8er7sY6+EpqQjRwBKNMwGSReYE+WBFQJTuJEH0/eT1SdP5FmPpF+mRWGU3iZofT6n6aqY0JVJlJ Vt3JRWkFqtYpEt3gd9+r9H7R/cvLZx+3797v99eP2V2fa8ccx5nG7MMtpikAQAB4ELiXhyzEwZ6Y CCgA8UcgiDGs5Ewmr0/sVZ0q6kGV99GDoZHDXp90YPzzem59wbeTrrWB0HUAYsou2pOJ5pJrEuTf AP6xBplW2tHp153fT4YA3rR6PKpWlBS5GV45oCfOMJOVUk3KpDfA4IuhjALyCiqqWkxGN8cA8qoA Kz7FIodMpSbdBaB2Z+GiKSlnzSK6NovcMQ2FdZ8A8btLU6T67RCTBMWHR+k9YmkgAGCR0urp8qXZ mLyHQgDKEC3m5MszzAy8CXjxOkGwL1DW7V9NBhcwACxv+ykGjCrpwQj86hms9VtK5WwyKzcTej94 kC/LgRhUkPzu9CdjfjpKtdPCJwWmLcH5mua5bbNRSxBC4AQeHB/IqjkVXA4HubYrjuIPQeJkXg2N zW5Wn0qzJDWiFfb/YgSGCgu+FddOqGqZ2IFLJF2kTa1KGDJkWPQwzcxPu7UzIUEaQEhPih+7SoRp L1xw+6W1W2sVzz3HkDQ0mT3W+ehq2T4oJxjuqzY5JWrWqTuQS1IDIfhNdvnte/Y1NCJkf8y+w3Po u57DJ+FpHNTX6AJz6quxb2Xueo7fhwQ5uedB5ITxPv+RqQXAMRYMtzGLjYDTjzgHmYWQ3a9uBo5m J+AEqirMZod8tYOpit8RyFUA7obvEUBWgOZG4BEYa4flRf7khxtWJvYCfoXoE/a1E4sOADhAcwLJ gwicj+bgQbAVgA8heOAvBhOiN7T1C0seUnKXDcIfYUgOQgimcAX8DYKNAHsAkQgfqJ7uQSQqSHwX TFjghwHzEP4IP7UBtQhKWdB5HhiLAfYQwYhQlx3smwBf0fsgQBE4P5AB0LCwuLB0APGuqniI0ZA/ PQIDqEJQ5Q0AjCA2SCAieKDoCyhzmCoBigJiaB/CELO4kA9nEZFJn9xQPr10G9CgHvueXQSRHsie OHp4GmR6WKHejz2zMSRaIdQoAWxgQ8TRAfZdpKjCNNjVMI64wDTo9rB9/QA7RNI+4aHwuNA08New 1x9k/cS7QNIh42GKelB7Sm4ItwJppB8wC3kA9QBNYRpDuXkIUPFL/nD1EBFxhaEGQwbkAtT+Crti 5KDABYAlRLJi3PBMemAGGEkEKULBdnCUfWFNiNJhpG4QHPACJAYkw5RlgsyBGPWYFkGNL0blIlXB 6WFM+XD1cCYEMwGrA/D0mXvYaYEv9FMiWdCx+LxAj4JYi4PcQ+6//FYA7oOZ6HP3Cm/I9wzrAOwB qYW1ICIR0Pr3B55v2JkJWQcMhobDSnch3YDsIakFtKAmg671MJgJWPsTx9yRcgTfKNwwb83dwG4x hhTbZLgj27BV8Gv8joMSb7CrhLUgKxFU++/DZgehByDdAG+JuyDoCD+RqkQ9WJiJNmHoiHpgLBGW +zR2NdWgzxGW+6nCauW8UHSEvGCXiGpCYcOw9ArtsFkHSIdkbjpuYLvgfIXebMO2+7BuSPcy9QSa +CNvWJr6TIam60Dtoa1ENqDWgwzrYFuIbEJbEbYDVIZUVvzbgLdQv+BsB2WHsm/g9rjqpNihOvXY 9mxWArN46tBOu+vg7fG6Il9ou8i8QK/7fYY+b3j33m/8b0i8APAIfSDwCI6J2P0eANnD3BB4RT/Q 4QhwAwbDQneRh37uhN2AekneQniFvGB40XrB5Q6ihen2pYbpDqgOmN6gYIu8kWMLfXDtmdrB9Ih+ YPYIfIDFQIvtsHtFvtBk8XMDkgX/3CX2CnWDkiXyCX2BzAq5jv/CncHP8Wc9aOqHD+PrUx9qtNNh hzneERu6/+EblBskdIP8EfXCpMXfBYCGSDdAMiRlB3rL+EHoBaO6QznfK9cF1Ut4rNoW4gZbAw2+ y7nB/wb2EfIg0xb8gvUBfIu6B+i13R79YN0W6Aa+Fr8AhzMg9ksAQB4fRH5j/bZ7WYIUmc27U6zP 96N82PlZcfIVnvdjV6S+E7knwqUWDq0dWzfqu9PbztGOH4+dK6ZL89A1vujOZinfzqlrFjzUJnlb JIHDqRHO9SxwKOZ++ziwNBH5Ta/3J7tL5QdtwkZ9prNbZ9tORMtzf/sf0YOZzarB5d8o3nW6hrSb lL2RBzvz05xAP6Ae+n18Opz/yCRqsp1DOLmOao9vgYu0TlwTclB1qINfn4bzrtQyxP4x6HB7YoLT r6NzEpiIc9w7GyqHh+fFufK+87v6rlPcRmezqrA2F+9tx2L0dO4P5YqnQ11Mejbnxanuub/2jxfc H39RtGr/UjAQg/zrD48O4GaVIcDsfmZdJ06p6h+r7s9nJjjjkiR/NnPzx9PFwGsTHPPd3ZeSXevR 11jfD1yEtWlOxsLCW4pLy9HwE5VX7SIdxM0qIjJauNz5L5estD++QsWcmuAoIiHdQKKZjYZf/2H6 9WKzJJ+UEGB7L+CSFfQ3088TH5yoS74AnaVYNghZakLQd1/8AbwvU/KUS/jdiCvWM98c3AoQx1ao A3zEIcPql354R5IXyYfkFCpNEEC/edR4F65A99z1Hs/9wrkDONwH/om+g6KhoK/Pvf3FipW0k7Kx HsRd7wFBoaTuwNc8HX8e4I9PL88XN093jzaqDS3trGxsnAPG8iBDDCB5jIl80C6Sqr6BYIpQ+FjU SUkaxiaXKCDo2Kr855b6G9AmDF9bKdgW6p7a4pE1BcdWEvkbijgknGFTcvfJXSeSbUnS6EkhD4kO xtxWraIHM0lH/aadgOAdvYt+05eUkntUhT5TtZClJFaTH0WFXahko8zGGVsMnFAa2NlxToIT80Lm FgQ8YIiS9DyMCZrocZ15yqi+xh4hwz/TaTP09IWYmkRS6vfvGOeBAwLvCwupiWVKqZv8HMKGaRJY /ZkrRghlGsfKMLfwO4AjX1PKuqN/NlHm1eHPt4urF2UnmOo3vxbAPYsvZtqcMlROPz8TQj2LT2qa 6WL1sZq8YLrVr6y0xbUyx0421sKiMvDhGevpkjqZCezLKX2CiDIwhYpZTxm+uqPeoVcciPwUrq36 Ok3GICzV47S1l4OTT2GVpeurv7Vt4nfRvjHx9Z2G2+W6md3BcrxP6k/pB5zwsvaYRaUzm6pZ3yvd /byqDo+xkG/TBF7fOzMhytK+gPzc5JScOyJMTvdmaxBuEucAMg0KXr41k8hB8pb8IZALEd0hbBVC katHJ4UYE9a/F6fyq0wc9dXAN5JYKf8AqxZ4BuBwGPrZoYk1hlnJHkdYIYvM9RhzyXU+ZUxcartn 70d88W5aQXSgWbuvk5IMVWIFM4Vbl/6LHvWISmYuduQuPBwquJt9JRhUvV45Xqopzb0ceh0Gc338 K2oJf9Xquvo+j05V+XVV+3o3fziTO5X2xBaq+8omH1twrKmoeUPwy4dE85ZGbnrhFDYbReysGXXd MCvTc05CM++tTXZ0g1vJYT1gVLQBkJpGZKLDxOaIAcHs6kDwXm6S7FmBSjq2Kckhgk+ZiDz9RsRr TH+/b71ipZ3IhYhtr2tjurlETFcr903OHc8RB1uDGT3aiNGRrIWVU1cpHNpLHCqJOnONiBDqofTE en7f8rZIu3smxkARCsy4LWR/RxcOt0120uTGYQSJDrUAaT9kZ3r8QoUfDqafh8akPBjNuQakXE5X ohj/8oSaO9TE4A9Ymnbcch1pvCl9aXT0cPiWTFF7mOH+H4YiRgZso2CgzYwMmZnDmotHfRBdwWZZ su/g5e9uIMUPiJM8zMCThAE96ydoTpi1Mt57AajFQ6DTo1SotZjUkZdvVlEQjE8MKVho6GgOkH6h XtzX7ZMs1QdTT7c6cDpwkDLVRrGkEktNUktNIktKhJaUCSwySSywySywcSzDYxmExjL5DSUI6akb QjVxnRPZhzEO7VqUxwdR2Ac61QOuGeK3qxckymFs5S/WFDvk1XrCP3p3ApHTCBzARAOGE6eNGB1D 4qQndXCMUO9SsDgmVPbCiKjk4QhQY6XHpnD2LCWipqySIVdTgsakI60uDrpQBVOOiJYHqAfCjo+a kQSMeFDxbQq4/BB260kAWzx9eF8WYZ5wLhjGeMzNPNDk9AbHthNti7wnsDWf4UDiLbh5QRHvUdV/ LTDGZwZukE5YI7XLJJ1jmannpCearqKn2YYjQxLQ51pJbJak01x1gk7A8OiApgyzFPekvAnm2M5Z NVqP6YMGdyjc1vzWbKF4PEWNZsy2lcjeFHm0qudUTt8CamRyuNcwsXw4zVRkKceQtPb4ghsjDKbx Tt0qvLqVdebKo6P4KBxSUSCPuKCymNJYCx4pNnBOKbMv//MwSCWKsJigDwFiZy4ThhK8tq2cekPv H4QZyiMgZPENieljCoOb6NVdb/i1ctxCO8m2PXPsOy6C0tVTcrJwKlcNQBKptEfEqmkmX2/49wPa Jj62UII2bCYL4Tdw3vUokZDeTNMXRaJpNAitTC7aPkFERE7FgowryUmJCiDo8KyaDsFDBC20VFYT 6baRpwNOxJwOtHoPxRq3rtFazu8h3ghwC0YHue5CXZB661NfoMT4wd2laYSJfjG6QT8NSIiHEmbt fRnB3QxA34AE9XuZhRDP6K6AFe50bcB64YMkhCMWuUXR+KeOtdIDMcqP8KODxQqR7LEfbBOHqwnd bNpSWviC5YRu3kBmAfEloQOLhUdt/HARxDzIg23UB89KgomnBvvphqQTCFsH74PPYITzGt5NbIUM B8lnWAshNwiQRu2DDJwTkFq/aXnDUGi0DPU1YKXffYP4IHzOlr/8vuO96Bx4YwQ0x1Db4IzzjUAZ JIP/5Tig2YTrSOmRGGzbWas3WWiXya5n0+ftQF94bofmEUYFGvsVb7btRh7aXgeRkodWqcfSBXk8 rqcgCZcoFQWtOHsRH5VsPN6A/dTkSwKDbBO2jRqg1+RCOOWXvnL/Vw6aYjibKr/sM6Walw2DDzyO zxhglGhsBOge/DEizDiavl5FdT4iWv9qBcgV+pnTTZLaFHuqNmcvjE41NaS25xJ0CzNcVixEKw2I rCRAM+Xv0WRDcUQatUU6hRp1jDt13Q/JHvhKnRUKHUSA9DAX/zBcNcAdZzYmzpgjTURSFFGFvy5B tSqzRcYXbynNZwKQOBSl35CONDKUlk46MtBE75nGeqTaxJg+rVe5IrYic9F5IXZxfMHGfi7moDHT p+w4a4d6RXUF5Rp9HucnHM4hWpDM3Fp7OnaRRh0ECRwsqB/+K+iVe6Qt9YWG9CTwK2pY/nf4dolA rfQNwhFn1KbhyZyDG6QhmagtV9MAF7vUNkovF6DYDtbDNYgXnQ8XQCDR27FMgASzvKEXHv4g/c8B +woCR3EedUkV/SzNMdYpz/HWE2NwD3b/cVNcI4s0jikkE9B77sbA1Uns4XgENYqYIDquqGkjsobE VXB1ps4s7xjt8Z6hGhPN1e4LcOxBEkfDdkkb3uWh6t2tA96Dnp2e5DJiYJLoNJoE6wTthEYFeHO/ plxmsTXKxInzv065OHWgvEGoKy7f8uHUhFDzQL5Ex2ox1aZwDO5RyI5JzHa5CbzsQBQgxFL5QDUF wf4HjqT+0kbORkgjtf4/EsdvCNcTtQdjgoQSoBIGY0hE4gar/bgSnvmpzI1YG6OK4q3JWtNk5KCk 0jEusYK89qA4jHDuKWfSQglACdl92SeI7bnEyZH7L+K7BTT046QnSOvHHdioqw1n89I5HNjukM1W r+0/s0aak6e7IjwH1O+qrWA0lmd6wq1xQwSMtEO5rOIOmECLyBpjoixyt32ivHXUZD7SrgHXNtcV 05mz7PeDo6ds2mCoOG3st/ttjtijRrWFxFRnlLU8m9sWpP24oqBrSrE3xKTb2JJ36huEgdzmU/r5 ZejKpUNLeSBLDfvlKefqqfev8fedQD4OEMN74tUjLCkK1xUbfrApiFKtKerZSXpGuJUr3171X+X3 X/WTYG/srna7MiO1wXK3pvp8qpkFXtvzOYPpirtBh0WWwoiVJU9tnhWqsL+2JvBHNxryobEszzpm 5H5BbosPR7c8tbCib/gQGdPbP4tLKlRyJ1upffsA7+3f+FHePyRQeq5HxIYcSoQOVSiQSFtIO1lY OElTUugTvXuWRmOyTNReXz4bKCgaGjBjvmUIyNp9RYF5Py6zC+FLfZDsjN7uFuhaRzQicHVoVzvA P8EdfdjmGjNzvkmATDIUJ5zugPDkeVgGbHCFWZOMY5K14oPfnM8NbnNA1HVNE4mfHZ+HLqboMcjG qy+L6lr1piXn/+SDDhRRqJasXHgg4fnhEItg5+wER6CDrcALo3DF2Iqwtxe0Q3EL548LIuDlh4h4 hMhlavw5kNRdvKXDe2sPnDZfHbtou6nxPbZ0C6tYOpXLZ2wBnHoztlQdu8OyrGFT5/OKxe57Beax A3b6gjSkZG2MA8wR2ppOGcfAgomHdsyvyia2xBIrDiyQcny0U1o3AjL6hgl3xWKfZb9oGxbM2hwx FMngoNoB/gxPKh6fqOHQRaS0PpeZdXFCMxLTOYdYdQlBMtp8WWj2Q/FXSM+GTMd+zaJbsNSbOHLx hTCFvhphMsAoozSVYq19gp0O0oY7uwGV1O10vH5xH2hD9VTfNDGCxpwBWzv1r/65eENIaPxEjhZG CUwxsnYlyltXuJKUbXH5HRAU+fgAX6ecLbNe+3jqpFFhB3iqp/1NNgeC5xsfu5+SAxglKv1Cishv yPO6G49dgYor8a4tjalXbmHL41ANGVXpW7uY2z1NAIMYppMs38Rsn8vHuuLcR8rftiYd/c+GFlc+ IyygnHzwP3JPPbCmd2Ke0qJN7EczDQo5OlmRNhJz6uYU4gYdWTVirmWnWdcAt/laVszEBgZTWdcg 98ZYsC5hbt3sGudpjUATbQu1CUK6CX0ixuvNYpmWI+eRbtFgtWCKi5P4wuYZJ/AkzDmKyeQ1Psh8 qNg2RZHtUh4a52DaJKdYM4KtJGyxpleb4/1qi/pFpQQI1I0LDxFIV80KcfTCDsKiXYyYFeCxLkFE 7qz+Mjh8d8m6FmzueGJeqK0fwSS3NjcjdjvJDnVMkeTSst8Z0eSIUYxS8DnjSH4Z3hTqSFTcfbHm ucCuZo7H1YN3+Q5UDFxGWznF38kq4OIEYW37yJYxX01I09qobkO2vRpzbdXI1zpTRLd09vABxtuq NBvLqoI+Pba3EJVMali8ZEWvclPCqA2TW8Ni+V0lb6GOkWtNTsGierv6RultHN1T1qjtIKvtnl8f 9bNmTlUl3Po3AyQlr1eTgKp5FSNqJlHDI8lv47UJyJazLwbK5ObJk43Ojl9yhhLFS0oaprPz96fJ axpCIpB8JW0rfjZliUiJDlKwyl719QNT5whNIRGUvMtyNbV7jQ/NXi31Wpr98JWL56Y3nNXjeksp yrdrEYQ9U2qVtYvmlQ/yXvX5RR0KtsZoFpUwnFtK2vlMqpo8LFhSD0cK3iS6lvSpdxpKCioly3OU hgy6NcOcIIGymiOqGJKUVQaSDyhvkgdpFQxGyh4+Vf7LyRZUzZxMnDiD9/vxqlZVB5UPJo0nMzwG woDKnIE9A1b8ZK8ahocwEwsq8o+HJYxO8JssWO4Xw6pzK+EEZSOiIVA9E1HVzckizOTKDMUmjRQc rC0tLawlG6iT6ElImha0dJE0bJF8GRE0tRkmKMhEDt8GsRreGA6Pf2XMaRuIQmJFxUcx6InDsRgT sZjxKfHJif2lcJMzY+jZ8cnneyd7L6mYh1iVDNjOXiwhY16uZnOuiT0NG3qs5/ZxZ2X7GPtixfPk EaCKxfVlGqaon7U0LDsU3889bmxKJxMVkXVUI1VjcsaUQqAG4jLJYOtd/X57bU6UbCpJv293QyB0 dHXIn960VURMz2llCqYjhxCHIY1rmH+5G5Tidm4ns8RpINjw05h4t7c1UMKWNY+pacqbLK5RiRQ2 qyjaYxb0inLiRf82UWxOp5tfDqMCXE86m5R+dn8oJaJIMZiscxRJdka4/bAcuvfg6FFN3e30xEmB yo9p22k04Uzx/eFbadfKCz47oXHwg0BFELEzwlrftd7zZq2/Z7on5niO04treR9SNvL62oOby7aP Cu0nFiEPJkn4/FSLCneOvsgqaYTGAZYZNC6H8QofWLnTxPLXeoLC8Lb2Dg8WB8nKelSpcX3RaCfu +hI+6qeADqOHRigvGuHPi2zpdWWDXNl2iyZaQCXxYENbYA3NcBZlN5TCJIiKfJCK+lb0csjnx6vY buW0y+Yo0euvk1SWAtEkZYmfvMVqX6bVD8w6Bp0ai0r+3m7ogU8/FN8fFs+IxYekogr9RQvSJhiJ ihvlNdZaIyRZ8pw9JE13u1NEZ8SPA06G6ReLR7kDn1CrmX59GTeFOufcqDEa/JzzrY9GfySvWObf VzRP3F7tiGtBvEQxFWBxcCZvfMthYFlwO7nVkTy8W9StH1pILyi8pR7kzNamszdys+hs1m2XKYnR mFKsJmGd5apGbFaSw1liJbWoD49pQp+tXxFbVJUUU5d6VBfTyOrkjmptpiq5TyglYfptgZPtayNT Cqo8xiBHNbRmoGlkUd6F4XLZxNpZvZW6gGKEw3N+EsGwb90hXN472zmjLmedaJQ3V9HhWrw+/WOu VeEsGHJZhPpII8NQbq/7nnHERIraWjemwwBxekVUigZZSpn+EtfS4KrlUgdnD4a6sfn3uvn4AEoC NJEeuY55m2bYA/pBBJUp+R75xCy/LFxBWy7MIEucvzvz4VEAdA7sMFXuyC/OEme32pbo7vbIZhMc GuRsqkOnq4xTXuKZb85O+4k+DGYo5y/eQE5LaadeCkEaTso5TotmpdSYmqCaB41JsI6KiTrbeJlK Z5cfcx7Im41nF0cpZZN227T62apL6j69xwaRjJLBhr0QXeenLy5nZxM1EXxjX+fyb9oec5vJxpuq U4t3267+Nd1sKy7J75eYZmjAc8iVdCYVtfcSRBOtbxrCz+1QHdvm3+WlS+KW1+EVzvBMazfP2jJR FelXHCaUurE/82eyNyhLk2YsFnrRC319SZyXhuc3hcVIVDZbfTi34ZqaZExfmb0zf23fu+T3Hn/6 X1Fp0clOGzsMtoEjJNY1o3r/KCTTSKH8wk24kjKgW/8ZEqR32/qpTZriMzgEHIb/aynIxGMETjy0 U/cLVlyeBYRYEueNFr1npwQ6nmEaFhBxDMoYQp6rHLsoQVw15TbVT5LKOSoJKYaZmD7IckY+WlFk 1d6j5lR5W/FjleqIgR2w8gSspNQfj9hEuS6bfua8r45APrgQDLsb38u5SffzcZou2Je7u73/PanC fzNW1YlpEiFEHmZ9//minGRVaMEGlw7vqkCn1KHdkjI+T/4eVZFo9TZrMTE9qeJJxT0CtL30Xtjr c1FV5cZcI1HnsvgOYZXxZ+nD2YSgtUg0YCy9BVtSiJbYT3Ob8palKlXwCiDhkMTS1OT+0lOqU8Qg 3KBFgQr++ozHh3rlBcUUdU0bpG3XBQXlbo+2sr3f9hU+lBmkj3bykcMvbS9fEp+JpOUOF1E4uYVX +XctZ67DiXkE4LOy8h9hUNpRnAoo+sqLnY0BFXuOnM6HO+7IupqVwsWwRa3eSmEgK2B7YGOuRpgQ /rDgbLVcTmm+C7e7o7q6at7Glkt0pU/tlxRzVxqai/eZ2a1wI7YeSo9uWxtkMbPsDDskrTy52mnu zU+/20eSeH72nt65nDY3mMJdTcRsMX/4n6/3ZnDS+Kl/xq5gdC9tanWeKX/Hpi3ERk3w7mvYCSw4 XsGlJgbybXhY7NaYN5ZUGq4k33Mvw+/zyau2S0fxcjfqfjTiUvG4ZFFHb7o9TXVG/3zwtrW/GdjT vr8nxax8LrKC0WR/zBvgMn4s5Du8cqxa2b79GkPmMrqi8pjl4C2bNe020VGr5r2ZXN3yGX22xUhp mfDVcKwtaQGv1c24nxzMhBpvOC/MlsU95dH/bAzdVlO6Hylu1faxxvp0vr+cP2LrArNRb7MlG9wb 0uW6brPYYlDmK8c2rRImJAqCVg0uF+ScpGzoW3ZRoj+rkGZwc2ALC1W/reI/ls0jIwAiU5W4HUGQ K47owqdVTy7D/LVRy2HjP7Gkraru8vNa7VyrPpfSvJxhJWJmsU9uRv1wxRyUSrU9QppNPvUlmYZC I8zYFc70iJNPOXbmddqD8/ioaE9YKkpF7Dm211a57v6ofwyj1WfCk6279O22Izl+8pm5SzbmCdt5 ZT5N1V4St/6pPxaO99I9ZtKlnbvqJzWxxhocd3bz2eRW8BYbOBlILEP5ua96Vpvd5Os9Vd7+wu1k oyDv9i8yyyUsW3NF38v38XZgXT43A9MDw8CW7rbL8wXk4E3N7VzPT8Xj1Jqqk7APAz0Xfn6D3MxA sT1MVCXYKY51TpdXhruJ1FFC1NcRCWxcLeXGky/nDzx1DF+tmArh90P2WzrKaGURzeSQT6pig+ye O13a8WnDwdDclwKnpcKe0+HfisdXttrV0Mi44p76MZ4FhE5ev5d/e8NcqnO9UOiyb1nAnXjafwTp XdbrjK5vhefe7h4iWyI/SAHnuGzlLFhOZO19LRBHY+CwqJc6nC1P7et6Gc4lsdxl8pXZaJ9l01uE 7ZOV8kKs+Tp9xN6D2U7qYDXHT3V0mOwnfOFUzspm06p/9kUxeaZcX7Ir2Uk5yi5lfd132aPUPnR3 dMsj+tivts4fgRqqTuNSuMqD4ip1Me8fxbrb2mExU7GF5uoe3XtMpGMbHqF96m6YUENtNHBbHAMf n/nQ5jpPHlutbG91dTEe08gsNlY7Y3H1TG390M/hOhBUqGVZ8J45uoah4AF7NI8IfmSykrrLs9gK /T5KcOrpJMbg5hzRRDNMqqil7OKo4jASuPZtQZ9WVp7jpNH24XV6DSf8MgKVfP4qRlm5/kIhj7kb SC+xbWiA5Hvt7ACGrfi85PpIufZA2lp3frkBX9aKhWwVvY6mU2rv9d3EvjlUJCvt7vNsmRpf4Xm6 +XB85DnqXTo+RZrNb4Vv4U2dwPXw2TAa3xNbwvKFRcdCQHL8XVdU9TydDe6d031itaWp8f44SwWN dlVp8XZpf099WNI8O60z5+CoPiRUaFgBHFLq42icCZ3r2dTiLhI48+vqxnw/+SwbbtbXe9Lba4XS euNKPcr4KWDTcktzg8viyPTTcsu9wmKiGsdUzJ2LEr7Z+8u4Nw0R8/pHa4A6AV6Xgpf7a2lJLnh2 5xHj8/rsUVW1+1jddTDDoNJnoOZS16luGtLr43y0t3Fj7KtNOuP7O5oug0sR9xebMvCxv2YfX5Wm H9ZF4DAFReQGH5aTkOtu0givAfYVQMlM8+XBKte0WUXlDz7Nw0FnxC5OCgr/3vddik8EVtFNqd8L ayvvW5jro41nespxzmlevrWzrJjTXhbN7Ytq5vTL4etCCgGS1SrlSFbrQlmSOGi1LSjfaNRvqbEO Jsu8C6v+qo1AA6q1aa95Z6UsWClBsu/V+6vylttnbvawfGYzbSyzteoqCGz7jQQizqk6tRxx79O/ c3XVfjmunolFtnbxGark35npTUiw3S2+Hr4/C6PVaihjttyJOyziHlu767+H5DhiJ7VxWwi5zb9B Ex3Bc9yXrc8oG+8317JNubfjd7gsxlK1osJqsbSUauDuNXsMtpMRec/y3mTNVOL/LNDFSYvrvjmy TM3V54V4MZh9iaKJXb6W6Il7l17CuqydpmQz7T71NGsXcqOXtqKkJ76YeogrlkYg3dZRvSD3fbx3 RybV2eK9Ech1b95gY3Pplf+2Cj28IRLTva/NSnC4yaa6a+5W1iyKxVkZWPbgdZlosa1SnfYUYbGN bqOFZLNNttiK8Bg+ICqZDJlITdo/8rDG7VZ6eTmc+H7fX76hO2LfRMnhuW5yHa+l8nrXtSIhGLXY 9M1WQGh9IymNBZfI0Wq64L9b3alUJeXFaa52XxELTr3++PzV55/ICjPG4hSUBM9rZ7YvMZ6FfEYC X6WSVnJ9cYO+b7nieSy+hvEs8ZGWC2Xa2z53XTgW9Otk8y2VB1No08nS9uipC8Vrp+y5drVWtWh4 fA3L4+NJSCJ9sg2r02f8y265/bOCq2tNX36nEfGrsBfKSOe1+IvL5fzAkoaMN8NNgm9v8GLjUnPV Dj7/9ATltaG9mmprOwnhN2ultfdleoYJO6P3Tc8sOLNP6ll9z/eD3+noe+5XA9lyC2/gu5mCl8Hw ybdid/qo0OulvddIVHZu9gWY/X6KadqUkksD8Tl+ww9DI4p4kslao7GcgiSSSYQGOhZRhVVzaoo5 Kq2OZaSEhi0En1m5F+2uK93e5evfuvecs+7Z91n33Nv3vLmzrzNEQ2f8JhNRp2esir9t0Bhnb0/2 uTF91sl4nmXAxIM95LCTPhDAaqYkRFkQdoFitsAwCxKdfv9MxP9wJQCUA3kEggoXzY8jr/ADR6Sr fUGG7OfwTYHRAhgN2dTjNL4+hJEEtL3hvTjXhDBjPZG5jUGj7eD6wsZY0CFat8y425FxlVYE4reS FtLzjCby0faS+x1220GBsC6BpEIpgb4kobBN6lLoYScz7EaZd1V98AW6DTek0RkVTHDImy7ns/KN X7RLIMR2RcLhqd/V0lJKfWRD+omkCdrP/Iqcf4rhuT+YQdH6S61qR3GfRMzMiOZaM4BJePqnZQ6y YVsU02td0YcRiDZrWGEq+1F5yHy6I9VSTuoTEqLt7x00hnJ6mauJswOLPdXHok76RL9fnIW37UfG CYVqxjRnniVLZnrtdVrGM33Y9vSg/S0W4Upso1o09R/s3OaHvb07vYwO2BXofCjReVrHu5V7M16F ZHtYH03SzmGi+fGtihYzoLL0tKH9NdTE7pTjR5wkLbC4H7HU0QBYkmh8tUPqjDi0xNTGHvWwUTxq qICUwLzw5ZtO7BfLfdBkOPvwwDPAd8FgYIF9yzQVN7Z2OuzPX7YNby00qVMRoqiMRi9uqZZo9f0A 3ybINpjskRDIINC3gJcdpMI4ejpovOc9Qlh66z/UmgBgPlZbaJcZQrDe6KU01Tn7p6I8ZPgrhDmx r03GtJtGW7EDaPSdfuvGmxQJdYRg0tTBS3zgWBcuYESionS4OhGL3Qm/A2/R3oDZPU1vIWUZ1Xk7 fS4lok+WClpDakO6/jjaA1siVLh4eIyKFcdBQWYW8u01GHTs7NElf6rsLp+H+DQtpftKZOOS3b2B fH9gBAK7PRAo3/uNOhNRMtVSwjSH25jUAxTA5c2X8z0+GFzHKRo9ZF4umOrXoLG6oUA2d5FgB9bq qZVcHCFB2KSulVaVIchfDHULN5bPbgeVnNXBwIjTJ29cOhSQ06ONhacPwSdjufBRQXb92Vs79CpB x+cy2yNRqqduQjbYD4ZghsKfBGmjFzWuw1Xt/LlA8hGDHKELiqF5wRWgwE+hsImEuSiqd0vfDOH2 TXL/Ig+/Xvj1LVnwtNOZZpA5lb7W7z8TEITFI1leMPfYoh9q1ZuinUFHHmVH8pgSDs7Y2mR0Proa 7hhNNyNVlHC04R3ZK80jZ2FTVt8gT+N2UIyfvI9gdf3TKc0xVvzE6VvV8S0TnBS750kZV95tT3tr TGt9R5amNJ43kpll4tlHd1xIA8Co6FhSD0istdhuKQ3xfjLsawrXat4dKibhIAPb1nXez1C6ZnJt 7SrKPGW5/6I0f1Td8MXdSxPDI9GR220EhlRbxWpy08aHVy9gRJjN/Px2g0GWOtvR58bGb+4+y3Xt EH333OaZlDeHY+tJfzHxkQXOgQshHX3yI+18tXCm/FRgSGlL/Z2iqcThM4SYkH+/nwypc7DTql/v rFszB75l00zyV1yuLPG5T38lF5VnHF2shzIQrjRIwELNpSRiwXNgb6Av13DAV8jtAhAzQDNMMkxx XeF61HZw7mcVFx88G9qZcjueuQMdxxlQ3ggf+vvdecgvs0zk3yCLgL9lyCSRS+p4Yrv+OhMUZ+N4 XB9BMlz3EuspWCG1W09vaIOZa/DyalxVMJEnUEEwGl4m174ccU50RCG0VSVcYt+w71okTUeZCIlD fUkG1Y9fg1y9ItS6ps9akzPj4igcv1bItDcSWY4NDrEW/LTIKm3QiwYdCnigUapYltVvN/X103aw nbnbiOrgz293ibfxxQ6ZTJC39UDFoNWAjW0+GhocSZfhDKeWl5jdWua9MNpZjcVXzor44WGN48Ke 2ZCAx5seqkJi2QEbLoNX26PBzWutI7tYPcI3WrDVi1042H/6sRG97JRbIm2WA3dNZdDBavv7ZXY3 Hv8cmejuS3FveV8djpexxaZCsbGJ2m2Bl1h1ndedAOcylrhPU8CKdYE/n5/+NNV/Pxeg1zkqG5Eb zM7Wpuzbj/BUv+k89HLR+mm00jSIQL0lNytQaJuSgcgXuGX5DgBJE3ZX3G5TEjZMbz2VOp8BfOts Ir/ZLqmZjMxfaj2jDh8HMBRmimVYm/HaAOFyWmsSV921YJFlnMdw3fOeT/y7knQXhDxogNczvLbt sZOPolxJS5eVpZ6GsBiCE+2AOm62hF/QqVNyu0qRpYtNY+x8O4ZwU6/GHyddIi7Lf1wdNJRzmxGW z2POiJyhtAfKuDrKUoM3aPilnAIFi9Y7b9b2U0kz4dVCZ5SdJkCR4hOXsIkJlMs8XB45hFQce39H I3tRythd89OAO5wQXfAq7Imd6f49ABH5Hnrr3hvCftRGvSncZbdI1pe7JKS7qq+Qh5YjgfrtSBiE vzzNW/8zPH5cng6EcZhZgW7FTciJUp7lJM0qtKqfDO9+C25YX1S/3ikZA0tTjRjYNy8UeliYg86t r6KEOaJ3/ndZsCcJ5y3tqyCbNQuULLFfQxiA9paHoZM4kBNSF7Mo7LWj73j+Ea1YObUTDBZwHiBF oj7oxTqu55RmOQ45ukcmS5M465kPvM3N3d2ibbh8qcCXDTSPLHunfgJ7OjM+MokTKrqOVvd6oxRE m36zE58T7ryVdr0z24nsV9Wc3Tf6quDE9YH6qJf36TnxfeImd0Z+uRTuGSAnJ6zQnHa0smXu+RZz bXZAyEty9DNBgJac8plDOyVgLHzp/JZtGfOBqNDAaOzw0Tv7uMNbRgYy0mGGPcwhnfQ5WI6vMWHN 4tzUjMRTivna83w/bc0ZWYlMaJJS4eQw8wKVaKgOs5cwMKwHVS9eGuIzJsh8pBGvS+ilUMIwJtF5 FEsy2Q2UmPY0PiXnqzyjhJoAvufA3JdBDAeHGGq/ShnfjQ1NEK3mg0NI/6c7MCBS1PXjnnFPiubF svLkjLPwUcYesUpqbJZsczdYF6NiDiXJbMjD4/YbMOCi3v3/qaj63zdhaeIza/4pZtfGx2dg1cRn Yeb4M2Ng+otOT/9v9F8r/1ngzsD4/1SazcTM8J+l2MYJkzaB9Agiz17BqaeEQFNE0UFxQBLEqN5l TXj8FwQilCOMRv3byzkS88wCQE4XntdRLE+TFprlNgZfnRjCsMiWXCSwUYPjEHrg7C4T0IakXAzZ kL0Ftk3Hmo48scgPyRbgdJNp3/pso+NTVvXxg4A53N/T4vTZnA3DquqaNT81vvnhLQz8U4+lBS0D dTA/1x76vJpoqMyfO811NGZz9xyX+tgdxKfDBAbKsABL5MVuGvp4OSafnsZ55O5svtO1QlW82MB+ xyuDA8I7FPHIh/8IEeYiVBAtOoBUmApXEWZQSCIkQZwLMQv+zKISS+WtsdakE016kRJ6+P8Ydwfg ytot/DO2jU7Htm3bPLFtszu2bdtGJ+nYOrE6tu1k+rv3zn++qqmpmqpT+2jXqrWf57ee97xV+wx3 yaIxYLWnK50EO2u+Z8tKz32AJtGPcRzrddFkly1Y7iCNbo7Z68AT6tCW+6Imdb5rMv1i1ComA2yF dkq3w7sQNHHhmlBGt8FJnoWuUbfr8/FbHjlfMUYk99H9f/nM+v/LIXZmTg6m/3PzPDM3C+f/6+75 HFhfDPG14bzKyw7WjIyNETLWsXhhNCkiUDSixDFIS7FYCDk2KbCIDTCoX3HtkYZ8jnrYmMjXWuJ6 ZolE+LN6Wjcag+oLmJgoWnF6qBszAOkABw8K2NV08B7GrDydLwV+Pb0H94d1dnb2D3Nz798gYgmj 5fRUAna/+LzG3LYd6CGMHb4ZKHFdvjrY8yDqPtH8zsMV9FJpoHf9FHDcoxfy233etfLyuaMp/eGw Kvboka2vy2KvfMvHfxEA1YIXICF9E2zWsEf7s3gG5Iw7KXIeeDFQ6x23xqLiN7T/zioTq8fBkbfW G9MqqcCYrsXzsvRiAIqLDjJi14StzgD7epZf9ltDV/Ztg+et3+zyLfvqHd6WfvFMdhrAYjFXlZZc AwnAFF8/mqmo1g6kSi/nbwzzm+6XneYNAHpo/qjpxcfxsbRfLIwycNvgg6byJJxsM7J3M1vMzYCe gViJOb05UhGWCnXjshOUXQc/ZNBxv3n0CcKebTgCy7XBVjNw7LnvzkZ4/FCqrAO0e7qbOYae4az0 6BAN95bf7pITRwVCAT/zlLrf3sfFF1tmTOko3spA70LJo2xSqce0RD/VKx5kGcr1E+8fB+0MOevA 6AJ+vmod2x6UmsnW5llNfI7jVLmjO371/Rw7fe3oMs95+Bg2cTlngporlW7SLGgxsr3LGG3be4vZ MrCWBMiDeP3UMeaH145vBkPiBTLlWH9KjagnFKufYx0bLtQsmimBN9DbnDhwxYXhuG0UpnVE/iIc G3fXza7zEkqWm/QYgPYwTrmcOqSmG2BKZX/+jSFesNTdWbbAGlKN3D4o2UIuGAB9VIgdf1H080Hj wtaaqYbz7SHYnocf6/QVcmM9qeZTeWNOHP9gxAHfXsTVIVb+yJGn5MzUkKVmRJmm8A6+xO17Sco5 ZDXw/Id6cm9obK8KfZlafu0izyeVhpIf0gXnj/HaAl+EnKieC5zf1N03B0fhuiERXw8mS1SClTan T8Yye4t8/BzwX+v+zSJxb3cfbrY/hYhQYCB6fVegzGwC3mYBrg2ChAaQYD/zBY2UWvGoV4kP5f97 Cth/nwLzOJeaEKIbRtYEiMHA6V8VzHkgWszToOF+YNot/kH1nvl9ujupnM5sbXX4A3W2LNhU4IuI 6W3/1+m5UNh4PdPF82Z+9oYTZK+v1gwFpRHNMWim2es65P9qC0gGDqq5Jg5y6X2JnQg02Y60SUBK 4KSYpxuqxPYhsFZAYgGJIBJ0jMgRlxZCDVV4bYuRgISoYNBWVCJSAygyeAqv4CQoEngRjkAq4BVq jNT4CFHmbUM4sZs1XpgW0JMr5WobuBDDBYRol0LfoXiI948ClSKSFyGpSLvHRwgOu8dAICKAYLRq LKXGKfeN6eMKcQ0vrZCikBeFO1FCICaQeMUEJshk/mQD7uBU+kagZsYOMgHlTOPNjdpvBXFKTiyj iQiKrDgkEnMj5YANoyRTfVQHW9dGbFYMw/GHxFlseffwGNtqQJFocoKwbwdUwwOSPKAdxWXEcfeu 8lHxit5QcFKUxtnOEBbWPLB70pQmYCcY2aW+sRWZWHuuQDQM6jBmRHTpMhtvrGky+iGyA9ZkI5aT 1eIwJ6RSpZ5vQ8WsSiLetaWszPIv2DRMOc1oFgnTJB+U4tNmxepcWc14R/G5Yc4HqpNzrgzm8dMD HeOU6XFw44yzrsQ00thGWCl5cavFUex6gTQHJnTi7CeQ6aI6RScsk+oChfH+309C0hW9UU8EHZmx 4vUDxYvTdn2BE2zd36Kk636jAWkb1LiDq9hqxBFPFrUkXvHpNJF28XSlvGtKaR0TnEGWd4yBKe3B rpgM5N3f06gJC5HSkv78oC3flwAiO6HXknXjaibUDi8Wt8Vfjjjc4AMBTognV441jchtVq8+1UR6 QSnFbSaYi3+EO5E9dr2BLeWqj7sMG0LenPZk3ZLzPk6sJzzVFHpxAKkr0g+Qp722YuRtDSD0DS9Q cJvjwI8veIv2aseomnjzx7o04dy98obwK84l2QfpJYmf7jylI+eJxIbo6Uh38UOxz+wPt+IYLcVO 2Cfaq11pvvx3giz2D/TvZHb9hFJt28TAmkyBEMRixT3UA4J33LjET/F5O89oV95PqVdNPoVXhFyi zZ8x4+ueWP7AI6W6XyFH7H6giMWMhcqrMWn1EfdmfNKvcBxJPZGCCZdi6Cc2KyKdsvPLDSn3Dp6Z 94jv2l7oDok9Pzef4U8AKxKvHK20AQO8mZ8EM/E9UQTFPtd0Jz6ZPXFHUoK/74p9bgJveR6tOgkZ qbuuifUp+H9oSiFbe8PUJX6C80oL9tsUE+65HbD7Fp6UPeOfCN6ENqJ/9WcV51l543RJC46sj1dx BXpIxVm/Qn4qvDr8kn0VXBF9LSk12PE7wPSNQZbq7dMHOkgbDHusSL7yPyZ9/kCWDli4x0GiYSzA DZPCfA9SmzzxEywLuGHNm/9aPOP+mGc4vFfknTrJc2UuC9iwUvgqx3Z5LWjl/ghEcnnt+/tl0Fq2 f/18tr9Q1jzyN84ywtnDe/C/H223c38MKLi8+tspbNVNnbwFhLq8dn2wlV1huXSmzwe4u7zOfPB8 HPGWebjlMBz+Lf51n/25y2ioAD3VXp8KIImOJ2Mg/MrLzPOc1/Zj5PvBrATijWspXkdy9vCNx76Y zrS7eDnLx/Ot08bbcxmQ2tflkB9m3VeXho6DF5orD9EdrE3y/+RPDwXVuFhDygJz66mvvJVth2Z+ JLUSiNZaJSJUdx/RHOF94pAhk1ApfQ4sv991G21ndzl7+d/T/cD51eD9u7OFbM3OeRn93a7zyz/d hf8bmvl1DcPp1GoJayZEGanTBTEV/K2NEHCWW63WQZFYAFwdE1rtqBqFW8Evkla0e0xKJjYx24cv 6Lbh+zb4/yWuXwz9H5GCyFoT28WXTODGJ0UKuZLQW6s6vrppkXJMTXVySGwrQmpSD8+FO6e1HqUx bZ+0M5jowEZTRH6aI8A3oOt/6T27vLIpbG27+AlJyd7K4sbS1LxltoBHxSXQypIRTZFky6KiJdGQ MraABcjZf9PIIThWkm5I2cgJCa+B0CMxrvL/ub75cRH437VA2GBPqlml3FnXtqSoJK0hpahmrbiw 6FompoYKvluZ44PwT9spcauKQ+qcHzjlCz9jH2Ped4npGy1vDtR7tEupcwfs/60nr5lKDkxDGq+P T2kLK5V37CWYfTXagPwfj3ZVHIBJrKg/xqlGiRfJIX+qWbOq+SGk9eYv8KGwyg2OT3t+Jv0SLNhO m4Ed1BDmz4LxhkV+ePx/RJP3bNTrDvL2sS0pK7ljN3N8gwYh+Am21lbDM2rcAHFCj0Uw2biJJjaH LK6DtS49orGpvwBV0aCO7CAXsSIzC0mJAtD2+adZar6OXr3/LX/HNoWhoUrlxrZxPxcMGv9BxOEL xNAyHyTctqoVChoSgNjXxwNxMhBY08cEhRtIH5v0ORPQht2iUc45cdwDigqA7dyGEGCwPlsVm5Ut Li/4l5zovCxy3RMGb2HX0c2uPaUIwlo2HCxKIFzrlXathllThk0nqNVx9au2TJD4dkuz/6u70FlR ti09qBHIwPWzYOf4P1VXEv5dlZMn0JhWdWRl/M8YXfMH+I+En2D5H6Xj7l1T9pxrF1AQ+IUX7ryT HEWbeLGPDlY5OP+4bsXx5Brim5gnjvF+y/1zhabZAl2YMWFP4ulfRK5jQyaNAf2f4B40A0V5MkLa AkCYOP5DJe8397CBcxjm3/bhiE5chg1ZIrYJlB8VldNIruVkHj7tHV3/8OQIJgiPsvQPoaP2Bv8i lGxfvKpB/e2p0J+nNVJIzYaDQwmkeUttFVUkiruYvbXweGQODbCqOE37V8vXSPTwmv7/mMRNXPcv kxIVPPptW5sDGMflZI9sxo+FpMTbwSCF3uRTBvpFBwYmd3aggvF0d3Z2YOCYw3iNfWASO0vXORHK H/Jz/blk/ytnnm7U6T96ukqX/eu65Z0jskRSth9nLiHn0FbHJlc/D2gU/wNrbDRCXHSzhISKlvl3 FFzciO36/NHR9n98soDmUYOCfsLgizCgQHPtgw3ebPiH1giGjuJ/9awywV+vE3RhB6mhY8yT0RE/ mykPhzHbY7fIzJzAzNzHzGwultnNzMxcL65jQoLu/bdlis4uGevNpY86+Ki/wJLzR2fvRZz9kz7H qhNv/0q07vGobUOfN4unQCsndxbZ3z+WzvOFQC/WNS5cJXhz+hQsUAqDFJx4chzFoHmL+P/vEVvo BE+9pFN4/QwONBD4Owwdb5MRBoSv95X/CjbcDkcUWw7Jt81Su+ZBDxb8Hz9rVon/O2MCAhwCf7AI LcSr3aR0fflEjO2cGsBv0K9+PET+AwIC7MlJDPVNVV0gwzExjWDu4D9JPMjkbPQvFKL1OXDcfSz/ snDe3M6bgWj75ayu8x+t3bv2Nuy71u3Ef7mlr19IWGZvEnDCCN4gadUd//Mjc3Y21z9Z6782xkVR PORg9/IgFKU9/MvGT7cTjEqx5i1U+uTU6eVkUaZm9ixcKpA1h8rs5OT0ZIzMZFPRQjs1FRU0EjTR JDTg7Cd9DXrRepSONX9h2fYJ2ZUi1fOBCxghtvzJP4rj3NWd/SvRCtm1YZDjbL8CVbnox3ImgeuC IJ7W/+lcQeGRgjKMkpJ3222fjJKSdA0/N5ttt/jrTrD8r5n8eLGX+Ci9cmTHYD5X8mGPKci9InLi Nv9ankqfCxrCo6Pte0l1yOgrciZZEjYz6RH+w0lFxVhFhXJFBbEULG5eZiachbPpaT7zb2rKI/V/ COTJ4e9mdkt8ovw71Cf/SI7qdzRUh+RyI/qvuFD9oxaenp7+F++h2cS5sfOFR2QQLEi4Hy5rlaws KqwsxmEWwcT0tsYSElC6Fcy4os4AB1+nflf3fNGSicV/QDTww3SVtpyhqIn+jy4QKZz/Vn0xStyR J8fOQyssKbVawfwlfTaTHgkDpGm9sqkR2NS4y9JEEv9dOTElJSTY1WKp/uZ3fdIdTdM/woCibnIS +T+o/83laydlgzzum7MBnQfj/0PLtYEQHBllemt3VivVyKNQ6GvvoWk7tYUECRQppmhCGJhcMcoZ 3eQAmm6wbEMu4vzbRsGlpYeucUqhUHfaVsCahjEow7HhmZpdSpAeQ1MKdMD9Va/HF/+bwxYv2zaA 0ci7+eI3F/RzAN4s9URnqzz+N8EbfwmVt5ijMOtK/6Pqj8NwyJC9YUWui/tCVsfD4jHVUiyTtfsm mYlpKPPs8KoRJwD2QWLpg+VG8BQ/282S00veRdHRRJ5G4tkEro/1Y/pcUSOLJMKMFCEHG73b6Hby vnAZwj0F4jUZRbvejdP0f/73F35dP4sStolli9iYLi8RpE8pm23kWGChG7J+VXM9oT8TDCu6YKdI jqn2XVNpx0N1rj2Ww98jxPzw0vKEdOLucwC4bHxi02Tq7sHRGIbgju298ZkD+d0DnddHhvrAgeY6 ueMjrOVdjD4gKrVNRYD4p7sjtsQUveObdkjXrOBlf4dbCCbkgm73UPbVWB0HMm60d1NII9b4Cym/ 7Kn2vlapmafpzrE3UlFK9u2IJxzcx1wu2CJ4b7KalvZBHl9Jcz0RB3GB7aih4ETeRcZBGOWMg+yc XHwdwXDdzBN+80D7UYVFEP7GQ1Db8uaK6Uh1ZHI+jaK6mVeFQSWdatyOVMEe1jMpIz/GYo90TNh+ Wi1fD4dGJW105pEG59mpRufHWVnyd4OsfGtt3Bbht9tiJ0y3veNZThVKLMyuE0tfce2KvJp80c5F VuWZyoP3Sv4Qa+kh37at/bG7yZosA2FkebkcQlVGacvwiBs75UfS0lk9TZVT6eujQe9xGvjsB6Py LG9pk+YZgs0G89Ft766iEpOzILufcvEPz3JugJzU+clF3bmF1lyzSsnceUuh582mzX3pirBpatmU U7qFqWkS1sLoOf1PGm+xwxf5F0y3xznrjs5egzTTp/azHrAYkJmdGZ5UNSiZe+nHunzzRScgx0J5 D/uVovQNJWWV6GC8Yhz1C5fG+ndm0+sQ+Y09bWOP+chO5KQKB9oJiTLlJ0qycuRrRHmByULEgItk YKodp/kQx++0VJXDI0zrqcelzGsra3k7G/n1S8zveGNZzZQ+7VvHdm9Nq6Qi8Eexj03h9pVVgNOo SH5x1WkGN+wldYjX1vLiAQ1ZPw2AHtER8hRjirEX0YgJeU0qlJlXVkOnMt5+WtKxYh3iaSVFUIJE iUb/xt77YyQsvY65gtTxgYL8uLIbo91iD+C3/Ndxcuy6CY+thyNjuQJJmBkjIw13V+30RkFsqM4E qCJ8teVgUTFbX87VCJu3OcWcQVIjv6y8WYM/oZt2j7XQXl0JVf1qHxNHPCPpwhy36TVX5vHp6bDX xt4pzSlNVvKa9ve2TdW2EMGBvAqAitYcj2Nmcg3n4OvIppaEH3taTCklpKR+d1hNpsqVSVXkDMOm cZlmgjp5CWL2zXvkr8ZXUDXNziH5pC6N8UWVFqVNxyp8KmPXRMSN8tUR+xvQFp2aakzL9aYsnGYW ExvcgXOKPyrmDvR7ahRtyS/NLJhusWOM1Pz+95aKY43Ev7GSpcrYvIt06wTpEfv9ZXTxFuLRjtZI EJN38YbbfeUTy5jJ+DZTecWc55nn2dySGEqbE4Ac0n4pOdRDqh059zQyLckcKmsSJ24yrvIilUud 1PSlzbFA/xaJyKRsRPs0fo98DPk3iXnulWKpbwXFSonbJPJFbBFAOZkq6pqi4uXzhcSh5NrC5hig cs0wpTjHRqZwjyTHRn4N3hGj3DIHLYBjwsIyK8YipaWaUsFKGzt7yZijc8h25Tp1d+FX6sPvPvqz +OJ7HTe71lKHmZh4kmMy0tEb8uJoQXh8E0ejbgwkQXKGE3ByAepipx+cfpsc0lBJ7YNKkGmNesaI GpLetRm07zAi27t5dwP07O+OJvWkfnqXJ+8g/1yS9C605Ut8QHjVs3/LjLQLVU3R3y4ZZCSpTl78 dR7nGtOuQmICfrDJcCebq+hIWuGXkCYjvIOr8AYY5OSxqd9xJ3MF5C1MbxXNe8ctDD8p2SNvidZ2 r8Zz0/hFpUpLw5vqSv+UM7UlQkdL+DO4ZflsjxJDxcgPZCvMTURjxsJVMRYFMmkmYSzG888sDiJz dKrqnrmE3W5eq6ow6nrMJ3gMyFuxlMDJyFKdUD9xHPyRoC8BUNWU7ZeJFUUvKIxNGZTe05S0MScn xgFNZSQ+vcEJSiOurK8PO5xJn23eIcVU4q72Ga3PNF/u1l4xP7Nb/SOWbpr9MwS3UK5EakNOhd9W rOzK3PAWz54N8KGD25N1obck/I7+mpcsaoVWkpGsoQq8s+NrKBjHFInhC0mLIZqA8q2sIez/kHg+ 7PL944v3w179V5Fiybcxnicexiev5Q3prEpPh54U50rPuu6Ev0fG7sy/R2x9KW71X+p31GWRT+cZ yapDvBXBzmTy738EEXGOx7Obf3S42L2TnJZElacxFOp3wrD0Suld51S/umuKOrM8rOgYjOebal5o aLyxVeWMW19ZtCxWP8po+LBXTZm3HDWuYWicmbbcVC+NWOcZay9gtky2VQwcUhlgVPllLApMW9to 1aQtUjSsgVYvTbH4yfMV7DQj2KmX1+C5LFIS1CgSyDbFxVAqxVHMpivmcxvhnzDIRLYekJJ6GEc5 uf7qVLCVm7ZaVSDI6eHyANsS5r3MDzOCflROPAFdEx6whGZvDMKrTzhUypS24v0LB4aMd6MC2Yim jTXpf1SkKKmiIigoXt7gFokwcfo9FJNpYgVaRlkB8IWmj2gmu4YwyN60UmxQjNfgzaDPlY/U3PUq 9c4TIRo0cmVjPjt0qN7yNwmhXh50OKxClUQepP/5cBp6tasrfx4LdaVau+Hozrtrhudmi/GLLmJJ u3yuVfK3ldrywM5+3BxPdx93jnsTuyd0V2ujoVvdVO1VdphuHk8Wl5mgk8CB98gmWRPUMkDtdsV8 2f7ooTYNmBmtdtvcFjFnXQVg3dyddOb/bDT3ZlevtnPUq6jl6Kp1jPWgd7TGXKTHPFqaTZ05zDzl X2f/uUbrOO38Yl0+NVX77aij9hyrCvVUIEtPdCwkOdWWhZt3tIJgAb2OnYu+KWLqAZGjmjkZjwJX Ag+IGIQIC5VGPI1iA8MainMxbGgSP2fLhvcgsToawxTKTv3mR209iF/aVkXbXV1ZfXChq87OpUHJ b77PRfCpVBGOjXnUQPL1uEqVefAYoHduZWzeqTPndZsuWAwjTu71WZ1cSBHEspiXobLPKSdQ1pzb kDVRvjCjOVflKm2FrrpQiNlgrVsPGc2tsYFRVauo7aSqjVtIwjAZMQ6Le4bDXrtNWUyST30h5jY6 8rKMgZn2ShhDe1dWhUteWz36xcvuuNL/ORWLhWVrZFBe1QikB2o9XvVXWHewteZXV5dHyC+fb5sb xBPEpDOy8ZJ2M1W5O+LvAc6XWlfI5z5NOYX0EnLGgsmmGMZMgeempWuLywhUdOWETEJNEa5FEk0V Ea6EDnfOaKtk5FYcqC2e2k1e3IUaLTdxi3LZCiwRHtYUdFAKU4NjxmxJJxcUVqBJZ+tytcuxZA3u +BZRMW4BVTFugqvF96mnv5IxlrhKbd078FzVPeGqqNWfHdod7ZN73VPX9QS76FBivGjNp3Krammr PsxyT8G+bBV/dvnLvSiqpVUtmvBBPlAx0lHXMD6pY7NF38RQ36thJbPH5vHxNQ001DrwLl2PCc6t mLY07Jw2DFt8irmV6vDr82uUelfLPWjt+e21mAjj7yXJnsWM0hbZ+NptjtKb49VhNsCaeaE+kpu0 9PFSEJ+Or9S4tjSCYsF5BVL5tqqoVIXuI42pVx1zl2hAViW45dOcjjPDNgBWQ4VSciIJcvmK6QD6 Td+UQ+7gdD6tYWh0WnUvrrHkK07gKmmLiTryzXGV9hUZGG6PZhdtu/uESjBPqV8k21K16UJc7bZU 0mVCihZFpK1Z1SYaF1mSqA1XXm4MvmsdVc0E6nyqkd4NNZmVUye934iTZ5cGJgrBNKXUliykhWWy 8PThpfZb66zDtOckBqbalR9tZKbSI++D+TXQ1duvJrlXWF0kcixMy1idNZgtELkCUOWpJZ6YCs3q XjPcDkxk8srPDr3GKa27Ow+/iiNqqeN/IHpmTw3srYRarCiv2ZBCgmXl64Nhbtvrxq7XJ+ovTZcm njGnYBGkbA0XpshLDfjd97sTuideaLejAVD7CpMVnTA1pByA+rSG4iTOzLhRTui8otqxzudJdcIU 079ftPqtU1QOzA80DoTfQQHF2Ckm9URQTVarFb61b123AqGz33tHclZG7Nn5YQkJSlLprvogtWin 4jNYJF9y+aR+i+8HRUesjLXeYVh34xE2Ubl3JCvW8OU/p1iMjUfgpke1rIxL1N/wCWvWyqm5kwTG OjG3eFPi1WekUrzj+mjFX5bf5jtjzOFEzx/7cuywt+pZC7i7uSA9pMd6W6FIKE8Zv0MybrsdGgUc RLkJd7rmKHpUNOIb4YRa7V8MNB9JnuP7k9NrSs9M7CXzQaj2vmtc2PGFIWsjyJokrbgKhDMePslg /5aS/CYhi3moHLAlXHNVYtScAX2jBwS/NblFfm0//JBh4ifR3wjxudY0L2F1a8J7xH/k4B29e5Hz xxYk2qQQJOk1Ki9uEsCOckT/PsBJF2zWQH3+jSNNb1qjcauRd1Xhkect+OgWrecHYcKhjGyJ4IRX M8YE+y1755kr57GgFYOdf+uLw9QW1cm4W7rI3o717edTe9q0Lbz7jp7O4w7IPDM8fOnQFNoKmzsu vWZj1sqHLbhPsF1h0a9ppHrFE/IT2kfwMk2d2qMG15sifTCvZ0jXEC/83qyrwgO3T9wvhchktBIM q+Bk+hTpqLGqFCB9Mx+1H9XIaJdpyCu3XptEm0Kb8FP6Je6msl/8Duc93tdpHPI3WYHWNtypqsxl Nk42BxUBMS7+0PtTYVBNDi8D6Qlf71/Ls+Hr4ZzaKA96CLLmJqu4C6ysq76tyXpy/F70gInP/JdP CJ9M7xMC92DfVueyQxcawr67ZzKd6YNFX2q96M1xzpu2l6dE4UYpDmpdmdRhWdZia6sM14hmiVvZ OhlCKejiuhJCK2XTpvNEdLO6bJK4NIvxiQOfg7iDOLeDTk3Xr9msh6j75ZOse4NZ9SmtAdMBjAGE AesB8wF7E8iYaQJPtACez4BB217XFjUq/ogsr9Bv8sSTNmy5FoUymaNWxbeItpi9gXa74K7YZyPX zOdy31K6F5Zn7tzebQQkMkcjtZgP735b9N4b3RY1j6d6bNe/s+Ws2yzcDr0SuZMLFiKLgOuRxhSa CFAipqgWa9ZLro0g3Pp5KnI0SbmnC9LJlypfW3hV12LAAjc9RXTGa38n/UJh+jL8lTB8k3GunIkt o8XzpqFyzPIshyeeARTWDYJ8v+KSm9lTb89RH3NxZGVZOXjGQZ5rMo6/9PVrFMjuHjwac+NLtgNL Iyxowh+CYpLGDrVZRbCq+YQJwJ5okOUwqbuXvPXHDhDJpCJclDdzOcF1hKwdUDmw1i2kTdkydCFq OJFKfJo//zt7DJSzrzSZ6uNWCutyM5c1bMj7MugVZJES07hsDKVzCA2pqbyWufFWEFNFR8/abFHd ofKvaH+CuTsNJZqQiHqBfJgWtMg7CmZI05r2QyiZyBo0aapR+NfI1cNQrYUvLHQFSrd63vZ5Bfgj HifD1KKeBAFp2HfsBIQGpxdkWCEBwFsIu+hF/hCeFwIMUskOZa8oiSdqtoE/Edqufd7h07cuPP0Q VrwsmTP7D+NcVrA5VwJyyt81dCejO8ZF5Prnn4OEw2RE4fiH/R+hcq7Myg9VU8xU3O74TsMWF+AF TmsO2L50FTUH1oLLVLf8mUFgYyEk0WD1uPck25o/JPOQBH/TO2huAW6T2qpO1CWg0WvLl6u+LK23 Z9lvYgSimAEOHDGpTQ9FuLK8rucozrF+yeiAqwXrbrWJAk6AfoJckZu2M0fjqML44cYUjs+Qbatu juMWgeuBT+nHBO4q+kXYRVh5hOjjTEIS65z/OWnnrd3CXAhsk8V608R4KCJiyjdcJGm8BNRPp8Oe HeRzY3hydFpb/9MRh0yH9Q7VhwfdigSD4hfrvlv6e7QXOxNjoKNe0m0N4xyvZbu4Q6lC4Yp02TxA gBM3JnHQiMk8y65UB51zLiWQccMa335tgow7izVvkTlbHJrej0vGjZncZ7fB9q0hGXd1pDEhqYbH jS4rmFtEIkZlvr6AjpxczU1xfPY+9T5HVACn1aV8YZQk7rvdZ7P4ouP+3GH3OZ63G+veJOXUPQpf qYNxkp9+jUt6htnAJPnaD4EJJm80/jvseS59RYuWP4XuOG7LaWHnYScro8op3pcrRosxRqKsx+1G 3gO/E0hZOa+yfTVeyxOA0zmyDtcK0bV8YbFdKUg9ibG0xGPYQ4sDpm1sPai33pUGjDYXAfwmw0bW nSUdNbyAV/fM24bzWbswAidbHX7NkZ8z39AZz/p3a5akTn8pcqza+mZm3ogDapJdiKTohcWUUKzi dULZOmtXpRuT1jTjUNZZCnla78lbijUBr5ZJi5VmAk/iADrvFukuHTAfpfhKa21A0oWdPbCr6GKa 4sAS3APwWXguCVGCIsMBh20x9prim2KWclFimDNmGLEbUmARnPc9hxCApvNd/zs/u/tPo59m7sf9 15BzmA1p11H32DoMLTULW0ZaJgHU1sgBgK/WA36AXFYXO4VBoMWzEnrQmILJMVZaEdSpEFypCudC wMoftK9+RJ2y0m8U2pnOXNsUWQ3JDPqNajgljY1KPqOj0ffh4fGOvMs+aNDeoheouCekBO51lHP5 ea3bUw/YHHQTWV+Hfl2MLxepkgy97wmStb/e73Hf5SmaVL+4mhq0V+c3Nn7t3fB+Dl5a9XyMKneS pH+9/DpbOHrGy+wTKDkKAXeSMi8AENEavA5XdVNO7PHN8x95WcstZ97fGaeepaZb0y0f1zYcQ0uk F5f/HLtBdaJQtZTydb7NF3YcHnIZ1ru5if0yO5f9XUQz07r1dP7G8ZY4SZaRQYcOQ4YuwpRZ1Agz 2jOaOFf+o5EKAsVJuICmPepRtaE1cHFXhR4UDGphprmkleF9VuOCskYmoKiFJk/XP5kmfT8g72nS sPmj7kw23SXX5bB6xlnw6e6XA0M8xjRMphlzE4QxRRsoAj2XobEwiAs8mm5O+KBCIKEtxaScRTNX dgG1Y7bE+TnUNhW9DkAlc7D5AmEL/SOnuEcM8pRjE7yssxzbKxCk30mzoCd+JncR6vWBii34yLST +WQlAqyGAo/SZ2ePbTkBx96qtonYtAE9sHwqSZZtxUzsDoW3ni0dTldji81YzIQhqYJoVGvLFWlv DJk5o2xLq+U4cv2yy/KD8eryi1jAZ2AUFn3kc7vhU3CvimE6W9BhYRL66jIgd0vQY6s/qo1Traf5 MzLnYmD1xN1xrvhmokrRAb0lQXZEodeea3DBBCLkCLUrfZCBsMNtDELA4NbVFlBCkSiSURyNzhBD UYmnXcCMVepTDiaM68ymbPxRh/k8UwjWS0NTf/8GRzf64oDJ6bvystxBupJOBYvG6IRGKdY/x0Ra DtdQ2g/3M1/wGL5RJBoxxWiEKKoeg3FAeIiBtAUVdBjvtgn0SHimwDD8uT2PWEchbTHuekFX2vUN 5/P16M4+s8t7cf/sStAT8KWw4fs1ExqXcX/dODbz1Dt2hZys66n9VQCu+PAk6GL1cUcaGvfy9hj3 pQ1ehAaAmWCO+E5fuixa6ieFx3VSeT2cWLA+SRdqKIUNw/dDGlMqE9zgrnR4HIY1sRpPKhFXHFMo pBLSWjVi7bFfuTIEJAZu/KOyfMOhswfc+odQDT//0s4AP4dTjW1qaTAdTaCuiBywPF82lYG7c/9E 5fT7M7AGJGLuGBUMJ5K5PMKKjNqVuh/9xwFZvRFYMUJcS/HuvlznNjuWkah4YjAupP63WglI7wTs jNVR4s7Mi9PwPzCw4nH5aeI4fw7ECGAJjb+WUrGuzG7/rCNUephcToUzkwuiJ7Wzr0lceIilrHna /RrTcLHqXkofmD5aOraJke8sZvm1UB3HVMqEvjpXSCsPnGFNpp8kPRfdFQXOn6sWbjOVGiHs4QrO sKJJYw14RoQncmxmx+pNMiWS0VZWnoUa/cxZy3lA2ju3yJXg+d4TpSiz6dleZdmY6NqSpV59Sclo ZZjiO+Bqspgij4Z/CAcP2Jw8x0705e3NtYCV9/Ju81vacOQA42bfQqOoDaDDa4hF5fY2L+KM66+p oWc7wA4oWmowyXouWJU/Q7LFwwtdvDayNC7jMTG2OGn2ctGXWPtttRt0RWS+TQDiwdegSrqlnnD1 SOy3XZUTCuZjdSdM6GnjoN2kDFiq9kBvqFgtdyjczSU2vYo3Vzxw0XTfV5b8fnQ0TS4cHFSAKt8+ WVsvnWHtQJzt9VlvWJygxvse9dHkcT+z85T3efsJXyow7u9iTfc0fCJxeWz1O4wjcUhw7ys8lBm0 7db50dkesytzD5gSY+vy7uv+y9NoLH3weGFlHPdct6Fmv7CS11cC0kn29KWiMJ4BLqNQSRuDhmrX E9pHpJPKNBKM+7mYF6uYhj/JWMXWzDs4owon57sqJyN3l7GGd0anmIE13S0jgkGZfp2BQ21TrXSN jIPpldrV7BXbVYO97Gaiv1DAqC+Vkk54NbEZLmVqxHiGdbZwOc+p48MAqyXxTy2/UbcGXmM5OoKF sGSNUqdM5FuQbLbEZyCxs5VVfAkutyyLSK4vXBUfVFsd7+HH8AbxSXJBlS9u31E6Gdy3CRiuHBrK N4geNg6yUzCFDeyhORNhNghwyPxn44RdLxr7Edprc7pt+42T19Df9DtL+xGUo7hqMVVd0AIXLAjm Gux8mUhH6pJnY7w70fP819wf49TGHeDKDv3M03JMVqbPB3fUolOKpyGmFgRFL4yKt3mS7NU9vq3Y WJTbMecoZlXxbzBlEsHx2S/E0YPLauMo0zvEzpUsSVaTMfnFZGSJ55oMEO8FRNiFGYlKyWqlF5Af iVs1gM/z6Ao7iwfGrNbnyKye9zjKnj+jV5x5AaV3N4cJz5vcZ3Vbnq+UvRdfeZLXedVVVx3Hv9SL RnSVUTvZ1u8H+w96deufpxCH9Z7s0wVLCoysFrV9lnRdLBetxxNIYSJsYErDbvI25djHVxYVKDai JVampsOvPdmmv19Fw88IY6+6ZEf1L2FZRY1hZBf09c9JccTvuaxZ+jdzMDMl5VVMIdNtY1vKgle9 LK4hgiYhg0jwoCXKSZC8pIJwvoB+7FMXxHWU0EnGS6GQR2hKkSS4DbCx9844gfUpcX07/m65OlXk iLaUaTKwloMdv0+2W/Bb2D9aOT2tGCi0QggTTCCfKguOhEqQVb9bbPZGP+FuKg8H7TnfyjYYL7m7 Wm+WyVIhJ0XwO5hghEKMFg9OvMbFjA+RPEEiFfTWCTWu7EJehBgzwnWvy13gwkuIjaUiDkTTgA2I nctnvnMcB58ic4a7TeIQDg8J/8HG6ZDJhjPc00Wi0DBWj/SNKCoVXNzqOnA7U9pxiqK9dUK5f1CS v142KYcd4xxFrp9KqEj48XxJ9w9kpyxwbNwX1/5amcrmmtv0wIbIMbUCQyya8Kx3p42wuJAU89vr PbIqza6owKfb1yLjY68ydej7R93NW6+V33PfjMr5m9/c58zXUS3DIzbE0a0HJXYs7wcE7BsseJ6j 0+U3FWlOZtENHe00GxLv5lKdugpiK6pZDHx11h6KuiOb1OMom7WwzQqH6k/l67ljVu98OBrc0ciU 5kRQK5/91cruBOwqJDEk9Q/ia/0UNp5wWWIVOxDUkQIlEdASVKhi85/JMOT9q2uZuqzLury5Xfnu rWycXVI62XpFdkD9+Z6l3uk1eW5wFw09GuxKxrswxgp9/Sm1kbNojT0Bkypmw2tADMEwNpTNLM04 SDhIMDvVRROdUWqBcCsHBFUqAul0aGeGxVMo4f3IHklgUCFbVVyF2uletY5fhRs1GpWedFoJiBpc /GdHVf8fDOhwkVafsQnVHYhFMNTP3UrHLoxuZTgtZF2uxalJjxgZbLNqORZWuibSAU70hSIt8fzP nG41HKQ33e7kZKkp/qnJVvONb4EWvNi1ODJhE2cqdTBhEBTEzXDRhrMsgRqRIumpqHh80ULakf+8 T/Xvv04Q78mc8kDJn9CBGAV5mI7/tJU1eCyKAwHxaaoZefWOaFvGjLu6NuzJEOH7QSTei9QoQmAF wgHnI3/fxqwJ+5tSI3dA6RsCFNinYTnJAFxhH0oDKI4t6Xqj4VYiAWMMwE14D0iquR3K3Lblqydt 8Xw64LHxea4mi5TSi4Gs527oBfhQj6p7tyrdT9U2CfBf30dM+gj9Ll+SUhWWzd9GuuG0LPYEhBVd /i7ot75KeuOj7lRlrbIJeXFXlu1Hf3McM1iE/ttJ+qP7jx/GXWbGLv4LM99W5rEcU4SY1y9if31f cWMXEZwDG9hWMUYEfZwpWS+/2Axk/W96JPTzdWx1SPoEF9K/qghgCSLeDbaOCmZICVO/ySOQkUj3 TFffIe8B5NN6Z7PHGXfjkt+DeM2sNH5vQ0AN7ZJRpQhtKA1UDNC0qmnaaS5XZWvmlC9ILjr+ZMsr boFCjVUlVIki50eNVTn6yW9PsKKqF3MBJZaD7JTsx1FvFXrSR2ZgP5DzzHWI1o6p2Ec3VvGxYBVx HQMAuwypqDKEnx5GaocrrQ38OR4YNica5GjzLfTNWCdyV+qknaKuwuWQcquh0SxxUfIxXu3lQiFT eExQhzGwLP5bB5pbsvoKIsdYVIncb5FiNQtpHbJYoUYKJ0y+/YraFF7G9bmdx4CXW1nZjI3qt2W+ pyabJb6Rq6u3ET/VSx8/9S/sj6t3CMH78eoupB6n58UgsnV5gudgfolrmsgjTG9a7j1z9Cwa9zm1 5sCF62x0zSHHbNUGVBRyT5+Enu7yvvUorF/dUvzv24A6b68voZ7vAgNhQxtOjaHoN3d+R2Hmz+bB a34XBZIZkquEJ4o6ihLs0nFUsulD52ifeHYhPfpbtRcJTzQ+bPRSUh9hCDbJBsYMnA4c2ujo4U51 +KHbBWtjJnYS67PKrt/GRtnU7y9Yh8eKyhAidlW9on8ZyExRSEmQvYyXQDlXuDHkc0SoZEXHQauE iWWjAMQl2LaJlH8GicHV7V5rXQoVSJFr3AQK9jYyHdgR9sebxdbwJfC3JvZ0gZP756RckX9RTRC7 Z0WJoqyPTs8JTOBKgKeaANxTfW+iSD++dF+eeHO/ZI0l9w+92gTf9mtkL4faQvS5gmXrb7+Zc5x7 8rW6rtZ9PU/X+YMsvmkZNyH/qoXLPRCoYMrOXXJ5tcxxuOccZjQ2p5n/YN3VZIJ/Drk9+Hz0VNyl /7Tb8kmI8yV86YXxw3oJl9BnShiVINallCB2HyqQkyHE+zbEdoqewfyq9fX8LD5u+wH3Qbrj0Kf6 HGy0A2JTnipNooJpJyaSqD6AiFNix2qnHWZnu1q7aV/XJm0ZqOgJas2Lws0hr4NS2Qry3XT+R0vB pZrwXisoXltUSiGi3B1ffWz3mnQ3yXc0QRRoMSQ5NnHTIZVTZ4yyIZUZzIpVSx00q0dU0pKOiiAS +i3mE62t7fyiqYlU/XpteN+eGNZy93E80ChYHB8oUuawj61hXF7nnZ9ZWz3mY4C2ZkG1tr87xQ12 G//He0Qbwq3nlc2yvJXIVd6ynAmcsmGW6ay6r9tFUofvIFnyZFQ6Mrt0QrYcA4jkSny/J43vfPVz SxhM024nDkIqMX7QSRlkwVy6xsvs1le7/jlQfFGU6NiZLh+9fu6YLj7uuLFSAJh6v6scVR6X3LT0 r/2WPjRdERG2PS2YXTD0cRSPRxyemlriiGqgY8DSFGvO88Liaw035yfDC/9Dj0aA/Cp1H6yr8vER kuiX80g/WuM2+pWvQhCbRmvjnMOzVATb2MKbM9a3xo8NtAWjDETUkHFVZe8oLEkMosMsS70Fo1Ow wyh+JEnFi454OS/u+TOGVYGkAIQzQiMiriBu7GZrv6X3I9A/W6dunSUKqqULTQ/BO024wJ4INGTU TS2QTu72DLgIuHrz+cJe+Upra/jZ+yK26rZ+4PFEYFRqRWqx5bTH6ul+HMGQTWRYt1P5+fTW25rI +2gQQbjh+ZmyDhv5HA67nHTKHuzWtsBowqqCjYvlREpLEmctuJQ3V1KuX+Ih4U2iC3GvjCm/L0OW szjZHggut3S1pwVKDfhYEdx26VDKFKW7A/lJrrR7ncC91j41jN4xBSOpC5MUXpXEJOy/9lxRqJfn DPNNDXBc6XfCnhGf96jMFysREmfVH9SzDp8c+jf1fgU/FbG4otFSZU/lTiLBgYtoVKMHZyetXWh9 F64DXbMfgeEt8+PsNYNvpJIKJtZuRBdtNRx2xLKw4bD9rY1GSYt/HjkcOqyLnmwNsQSyCIb4E85n eamm55jehsE2KqY6T+B1lvhR0sODbiqme/QlgqX1o7GrV1uMZPfXp9V5GRmJjDKi/mVrFc1Vnfr8 J/wis78wQ0TyQiVugJ14E0+/oDDBWR79tHKdmiL1FwyOKK017UwFV9lt//hUy7r1EKoZaSXAZqTS ZGJYbYYuS7tb69ev89vTx7WHFkkaQeq3q0hGmgslJRhXVt6uyl2BBHM02ojQOb7G7w/5A+GzGuY5 gJmRvVKWUr5a6j4h0U5h6bCBMNEVuI6Cx9lXFE1ZtenJypJ6rMJ6LB5wG2I4mwKij1itgSB2Lpkf dshLIkJwFD/mwzSyuGLG0Ss0J0UPoQ9/jJFParjASbuyGU9SrSzRhVVlOLUnSjdMFa+YSzS2VE2A /GlMgu5bjzBZekKprXsii164F3m/7+8smX2/ghGmTUYblUFjjw5zKRiGytJYxt0iqgc0i9YIBjx0 rg9A6c+/HO1pfn3mptVu9VzPrH/ezUu21nXdnBzVGbzdZx83u34EesnneOykPrUa+j6lPmzRvZzO ruU1sfdeeR1MGfS+2pRXcRIP9lejCva4EsKhjSAHO9Ml0yfrl3VIuCN0GRwd1yoXSDGQrWZeWHhF T3IxvqqLy07YD4Rv/Ij2Mf1WzE1xDDx0xdR77YNgwcDisFNVtaeU3OHC5RFcIGsklCMRDVQ+wYlT wbnl7khr5aWEJsYS7UDtmN6+IWoiaadfwf0G4yw8nFd6c6qzjxs7sNBDdpNddA1tBF4Wibimah8u USFJS97OvguH6j2+FxReYDSmNM7NzWR/2kbgWK+D1bltyh5ODNycRX06JkqeY+NB7EOZD80fqmdI aBebvfjzQ0ppzzZoBC2o74eekSorHKiP6rI8v40/c8NZZonqlRVx8vUE9K3iZ/sV2uGNPOdku4fe VhQZhQNlKInB3Nxq0OXQLYxnEPWtuVfWBvXTKOHoiBnqGKxXyC/9Pzorbmrf41OC5bhSR5mr6eo5 jciuwcpgjDMlNzTs8ZfHHhwluQvCeKeZw2Wdw8awRrx0MzKGcubwJR+GqR01Y0nwNcU4kKS4jqOD iFSEwjZMT97WANIjUsKqQZKSd7S8jQI4OOQ6Hd1VVVFv57MF86AMLq8wz+ReFo+0t9M0LhX46HxI xJNYh2PVFV/IASqGB7uO87A6elTiwgxwdBjnrr6OWD41/VwiQM3UJCnUxvWKyTGl6PiWgXkCM9cw H9pVUsdvM7Dyt1yxivCiydzjLefs46iPosIbDNtwxKSlJeZGxRuVinNHzi4h3Lu6XgQeBF/h75XX 0JcEBZrPXc+KOzbU21RwM43fSGEK6WRNRVOLm6mexZUNuRmmaP1zNTGMcRT6xT74mlPVMKl1OTn0 Mo4ssQt0A2saycz6mhcwi7KkCzXnw6WTMmF2NNhCPGGYg3izX7kIyoWaIUQWjEcLchWsWAsxvomz fdSZ7WEhitCAUOA4C0qovEuv0RbXXjxEwiDCs4t6ZAEsCIjOHJeIAi2l6VXgZdNCFLIElIdhXzRS EwY6c0gFtkD1cu7WD9sjdQFAOllycvpBw6srGiuKqjZ38hNri4xlYK7s2ypBORO0Is7xqvqSXPRK Ey1M1ZOH9lRgWyEAT+9CLerDESf6B4D7yknrFnps8/0Tq5PIImcDMzRJcAvXhqGZ48hbXYCN20p3 Fyqatl6KD1Xw7emT/Dnl6Y2wN2Pra0q2vSlAfguMwsnvy/d6AjBaGDG8G+bjhRfONxtSmsDdOc3u fWY00N3CuZU/Io+uxf4C0Zvy9eOoNH7IKVf+mvb54R1kBnVBBWcJnKUdDbIZZGwbgHpJfIDBirPY 84q1KANVkGlhE+chBQncCaFAhYo08Q3BEU/quBqmgqBuliKSs+LQObmAmtoADl0JsrfG0wYj7EBh PrcxyTkVcp26FnIxfBlckqnPlHTo12p+2hwXkX1xBLCMBRebhnyLJTdLraGKgQeVyiHBoilEleXO Hs6aXwfK8WBE4p1McbRy62QEW6mLrCs3s9wMyK6hzBF7KmcVPERInKGvhTdGifa5O22MXw57acKX cY44RuszuB86M3t34ER/rDp24ExBMesYDhOlWqJFWjnuaDUMYAadQaLOKyUMh6GG6qRJE4ULpg4b jPUOEl5oFBgSz/uq7gdS6grKc+dSIzCSqZ7Y/3L3WG3vey9YCTs+I1jIxFkAkuD7NdesC1fqiqDB DgKJKHbghAByUplbaTc27gi83vnp8XAYOSucQvivxFqeVhG3Q32wpzevF7JLfNntJw8juZt6c+7T kV/HmU3b/YhF7ZNBSYwdttOfBD5vNBl5dF2mC0GKj/yT5zpd7qdxl1c+baP0AhSfaINnuoQzcAKH VlXrr/EfWVdcPkBKR5AO+kGj2qZrrDPHZ0tPokly8t4dZJ5ggCFxOW1nAW4F0wG60Ti92jjN38cC a7VIiXB+6jyp0ECyenmyevxFHX9QpUzBmSuwxLFcZbfQ+FYx51tofhTYAAwhMitt/3p/zk4uE7Z5 RqhQ/PDhGMM6Q3TOF8C4wDdOayUoHFIzfPD78ouAcsa3wjuh6fd4Kj7hsWGPx0RCh0jkhtsGh1UJ pXozcRWxEMxqhIpdkxW17MAEox/d4ErpOh2zNd9Md+UFuw+7H0fKdGQ0p4DwGvxDZt//MJsPFb+6 +VWlx2gauF2COzx2Q7DfWqqQaqLRnlIFpl0iBu/I+85ilm1gizhjSqG+hpDSoNpl/91VAdJp9Yjp Uouz2cdxMW0R4hooeNCDTPrtfLP4Nsd5X7bvr9Xf1W/BzmiOKrcDr1u4iOB/CeTljM2oHdpMrIS8 i5hllAbvZluij16XGSfvjZTjh/8+pB7BtpovnL2macWpEOIGhzGEpsEInfDRNaDJwacwJtMxTsQY HBAkwgF9GxEdkzMlDWEDH+flCYOcy8WLVH0DqnSgtGAEGIqga3fuJ4JAI+B9DwHimj9nN3yjzr6j vHsRbqWbfv3ZA1VM7wUlKNoT3St3SMTZRyxQFYGD6CVqY8n0QvixT9D7wor053pVj/CecL3NZn5Y r8thvTnqZmfcZ/n+q+Vq20Lwd4lWwF0MZ8BXFqc+JXJzRQCzpgTdcb6Kb4ZPnTliw3QrhY6uTSPr GFnioo64tF9+z/6vRMyxKWkrNUs1WxFLEdtaNgMb+JahVCnZlqEl9YKShtx9wo+rkK2oz4bm5S2A Nxt3PIKGozYtvuW+hLZJB+wS3xnpQ1Oiv2wLIgdOGFYDSjQ+DQtJxQBcK4amleYSrW5iJpP0VMVv X2JMhIpg+PWyyODLSTnIOr3qH3Xqs9zwVQ11P60cgTAfb9OODcS2iNYwgC0rmLx3f9F0pBWU8GLE ncH2UqZPBcn2FZRPf970x6CLw75NQwNUtSBQwcmNcbW1c6IzO2/nBXDNP/6eY+yEG0xXPQWPj+w2 AZ8Lp+q8b9h3jFvcdmub4IDcY0G/5ZCiV4Umxe9818PrDr8+KX8D16WoemRsLYuWN5pOfVd2HSHT 9qaPzB2j2hezidYT6cY6Z1LdBmW0SsYlI3VbtPtVvIBhfnIdH191KdP1kXW6PijFsAsHvUldv5yl ccQoKXn3kN5lOxZsDhSrz0Oc1AoJcDSLFwi16+xYjvfD32XSP/aox8+UwyES7d9OuKMARwa+015H OW4NvckTfH+c+srLaEZaWuvOfeCbZ3muYbuSLI1w8J0dtsc/Dor2YW+PF85vQw44x5/G20pb3/z1 32g10kTnHC1XBtc8RHyjM4aYNPg1+u1UsjZKmyvsdLJ6xHRIGJVTy2Wbyb01S6uAwTsXag/hC3xm tZ1ETfnWbkOnC68LyCmENshq/Lpv2/WUKRbNlDR51Ws5L/IUWur7fAfiBYVUxZEiKZphGLGg/30N a1Rfq7rGp1gpZwOHLW8Ols3TTAY3FX8rRX+xLKFDqkqSJuYuhiQOwZoYThfni7KDlvBGIrdvZpwF cgO/xu/64dgOmWRC55uejLHSj+CK7vEWxF1XZbnCHR3WmkJHaySzC5pwB/VgWfHk1JD9tvLw82fH sxI76tCc2uBDiMuDozfBxY+QbvJB9eDp/WiynUkptOnIWTRyEd7wBHvzTwZmdVGFTXQHAd0gm20G Rwl5J2cqzG0EEt9ObIXKCCAgRX1pf+3M5zRj6fXhQY7fVUSV6pyZ9tRZWnECQkzoBzRIX8xvUTJV CkS3JIHcjOILvNER6fYy6SNFTDzOA0IM+L87R5Eu1i3mCpT7kdERkqqUJPigiFXbkXztYG0H25/V gDi32T4xwymmBjCNP+HGRkIJ+1ZtzlJWkFd1UyupJi90GlTLScxkmhHMk8jEUSqCq3SsNMblv0SW i63JQ6tozMRHnZmT62WIiiwK8O6wXHfV5d0HQhEtUYSExXOe2CH5yysm1ZDM8FxIMz/N+qFe6M1+ NSdabZr9cRqIscGfF/R9SKD+v9guq6A4GGBLBwghuLsGJ7jr4JKgwd2Du+sgIbi7u7u7O8FdBndn 0EEGuX/dfdqtrTqnv67z2FX9cI5jqtr9RzpSj9eyQRXDvCyIX85NWntury+Ga2sE71mEBXtcDwfm LDT/Ljzs88qTeeirU/r0o2r+LW1VcKgIS31KUhts522ZWveec8EoLQ9kTSd6x8QR/2hGZxhCYOTg F8h/0aOsijX6y63fz4Sk47ys9iPBSH3hu8yhlsc8ERlGMfttmrtTcJvBBpNz2MGJnUnpKhUZHjzm PKxR8kkx/Hffn6HpyNi7SLCX9j56UxPvcWZ54b8oYMj8MR855X4RxK62n/gcYmSrbK6YPORY5hdi Apk/3bpLBD0Q4fxYsxU4QJUWrV2yb8jvPUNY4tS4H0iZSFna8j6/Avj4rlXMj7bqHDO9Mrg8b2rp LfvPbAJFstSIi5Op+xsKr3n1PMeFcYJZhMsx04tY0zh3rYhJ/FnOBxn+4S/WsZZhsbWGZ/ySYCNF g3GKVtEgKfDlO5iVPk7fhWIEg2cJaUlu8XVygt91wlJ4vhkNCJyYUvz1Eefj4pdlVKLon9tXNpdy 1W3iFMA4LNDREU7kM7J3URFmIk/mb0/jO+AML5zdVrXURK9RuguW166TX7e5PRjziFCyLHxj3LQ7 LSwUrWY2OMoTwzlkkuB1SwuGW1BEPDxsIpinEQwJuF5etKVgSMvSJaCroB6xqgsfRDjFoX2yCVwm 3u55CmdIARWDNJUy3cHa+iJXHTsVDNGVaQgv7tucvhtNhI+b01y5wuJV2ME99PUxf0SYo/pCPBEZ EgLg4W8ahkxDlAKhN25rj2g6YFLqGpg1NDJuiDhVrHL7ZtWnnnP3RnmkjKzPyCEUm/YNI8HNsFKN ejopEuq/xQhj9HKm8ym046qprhTUJVzof+KVaERXHETNRxElI8/ymfHkTE0mH41FXlOa1zdpGUTW DK9wrPy0ObRJVvDEbozvlujS71B9RwRRbtcKhfpVdEUZYHh8r83fppeZXR8/PpE45BLIX0xYUR6g L1PLj5ovkherobyrwZ68GVJ3Dp6Okd9CMCCFIXRRYCv8Qx/yh8WInEYxD7cjdddLIZgBD2wWbj92 bAQxwlvqT/o+G7teFJaQlILby8QYZpbWxCsRoYkjrn3iSiem9hvPuEdxUKf9oKPmkZeQr2X0cOUO RYlaU5GDhUVT5A3Oc6Hesoh1OzU2JPbhqDuw7IiTlKnzuTOR07hE1zhktFWEXqSV721sJeCG9SX1 zcJBAHPar6f2w5plweMcd8Kixtj+sSMRVvwVeUiQpKaIb3A1UAwhQniriSi/z3z7bN41w0TEST3u ougIOLdg5mmnkaAj1qDfUb3KJE1kLKHFFs7jGq2Yt2I76YhkwRgsHIbgyvN6OiR2nh20rOva4GQ8 TQQUfAo0Cov/er9PVKNjTLt6d+ljt6yoAu0/iBQ/h1g6ed61MdKNO2t0DZ3HdbBSq/Arzv7OxUik Qpv5pvjLbCmOBPlZq5cg1cQasTx53iQ6idu5TJmEJtssynwUsYbvZ0ZZjkNMIx3f3dTptIpToGuw S7Zjd5sOiO6C91HgA0NxQr1CP7jiXrZwvMr17JVKOdGlukkZNCBcBQjONc/RaLXxmTUw7r0RvCLd 1X/GvsK+c5hG3E0i0YT3NIlmYe7PfJJUFdAXgG+NZgj5xz+WIsnAnGEFh/RF4rdbVfHDVaDHBq0o Q7anIWo1kuvFI2KEtUVSFSAxs6ZpbeKC+FLQbliDby/SCG2GbTuXTCsVoHysUNrkvbsy8X5gOPnQ 6ArKG5uIoCzPKNFqUbgG7tmT8f9tjPLAZyiJf21mlv05557FxPriZcAVlr3QsbviJkGpbq8R/3rg mianFYYzZDS3S72wjJItnCPhqJcgiSk+yq4wKBrxUVS8705a4ljnzes3rp6gitOl165tnGRvnsKo VH/jDDXPrDeWa/bcUBRMYEKsKYXsJPYkRtLTRMgLxM+EItZ++6AYu931F4mtw3Dj0X9nLcGMCFmC JY/b5aznZDdVTM1ZTJiUg5NBLAVERAUO6lumpbuGxe7FB+e2Ywu6cJ5kvQ8KDhunXdFnstc3Biq+ xX2JucJJ3DIoZfvwJtezZM3/cwD6XI0Gxgrtx/XIj5/0AytasPgddWEAZsj4OnR/Ov/kamCTiYeU RAe2QgSmylJ88wIvg0puN0zS0x6OBhfa1z7R4yj5fhNIj6/+fTP0jv8osjDOLdToYLO/5uNx79H9 JP+Q+7VPCGTTO6232XoYHTRZsCCTRvzo6xJGoYD7T8IBs4j9Gk3ToyN9hXqk/0HxqzTHeywjNkyu quwot9+hIoU4tyrNivZUmzZh7CiHafHNLU4l6sxvc9m7g/JlDl9+F34GoH1fZTHxQee13Tzp7crT Z+zIH4R6zGaH5qcW87l1lphq3v1IBwS3EZ+/bjkzfk03k/6HRMUgS8Q5BE8o76tqxHLYWEBBn3r2 I5SLYiFsnAhpIXqKZS+u65oS7uM082sxld1U0vk6ShTKiiXvMvEoas60kXy/5oh10cbfG7S/pXmH lp/q6eUzmTEXdPTd92FqOXUIyk/g8nnlRv9VC1PsMS/L/C0BSpZG4exscaDhvJ8UUCl9i9dyUOKe /vGLwAuUKJr6+1yTNQBPLPledIMd/7i8ujjw0SM97+/AWSK+yVQDTlQ26qd2xvuPVSjeU1lEI9ji 6CJr87cSSwIBhbM2vUlb8JhCnhfDfJI0MQbcUFqfPVZC3N+pYD33RmRaBgWVM+SCJJVIvHIFBumI H/EgLkqVIiPmCOVKE91fXUbKypiYycAPzmNbLdx1P+A2+O0/y4R8TH5MpnsdpR97mU/z+xiXlunm nhQxCGH+UMzA6snaEPKjXOjl+b0XN5EOnH/6llp6HdOxccdrOZwL0CAtM/I3rOS/b36f2ZgouEqo bZgqQNIViY9hlON6LqHbLNmlpPuIlCE+FV9Auarbd37+uh0BoECP5sppDVJa6VwlufjsUkK38Hbh lxrtM/atN+Df/EHkwuJ2u6u6yDk0yWHwl4PqR/0/h/1awwbf9CcUe+sl7IiH8tG/4RfOIyytEsfa IHIRQOz5bWliM9zrBl6L8fHz6IwI5PzRL7z5lsFnQAM115rL0psk84eQdtlM9rofaVIQqSHBh0B0 9gNkyYroyL5xqZ7uqk1i2rEGAjODDThIUoJfwN8IktF5r3nb/PzOC93GelKFlGI9FUJksJ/gIAhY TwCID9YTETTj89ZvB9mdXD7hnwcGobzxx/y3WO27bFheJn8GY6BadFZO5KPW5HerBNNR9wSysca3 54mm2BWXUxBu96lpLFq6ktERgtNVvNJHhRyM9b6LRNLTLOWOkurdqEewBbBc1Q+s5ld5x2evuKAg vR23HfCneW+qVqOile0mdg99nA6mQr/DlUHX+q0++OK29h+6gd6C5sqlBCWfnO8kN4f/PTc2VwvL pC0U7aMAAJwOSwfeOXT0GZU72NA92Tr90j4bu18bVyklKcXid6mT9Fv04woUsfMXCATXg3/urF+u Yz91Q3ywn3SgoM89Az2UgSurNlie4YXU8TNuk81MuBZ83LJdImKgkbDAfybGTEdt2yyM8wQoYwzZ 9attrnCQju8lYK7BsPijCKsdPTm6tIvvCblstb+WI0Qa2fR7CFJq5N2EDJwe4NWeHxYcn71MH0BW pyqr0cxJ4Hda0BS4NCZ2hxfA46n2fvITuxl/YMgd78vLSzRVT/ZBuk/gP0H2Wvc/b6EN6m/3uwCI 5uWrGBR8+QpEgObvW6AZHGvt7tyR0rQVu7IhMBkpeMZlsLmYjC8KCnJ3v48owXX3G02dNY7VLqms Xs6D41W1/NjtimOg8fD1oTZqNxipvHPifnFMBgDAq173jQzLA+3VzXWlI53HSJohg6Dbrk/Mbupe Sea2O2lZy0ju+mSn4bkyUv7LC/2zBnTJ6ra6801waf2UaXG45reuVuyGMvm36W2akY8Ybq8zsf6R EXJNwyszLYjtxLPwBan7IQ8HNIzx3YvcabjdR3I3WNiz5SNCuFafIHTaoz4d/4XvPVgY7aVsAnOO 7t3wBFsJ7D6cCTxAj06zQgR4x98jAgdeqID3M4mvsd1Nw4byLUqs1G/SnGs2PVkkrNKkYT0r7Rtj sZjsucPCuB76G243Ih1M+TNlf1f/emCj05H1+BpsJ/Xov/nNfkwzvlMvBIy+8y70FfkLRku8DOYF /0B/bZ0vlztV6UhiKf5I5OJ7+ZAlcmfQl/1AL7EKckFYMZBNnS92/S/4/+Kjl/bOQrZM/z0FETcu +mVOLQK5WswvfZxTXDDeIiSGYobyWTd7LWJG04vl9vxEIBlcwGjVcyZo+JAdm8HUQchtNsYqkVM6 fVTe2PkD+d/21qTYtn4Tcvtr5riH6tMoP6NaDQNq4VL8QZbJGgrSx0BFJmpjG3NBdJ4f0/qeAKi2 ri27w3udjz6aR0sowt6sVVcoxOP2YGt7Octy3cJJegBSP8y/JhU+zE3E6MxkH2lJNYaRjLcy1zO1 566zuj4i9jZkhhdb4BCujhdrfDds/BxZz4NqSgjZjUC+9oRSD7upi6g6dVbMaGzke8bvKaegKtiD Zg9K/g9awnhK/q/gf/Hr9uTrW7Zsq85wdNiL1rDC840KL1RnGLsPusrLkEMw9+5MM3rwE/PhTX2b NMIwH5TGgSDdREjSH1oO8cEhL3/6NjxK/95wEPP1jRTTlBDzQdqT5TE+cqSf0oqL0JYsWRlxXFtN QV0UAF8mveSLLdO8w8EqCWy3jo/gXEnA/ye1VqYb9f6gVhoj+yslrxndi13HANkgpqfBrt1a9esi o9ewpWp4Q0pKXk2G7AeqftHid5q5C15ymUO+hMJOSxatfAEOmRrxSy2a/uLfqQz6+k1fZVD5dGub kqtVe4v6F2empKZd2V88k99VGWR+VpwvWRe8wG/+NGKIU4vBtHYqUZxqyJGWHMsI5vf3arnz1g7J qDWccmGPcQj4q0KjnENa6FpeQjmB1riUzrH4Y+rMkuvsiJ54sYLzcPzdJZ6X3iZNp/PEOuOPFkHo ppLOQPErluha3qsVaOXesHy+2WBJnYpV44Hbuku0Nlm/rFxdYEkXUq3ixxaLnFxExO1dfKu5aiol K72aaWCTo96tkwYY8F6UbqpWxmMJGYlcJCgBvMo6WMVHzvQLpdjhGzd9MYs3wd01bPp7savOBH8p k5c0p/v7FOi0pv4R3W4YZ7BxDtXBzTQ2DFnpGzbHaGcRrl1ZofKltjCZLjaIxjfQV+nhXzFZfFqa rFyKeJOJ//XEX5uqVXkRaaOg00x2SaSmVF5dy5uhwN9QjM/8roxSvHVMlJrCs8ZdWzXEXdlR0SH8 S3XvxdzNTsHNzhjo5aZeca5Tu5Ks39NW1TOdrK+iqXLOyKDY3dLSNXv+vdYFt+PMBjlS7juyTWpb hVyvSkRl17h6rMtd5fi5XIS+yznyudxse4WnrVt1JZGFtX5kBXHFmc2E3JnKIGxJRuHvVCb7a7xl xSmG8urEAtqSEgXn4snvhmq6+pr6OiLizRnctR6rXhwTZcz3qZrM7pu/dHR6yoa4R5L19T+Tmqey fq+E4C1Hu08xDBlFjiPruyATV0R8A7k9JP3bt6+xd1TH+6KH6kYzi3/HWF1T4bGk2RkxcW7dxQeT rM/dfFim95eThh75XI+bpjn58MHZRAqGW4F1pCqB0lF8vEy9mbt5aRg18qyY+dXsF7XJ56RD9cgu 1OG6asYqSbdk3h1ZBvLd7+VMfy7CltU/HF2XurSme1qKFKdVvHcGPpWwMmkbanLKMozSP9Akz+s3 HxI0t4EMD6tZmN67MJGmyge1uw0q7ctqrco8cFOfitLnSqqGdO+8kItNWKs1bNSu5tW1UJ1TUesI JI3gY5TKSAV9t7rmx9RpNJXqW8R8fvlI+uA8VS8X20XHqZe5N1/fsNN0HriYJvsqZiRYEP/uBEFI 11vtPgJ9kXTwTZbGHiwNuMdX3SGcG1jj+uIG2tbVldr5bv6y+ZUHrCR690pUXnQhPp1xr67sV2fm NzKhtwwtu5ILhlj6fO7pMKTvyLuxPZgC/nbuGu46RDrxbhb2eXzD0+Igkg3PPbT42iORb9EOO8R9 4D2PwO0p8JcPhu2vfugi8O9kIsjv9V9Qm4R1yOebPtvRPrU2gwMsrBR2pnQ4naqlBFHf8yEMTxYg r+u4V25S4rUzR1Y1h0oEhzr4vqAWiieOddIdGzuRz4YWugjvVOuxfSuRTkNDnuyBXOzKenDC2r6k QvozFCX+cqNt3inCyL4twvi+Oa/o2w8kb7TXegD8V3MAuW+gAfpWHm8A1FXEs3BLWs9hpRe9R+UD 5qkagmYCMVz1F8sANr59u9aPsQkXNOdLSTxqGw5c488g9Qj6WLxBe+qMWdghlzZOKsssfC2S4hZw krmIch+JO4pyKwmIdYxByN15pXnCO4bbWc+ODQS7XcH5bzzLXNNl+1NeCR0Iwbyn3Nkt9u6/fnpt ukN5kpmO7ZsRMPY6Hp122cnt88roj9reZ3HKvUG4hhuB7pATlIYTk48MYUe2M5WIWLH/Y78lHDB/ zlrAMPNaOCppZhY0jVlLmxNCuDgaczOSjhEKJe6arf/qVV74pX0GU5TsL3cRaU+kbzDc40AMmL8H YevMEuGjZx9hp1XgHfvVfVVW5xQ4QUuyTAAvDOLHc/npUlL+/E76WnRXlDGxP/ZIDGUvFDEycMb7 OQYduR/Wexm+hwOzHptN0WUsN9pjBTcHSx3o4JQ9zDcNN9PIWbpr/1Rmbu8OflDXepsbOrKwaLsm kdVCJll21EGZURnnKdJI9M2JCOcz96QNvwSYa3nFJXGzLkj91EBm+Sj8FWnDR6yUyvzf3xdwJGuW dxkcinndFOAl16o9X343rL1VTCZXeWZMlvueOkuYnJvKv6BOVnlLnYzecORfn6UrgkXEsuTRndcZ pxQ5y0vUyMvGmgBSIZcN0GcZjXrZQ9R/R1rD5Qr4Mp6LMaL+uvfGojF6+HHy0s6BdttbQRIoeAS/ it69+pCiylhd4ObK6zarAfq52RSbU2RxaiagSHfKBRy3nTT6xxSsYELIFDlliqzFrDvBU+ejTbfe 37FqAPns8yWBdEhLUNpi6KVITCYJbiKPQRY//TBu/0iHAGSdkjidecitlHmYpNaYZT0CD4UQNk6+ VmobtK4wObjGK7yTnEdnFw1eTDZmuX7GYBSyj+m1LFwM0XJijrmk5814GEbPNPtZoc2iqHJpe1h+ yDnuMs44WRihgCvIiKbWZUvmhd3NsOUKJrkrS9CkVY+pyjKH1N6mm7nFay8XVWrEFP+Uk2HJ7uGy KPc4jSj2YNkssTYlEiAis/ds2LUctMod5O1LPZq4Pnzp6sHbFlDV7X2NdtdOyZh/VTdfS7NKCbRv ROlxaNE1sE5W/w5avX0Y2rNOCh4/NSsZdNhfdT0y57aF90lwEQ5cuT181ehBWx0TfELzC+gNLsau bA84byaaKiWdzennplxLsalsrm7atFn/PhKuAIK5+Xs1z3hPBGx8b8CzWbkMPwn8nWs809x5OQxR hDqNqo1qjPqNLsS4KMMVjEgpxH6P1sF3o/UWv0ezSGkcbx9v32r/t3YqZH/PzhFFYpp944syLDla NDwZVh6+hrGA2Uh1tJbGWR+z6lT/UG9jSh4DpIQEr2ru2TpJ7EuP6sdakuPpSKz8jfnlffLVh7Up BIjii6UzSIiBKzBQGMiXZZFE8H3wZVYNypEBK496KdnL0UF4fBcAf/vAQGKDg0/0IxVGpUO/29st Xyn9rFG0pyC4kScLIO50PDNv1seWVc8ALBlbmZTvritQJx6LlEFn8KBg+/GPtdCJLxVGGHvscwMF P/GhbxI/vYvyUf42LMUXFQ4mBsK4BmwV9+8MhKK0Z40UzLo9lKHea6pnVmUre3tO0j1EvBiHFEYE 02OarxzqsVRn6j16ZsEedVR/LXBjnQ4mvxQc5802hNVzMClwWrLEHOdPSmVmwtQY0CTVYlpb/77j 7mNqX8gr9nWLe1zm9P5qx21m+vBCQfGU9gsm9/NvGN6QjueuX7zLEnqWbC8oI6QqCK9ZMCIWfTOE QvxNwYZS7dS/fD43y/xiBPQS52wrEFmTgwEN9U75ms8Bs5G+WicUhrjeyQXa1ifqPHhtRASxjTei hn3wKPAhcIWzHBHRaIDREdGMr4DQk+9Bixw/mPd/EqDzBMs/Mz4SRGLNuXODakLu0+OEsBMsxO8U LVW/kE7kmRIeVB2x50d3oXuKW9KBQzkID3HpEWBrZuUnq8Jiv05Ro7WHsoOML645IjDLPxKEO2yZ dXWq/TDspZzKgChvK6KjvEaBvHnHxLN3qE2+KBqecBqeQY8IX+BYjPjYYAlwvfflnH1kwA+DLrl3 QfbDi/xDC+0/GDFClXgG8ImtwppVknIxXYL+E/sIpqXXZx00c6u+pT5PXIRNw7ojTK27r1zkk3O5 dCHmg1iNxktIZkuB9AjGho67GyviLkbZ3K+yi/pSm0Lwl9J5fr8teWpajRX2jT0sbaQ+MmqvT/Gb n7qUEvtYr1YCbiujeknr3tF+bMCEC+Z9oGm9STWBYCLBopWkdU9oG9iitR83bWdwP/2ierHnX68l 6ahf8oPIu2NFoYr3wrBAHvEBzB9x8UuIiH4nR6GfRVzvBn2yw3yrGCOeVbj0mRJC/L5l/K41PXFD 6Y7JT73fY28SDlkenX1hE4LgeJNIxJpez6ueuMmvXVF4k0rWBp24YXSjmVQFnXhhANALjsXu+cL0 KbquDjM8/Mx6HXN3zUWinDEemZ2+kWKWLwC/ibjBCooDVtvdg5HUrkb111m0fInMrm0k6J5aLVFm UB6uz/t6g1SuTBrFM59tL37z/tn+2yF0NtFNzzhXgrShZEqfoiQVnRRX7p0jOoN2LxSVQ/eEyudB FVOPLz6A6Mf5C1ZNPHVirjFTSSLyVFac9yMlYR6VYTNuLzTJnvsddXYwqYEIq6Od+FIWhrVtsZhI C4nsa3af/rHUUXT8K8G/WGVvtnFrYewXs4JXtCLZcK8d5E+8IM8AymusPBwtlKT8GlgzmvEvScJ5 mF9Fe6Yt+vEal+Q7Pb9daIfsy66GVN6kiFZaTogDSoId/fAuAOhxPA8UOeNJ6opxgw3iqymAugFE swnifmMRPSvKaruYTRp/QzyZZ+uDHhyzBz7jcYQiRbnJxrolxKcaVv5k8ABZ3P60uBecrUnMEpzP Pb1//0BbbaygP7J7im5d472RxWmgm+ajjruAjn6d/ZCeOte91txsftERAzme0VYmO3hqI7bjU02K U/dLWZhkZV0R07X2dywN3ZVlFlwlZ3f4Okrzv3TR16SzwPypWbvGQy9C001fAZ0MFR+Keonh5HI5 BKFewo6qkBXeO5O8z27Fsq2wBjEq3n7ht+/WWiactXBEn8hnv34Wr7Tiq3JBWuZfsiFVjUSzdBpo UAk1y7fHPWxcymC7zEIfe9L9r1SavXZ9OkZO1iD1xfRkH8daTC3QQxlLY5LRhmGCqZXWhluEdROl othfMNZu1o3Ogg9v9AZswIdv/tb0DtbMKddMxY0HhO3JN0PMhI6DqXSvKJwPd8pRBWUlSdx0Na7+ gL2r6OPeiR2G1QOb0V0pXpIMMaDGDtsBBuaLboOVwGJ76+wJNzutnA3bYWuZISJtu38pykvGXuDP OVVIS2TGV5py7Il8ntA6630xBZhfZXu6LZrnatOpmuWeYA1BWcCOJtH9LyFv02AY5492CrEry9Dk nHkTOe9RLhrm4HtvG4cINLBC3KLp6ZzpzxMxh3KJWOt/c6Uy1XP0NkM5X4GdVO49ZOV0Rxnk9S3n u98sHESUalPwudQE25ptTKgvlK5Zf0cp+0jlNwGHcnabf8sB2yqSlxcXv6o0bDiRYApk3CHq9oAa emydVgXWH4YbrZd5Dh8awki/C3SVJF+a6dF3msZyM5tPfWHen3MW0okpVbyfaYQMIANeKshKUrf6 Mth9ZImfqr82PuowqUDr7JW7t9DX7/60DrZc9KP0OOJp3GrJJI97G1QFFFurf9/+YRP65qCvX+nz gKjLVeX1VEUS/ji9suUz3Fl3h2N0zPBL85X+oeh6JgeLT0GtFoBJQ8lOJH27eYz5gyhaqmHOkzpQ A9tJyRc1IbtkVk1ou4hKamJGawfNXzhBjFeVLOcZj2J4TsIzJKIU+AO4Ss8TgrWqxZOScC0kkvPS 8Ljqs5gLHBMu+A1hh6Z9aVBapeMKmyDfI5uEx+f6u+7FhXr4JTZ/VyhmVBkJPAGd/7qV+1ga/4ok HCB90+/7ldKDgFzaypePXFHzDtP3c/R+4RM90Yyq13eFHWw+12PV52ZX1JkdzlNioUSLeRQ/QK7E 9oGLE3NPzvG13vieV9gHsSc7a3GmJ2FXwiijJ+rhnYBBaKcSuUORVFd2qyqD4T/NeZOeiNoCDhPv +i2GbavS3vnPBSFonzxS3/fpW+E6+7bF11Av4NG0+D4L2ezSUBqijhf2nff9vOcPvgXuMDmSHduJ cmGgU8PABeSLIsUhyYvmctKXwi4s8R99qGVbRJMcylMgj31xhuE9I6WPDEQq2OExopuVYmpDOPTb +amxOnuau8tLtE6M9nSXkvTSjQqGEtP48vgnsm71wvuW1raxKyfjRof3LLxr7EBCLt8nQ/RFW0UW BNdyT316nMQkqvzdBw0+LrZ4ZN7gyyYk9UsYtn1KHSp7F1sHDUGOY7ml0yKRt25J+CN20TvFqBb9 MIZcLzT5l17+ZGetO56RrMO9Cqc0E4Xv2QSmIjGGJ8wz0I/vgZBRml+PeI7jqRH7iH2uH7p9DPf+ E6nrBJVxS2ODQkKPNMXRgzS+jESjDBvLfKjuE3fVd9uMxzs+BN7u4r2b0WjbPSMoVpF1qL6lxJEB HPweEyOW6M9YDNFCtr1sRrVe8yHGnQzarIZxK9dYto4cA/YIr/DjDqF5g8rgka0X1pzYOirbeXqY jxTp1ZflH9v+Upm0258mBf/1krURv9ofxlJ/dFcIR+Wn+NsaBlRF8r59ye6oco497AXMPvxjfZnh xfVLeM9AJJ9q8qW5cdz/HoyzKoRf/PmMeIVnRFbL7kotrCr1feoLLYWBQHVbSOy39SiHVu2Cd76z xEGn2nEi7QIHqULk0XNl2tBzoPDQqOxQiCS1oV8gVYg0lR8tY1WQQuyLDZDYqFMhQABif28nLa9/ vXRp3Y0jR85lQB4SEc7227bL5IY30IPSlLULrf7qoH0hWp3PXlwb/TPw+NXidXF1b2Vq/lYC/+Ij KmMl2M35y5PaCOCCH8F9Iv4YV+D1lOOLGomkrrAfkbAX7Hnfd2I0rpbKJ0328mUxPnNkthwmGVnS Ke+k3e5vHOaD7GGef2OJ1CfXqgCfbER+qHxxxLN5rfpQ+zXqLYKU1RqDOkn1OFBPSN4fj4RZj5WT GhHsuQA+4zMgk/B74utg14YVzsaTH9xYypldvdLFz6I+xpIPJa9XDOL81cNyTPOI/vEj+CTsDblj /2xPDZyV4D2zmL/FHK0Cthqp8ODcX4KmhZ+RTjIu+qRKLHamGKqCCdA0wY/F4uPg506SFVy7Op60 Nh5JYvEM92SeP7YgejuctWZ2EMEP8sroYvpL60vriOURm/1/5QqLtPH5QE2bQq1LKMhf5U+Ljq7E W5Ngk+AJ0mUoKNYyAGJ6OcqlBQ2HYDtbeVh5zGFcloIAXGrQdIhLhwo0GCInO3e1cFWoDHoDvXHp QJMhjESFgDyAaDkoCBTEpQFthtjILpDNkxVUNm9b9uY7gRyat+c9Lz1AYMs/kDDIV4VFsiWy4p8g U5CpazSkDcKnsIxmHWoVsVwIkOFsErFhnW9togJhji++F5AWnjdpNmtatUAyIESbed353WIuTdig dddCSA0E5jAMhz3jVqpjLA+WXXWyyDmeoaYUKZ6moUxlEq+xXHYS06VM53ekbQXm3ZCQzndnSbSl CL14OTdKpQPlbi0KvF9Bjsi8z5KB9BS99FhSi/QRUuzwkuX0hXllGAYdUmrhRNaYzQU5PXS+BfEg qV9MpeRhtHOSlZKRlvlLJsFaYq3hGnOyNpKdlqXrw7L1CVcYrRG6VtVaNBpz6MN2ezw6dPb4rQux Qzr1KcuRbiakb1pV+OenioGSIpjEQ19AFFd4Hgv6JoWrPzwiFUyw39Q2GK+KowskXGcBJo2r8plD ePXBfrQCUnSbjC0R1fcu9Qq2hWj1+ralhmGkJgh2eILDii/FqzR+MrpDVHvKIFoy7N5ShOH9PfQm VRIc/6LtMJHw0jI5ErzQU8w5Km/LVk9FIZnYCJFIkQWymwLPeDJsmSFMEOM75bt4L74/tn8hcC+N Tzo2UnO4ssmwi9agUCSMd4jYVTQLg+4k76nzSRDwbQvPYYF8uHNP31uli26rUCQcfQjB9YcvvXBR 6ZDMHpW3ji+TcMngHvYNIoBKGPvb2Vx6zdxdx+zlfQFZseCpGUA6Nr/31MmbhHSJdYG10NT7T45o 7UnqeepCpbdhNyvpCvRcc9bmRRRI312OvhA6J/jiCOTrriw9YXCVJS+PLXq8n3ux9DZUWlI9hQMo KBUuvPABsYBlSst0C/zAine3F8ncEv9E4QX8E+S0kk433sZTeG8YbO94gyHXDW4Wc/duPVYLRWD4 lVmIQeVKvZZFEmfEsCC5q/AkC6cjdOKFmGdwJAF1c3YNN2TQsQ5Guglz6gvRk2lQlBZVCirPXrTn EccLAXAVg2rux2+JaGqqcODUicW96WDUb6p0fSsUti91uyMUg8M1HCFEg6s/TNvYs6LZVaJwUqyj uKQb6kcsTbnkOFWi1dyb482LGp1GuEwFoCHsg2mD5gRr0jydc2kWk6Zr0jHxg0dE7dIsmRYHhF62 PfV9Wn3OKK275ryE8NIwE9wRUZTujcq2OI1ChYv0ps/Swcr9GyEr1xyxymZq9bAmvhwOHY4feoHQ uQgkE4MNGc2dnLYBhK1wZ/46WC2rXR6j7GBUSbn5X/awPHC6cwiPW7iCAaGBm33CO4g7VjteO2Y7 uDsKO6Q7XC8X4l5oDT+yTbfs3XK8nLZ7JBHqollO4e7hvuSTPd7IhcBQhVdUBnhT/KjqgDcTrIuo yfvHlXi08++Hn3dpvMbsdx2lzOuqjkT3BRjvEIOSlVOcbFMevImX+nxb2Mx/R3FHa/ps8421FFN3 kv3UeznNOSsA0pxEI0aAgzeP5xaMza3QfvvSHaxW97G2UuQxTR3SjL1S9LFXHewMmVL5MWEdiVKp RaCFoFaKRSXdeiOcbYhFt0XLsX3dvxxBAGFOtFF5zlQOYg6q0aBQdU58zoPRv5zvsROq6Hjo7T/J yFcplHJGr3ECaMRZHnECpXzMO2a8G/rGEk/9Rjkz26BRFlnQNguO1Z8znx/lcsqNlHYuFsiETDse PTk2oIDBf0d+m4nReO2Wu+7kwSjEt7aLRwXLl37bqlHLNpu1nWBX0/dk9M5t122Ndqj/RQb94nH0 D+D82Ku8UtKLkILhg1Xa+9BOMq4nB89O7ZxkJKbM/6vtpgAtHV8QrEn5hfunG7WQJ4bBOLOwXI4h pTWKT/WqIasMEhcpCrDzgYSitGzEaQgHMPCYD8UB+GXwRIG0ebhtyWORFrKsOXTdnjn3e/zzPgnS nQsbiQGuRiG8/wDrgBnAGGASMP8WtX4+7brScbcBfyXtkdi5uBnxqvF4+eN806MT7OYgNsXzqFjE 8kh2/XZF1722pVery/HMwLFKrlT2yvURx/fxtaeOwfBkHN/9EBmuJw021rd7hSq1n4pXRQTI8soh +myWl1N6PGf0ZMbYnrW+k82YncsnUliZ9Y3A9uBj70dUiWr3rdt3/vf63DpDPjwWwzaT3fHgVma9 VsfBAQW5A7pzkle4dxguwOAMBrYqvInBzHLjT4mLTXkeADkmfVav83uE67HXsVfDhy5QK9cD68CD AqUlEwM5+UYUi+0TgWwXab1GOmwR7KoqY6nO6EJgumiKW5bdtxXr/S8RPv3fUyVSxEiglA7gQtmK qk9gBD96WB9l3q8E5uLLyYNEl1RT70hWeLTalwv/e+PO1jf47LpHzZdPF9BkxiSU8sYz02i55DY0 ta0S0A3ES2Ozwx+uzU/NPuJTzbdk3WTA017yUKTDObz6Fds53kQ9uUYHw9vizVXtXy+/XKZnw9sV FpHZDho2urYCN933kRJAtSAcf3/Rck3fn5K3ah9YfgWlPVtMawjCeJwIYZm1d8lDuigwr/gBXr2R DsPWO/+hNjClpLeFDD2Jm1SGeO2d+X5z2/v7LJqf9E8oV92nwiykSSvQ9sjcLXOT3qxrxVR871vK lF19oHp/UYukeiKJ1rpriZvuznSJ0rpeYLQCKwX46zIFGKXGkjjHvyy9NRrN1tC9xE4vr3Btjoe/ DtkuBKEjVbNZAflCKgeTL88abdO54/Klr3Gq3s4FlpWbruCI3hmfmrpQU6axkpnu2vvuusXqmS5T ppX5a5Yt2YrG35ffTb69Xs662jtMLxqBdEG920LV1cIfli7SumyOPc8vPAi3/LPk7jY2iKAMF53H z4WZ+E3ChFEOLNZA5C4Ul43VLrlpSsrtpY1qvlujmor4xnPRN4PJczmv2U3fvGp6rQ3fr3fV1n4t 1djPctUzB7kOwiAeIa25V4EDXykyvlnfBrvOcTO5g0DFZLD49lx/0VFFC0RU2QXQVG3l12unORv6 ciU64QFNukJHs0Rr4f8jkakbN8rbWjgVcXRnN/NFs2UVZIDEIjPR/VypU6CrtJTEXSueiWMG06hp 7aK4/r3SXPwO1NLcXz4GRlF06MF+njyKtiMO0pY1/52zuQFzbsbrUaF3u27PH+q53vwquj7Xt9UH aVkJOtfZW8cKItZJAI3/yWST5TVvar0simhl4a6Fux6GtPxWHRRVvNOWzK4SwdnY4Mh78Hx/Tsm3 AyOUthT1hdhgRlvcxQ68Hwfp6qqs2z2zNssHPLj/IPPVun1NzYC0yiDYMati5s57yAR16pa0jiI8 civZKCEJw0x1/lGimm4tb26ke/KdmITA9AOZtfmgznLu52SeZ9TUXfMJkT0OLW3rNeg9CypRhG7H tckk9d5cjvRtMELEEF+sy8eWdmseWTKhTRUY4HTzopHCpfVN4LpOQX5mp5kXdHbn079U5bvGS4Y6 X0WfM1jdiYiWxIn7EsAldgohM+N6Kcs5HKstXG818KXBT+WoQYz5HCSdKeSYZwZHKQbJbrfVmihp ScQjZ/B6H0mZqtafmNdpSemps1WZiFlW5SADqaYWTxAyZ8IgCuarw3uaTwx2+7pP2F+gzGsUslM5 DpE9NXglsE6odn3iFOipwnFuSPH6JvNcDGD8tdhQC4D2jkHxyspaGPtVUwuEXyX/0NjFYfz9Q6GE uMv+twAmMO07UWXEH4s6YSFxFHaUekQ7X98KWfqIioIRviGeodUo04WmfFJTklHzKAWUmVW0fWfM wX1+NAWSjNWoCR6m/VkWfLs7c7D+I16q95Pvz9I772oDn0sXyOZjFhCyZZELnO7G25persHuc6Cy y9Zv9V7Kvqohzru0XCHNe5te3NrPftP32FQlpdFvvCqffqdakJzBRq0sdMnbV9tXGEOUATRnB+mj A9yyJfQjc96yqSh6y4GLHEdWp12f0iWjCScLC1JCnXBiu4ElNv9UEc9fEH9Xp1M954zHaM0eKFt8 m5KiUWJ9pPUwuPrllSFQC+ok4jTGFW3SLZaRBtRA0KJCp8vsl9dn+aehXoRcvYR5TqhfXpXO1Ta9 iEeb5UnWYDWU3Ca8LQTAbjKBl4/5U18nT51N/WWyqepbC1zG3cp4S+4CKwsfKWb1JX3CDA63we6D 8muxB7yQVl5XOtGDSTc6MR6+WSAhU8Z5x2KmWW69kifr6nEWa1eqLtoOi5GhI+mDwaXvMrBfMIZ/ 2aeRqhD6x2fjfdWN5CjeMkx+rBtSWpO4tQ45rlnoxoXgQpXBOJ4z+92h6ds+5C8jPuSuarBvX1/Q HhX5iqZltuj6WG+Fz0lCJz9gn44pvrB4bF73OEq2sUDQPLYQHGL5TAJnFvL8lcGOE4E5X2fQJibj 2WcK3qyUmKIENwr/jNVe/PwbNffXq4oznw7+IkMU5NwhiKvBHhX83CiIXXADIzk9NS1Tx6t/ybeU fdmz/VwmiF7w8tPjm+e7tocVeG4af1Pn0UxwpRqB9fKS5eHiU++SqHyMe+a3SoJ8M7wrIrLcQ08P gBMRoDPfrPE4TX9uEyn+taxzymWAbOHyPmtA/pDfNNaDq730Qrdjs/smO3rTbyNfoFHsThVCMKPt 4+wh0iT06Y6luTKWXujYeAgmrbzmSuyRykfjEePCtbRTxkiBsPMNAze1k9WTpZl8WB8Xkle1BQch GdO/gbzGSIUdlEGMZ3DDDhDigllayK/1JEAucNK1MA5ZrsI3Gw34boYPG6eWZz0X7chbBI+Tf7Io Z4R+TzvNSIwRxCGu0/1S6iylK2SFv1C/N+NTvL84Wd/lW0pcTz3nW1Cd1dzhW1ed19zj227sdGjd V/FJbV10Ki5tqJ13qh5dtHDeOCm/rGyWdxc5n3LeOCs/r3TZ4L9tchCpOm90FA94I7ItB6+h3/Pr gdFwJzfb9u2VEmvzu/uFz9iVX9nStvFiEY/xT3QBodAMEJ33RRw5rY8ekDlmjYzckhtdh9Rd6HP1 RcxwjuS3UC1pnxivojaq+/Y8B1mwcpjuqp1xFTaGZmlATkAbLNE+EiRSF1DqHftlr/ROeK5JBJQ7 YO9W09grs+Sjlxcr7+ngEWN64cYDyeq3DXCF0s9qUxxXQYNNy499c2up4E4hkYBjn0gBG28WxBtE YJCrj8xMeY9ptrJ7DVgSyg/9Wzpcf6HymO18cdIx7zHyz7tGFCVKPOSn6/jOAad571eoEd60/rZ2 VmfPXZsArIYnnmAu/yiQzuqwYedM62TKWfpBz0UksItrWdBW00P/lqkF3SPWJ+XikA1f7lKaT8xs jZECK+XbB44X5YUj0T2HlqB91PNVptpWCI9PZ2kXhw98kvIqmSxjkhPpaAeYm1YUqpKW3X4F1Ro4 k2vhJVH2xGaa6SS/dyaQ6yutr7unbY5tFgm+cOq7QkxBWI/eWhRd8+veT+LFpvyIP+56+/WI7cCT 7KWGN+9t9e1NFzb+C9V3o6GYK/wrBAgLfugzIdXClRNDlw50DtL9y/tCO7r8ErmGoDZnXJ7JJ/Ji tLo+RyBskrIJ53Xf2v8s4nE5gFajds2v4a1Pc/yy1FhqMMPZ7hnJgrwl9365VaQl9xUJIadru7Jl pCOhP3cHNXbC3q1cbMBFUwMs1omp0YHsThg8Gny31PmnuLUe2Hae0Ep4V9e65ocFWnTj2Zv8k4Oa 9w8laouILzmwicQglwfKrymshVSqWrvgN+dMJI3gZ9oLrK0cO2+pcu0EJEMKUyJzOmJoV2kaLwpr nGt7JQ4rriHro3rS4ADASDKY36z3CoS8lemo3R30i8czFESsh0Ahl+VO6tobgHIKBtrmXkB8ZBxj r51SrI6Rcwfy/3w9oJDbCHLL/orp3B+/13UcGZg9fRg5it3mIIcsjBnlyjOwiSk0A02Ih5SHT59Z ihN5yBvGmMGDmii3E1eFYVw5zXkMhSepjlUpUH0LBO13OcOo4JSgpMmb9oaYVaTBre2cMCPec+yx LztEN8nrrH/QcGNIxzwOvjxL74FpQBFNrc0uffxLaeEzyAZAmS9N/nv0ATyo2TNGM96BLX3C8E3g T3Nxgcri0DTTfz4zyrD3YqP2E07b3/bIJXtqg05YrAs91NwfoUJoiTZNHovKp0RULwKztCt/wWWF y9yIh2irhYazfgIwnVHrHiSKRFmPMHOHktvUL9Rz1aThNVarC/ixQz7TkafT0J1B0hiBqINpzNnn JtNexhFe+ab4E5dZvy/OtqoykeCCwzabkdRDSxhvnOce9lFjnyjwHvTkfNFvIN956sGZFD6FcJt6 6CPLoeMtzwzES1VwHGYgCspEFEh9IZNIOvJJDGuhjObXzgMq3fjCWozJa3ZZkEG4ebNgLmo8t++m GXyx/nJOioPFJtL2qxzgl+fEc3Gm4dDrgKHoR5bMCsd/0QzBbEP/FITuXJ8sZTrX8HfDTq4fhikv M2l1zLTrR/vKS/oe2ljndp0Bl4CT6/YcCQ09x2pPPNJR76JuKb/S7ctHwc2rv1tIpQvZOysD47cS XOLSf9L6S8eO0+p9iC8W6jLkA+cJV1wKwQmc+cca27gW8/ExPTbTizmCQN6sdIAH1B4+Jz57TQYC 2eynm+rpfMJZ4z2fPE8PVhXbQUzNsXsu1ZnDZvyoklUqnx7IeW6eqQgsVbawmhns8SptsagH56tu Ny62nlSdal/pOmdsVjmsaYPNZyMP+Ig3G7Z+WzQKjs846vVGjUyNOr0pvy5wCQse7zc2iqBx39DF 0T5XZjwlwmp85qAWZoCq3hCu5RLVIeduiHEADE0NCnr0wNRXFO/yG2Kva2M3x7tE93T8uoI6r8Fd TcbzjVOkx6zB5T9uO+Ac6GAdULLeIIi9PZtIx1lOxwGCS4aDvZF5pX7HeYILDu5o7Y1vD6+CCLfE HxqBOdvZmpve/owfy5TXfhSiCFuaoqy5c/x703dbrgaO+C/T/Lqbxe/Sx2aty9tRH6Zf3pa+Yf9n GX83evWk79bafG/FxpRvxbt0p6yoqrihuO4tqk6SN+RaZG+4xoRvuPnst6rxa1W0t8oHpubFvb6+ ie/TN3Js0mhyZr0zBIwWPC3B3HX2KRMvn6y1RKB4PkHZxv7jPX3TsBemx2tS5uYivzXXMi9ofVKB 8VP1vaaGFh+pAHOHeosLwFGcY4L8UfITjcya1L+AA33INrVIqpDRhxKI+o0IKnNad+9zAThNu7f7 mXbfck8arvLy6+UxIXreYtc4QWG3fNcqwY6j11Y+gZY4tZu5PPlNEoIdrs3zDZo+RAk1dE4/mHAu 9m08WL+tvqX+V/eaeEuV0DhOJYuOX3OhSnZckLytnLPHw/iReCv06HSIntTadjnukcS5cZwsoim8 jzLuHxV23BPxMT/0IDkiab+zEe8Un8mvdPAR7jtGGm0dLjCFKvkmwTX65nY/Wigy3Y3dze1NzEua TZj9703h3mau1qlRHtbPqoC3+OfTow5oIWAw4PgTawMzyPiS/1Lqssxd3kdfEGaxyF1HsDB7gcWS 3CbXOleiuyDxjNK1XiCZRTm1YGJ2t/OJLUO3hF41iV1ROb8srzc+ar+hjWmkzZcl92cbbE2Akx67 5uRAm0pN1M/TRz0Oe/TW0H/tvG28aX+gsBbmslcKVwp4U9yOhibs9z41Wlc2Gyur0lfEG7yiR7p6 CFCCtxwbzifBZJoxP1ooYQ/Y4nEV2MCE9kGpsj5J1DQF0rDLXC4PdlyE2CA0BYG+XYZB/kAaIBXu ej6qPrqCxd2l3bXAPGAREPaB8xKZtFT1xMT1poO543e2zn9lYu7wPML1sAMpG9NT19XHTUM/6Crg Ku8qrkZipfjuJEY8V311YNBlEynQsbtYnOjTptPmz83TiK+bbHniHooemFcxsNwlnTWZs4AlhbOS XWtp3lLdWcBIb23iB7+najPt9M2H7pgZM0YzfBWpSU/S3is6RQ9rAwBjV+S3dxjYIz0QAMuWEFtx sH5gNUmtlFrayHuwfri+ZvBsc0t6gXxr68WzTjeTeMze2CVq0Md0K+71rXFchHWFI3ODsrWB99Dt VkCLFYvnKyNid9bAAIN5mjuOI8q1wM5nxkXhRRbr1KYJgZLE04K8qAWakwTX8g75HbPzW9fgDpVs jdKVJVGrL1Ur3GcZbtUdPJ9Kp6vvzl/c4DrE6ENdqTqQ+zpRuio7nLJ1BWu7KzvLu5EdEU606cHW tZa1Vg6WNz67WMMruNt5vTzRWvvV7gF6ENWAlTXWT7dGSx+kUI+Lb6I9G/S8DTPj23G9/UgH0ENo esjPgpSCU/8D43T56VVhXCPKRK0ciWzYNJh7pEStYmN+qAlzLKJ6SunfH3Q6OWC5+qpZtxD1DodQ 7j9P7curQHgN3Jsb4du/7uIigSz1tF/MqMihlAVMgdJrsN3rGeJhj/UjTn99YDV0OE96ZtGtSNBt YBTYcsJbEUZrgjvQXIcE1La8BcLdsPcnXkIoQR3bHUGv8yZTqCCWk+COHeB97I7mgsDqZ9MITChi WMtX+pMQ4UE/+ju2KIYnaQJdoVD6oNYbF6flP9x+VYc2XaxN+NZdFq0pn4GMYyOg4fOAppmOzDPT 5fG87WAdAuJaJ+FgnVnMt2CefFS6qpLHB3xb7DPVZRDQosoNOq3zWDunaitXVlOCIfLVLeIHb5PM taElE1e4pdPkyC3P13eJHIr9rmarKQLxau/wtz/dFRjQYJso8qJgP7YUGto+5OogOxZtXYh+PRkP 5zlu46T3ZbGfdq07cAxaa/14HrUwBNW8dpEd8wX+utTpbhlCuPDTZn6iWVxJYYYR6a5Am+60ytax DeWD1PeYNyPcjaBW2mwzV8Za5uM5N9QJg7Vi4cGbzTl5TuxXwb4AG0Czw5Y37Unj6tJq3kv+g+2s tG2vJaDXARHEpMsKv8K/PUpi1m0c07hFyS8uL26nWLclRnhEfb5p1IXEnXs+ubYceqR2zvTMNspj /691swlnzV533E41bYUZt8VniBN0pQsBkf0SZDyQnEzNd0ERbqIOev0lXOV/FzYl77RdJyDtOI2+ SpaPKmbY+x2SIb7sbikffFQ52zUE/erWQNIEwHQOO4y7TC8ehAzMq4/CA2miCDNig9u0HfyRdjM5 q+8OLIaEzgvaZzuot0oni5fNGpdHJr0zbaOZjHPhuVZWCybNdUnmHlo+g1zgcQ64QAll9i3FGbp2 6Uc8ujxrH1hcgnZeYeIb6Zst4hVvLSo3BtZXrVZTcDzdnmB2dJB1GRks4Y5MhuHNVg8VBsIRcot3 U6ptl60Nl2Ezt2qvk27lquFRZgvPnV3mgpCZSyZ47fUI2uJ3B7ce8BxvN/s6xPPbz5yYvbdOv86x ZQI8EXx+CRzIoZweZK2U2GdUy+kbBVb9xHE4PwSuCNwGZ9Fnof91o6x61lJmMhaMkuLuFQEbVDNr Bz7jnVH0jE+nHoC465lqgt0KkbRl8qG59KkJgAKBNnDoQRH3w8R9NeqNxZhnfzeHqyFqNXrkbXYb 3pHk2Eo7jD95A7kz4vnUXrnqjkAdSXVkPUltZCu9rSai0rKdGErOILzXH9tFsKu+syPqPt/eXX3d +99G9u3cW94L7JRdATfHTSryZdIakXqhifaOKreZrS69ieGOLO5zNmoZxPYxDp3U3iP5v49sdDFL uJeR1YzbpRWVdXq1nFjZuq0e2zEC5z2bbqgp4R1wrqiPj+rLpEVQxxkO/RUpX0sJbtagk6gOiUXz hhq43D3cbbVXmRFKEYUPlyVWKv9/1/7B6h/227V/Q+sfTwDjmfdkh5ENTmtK1HQnqOM/vYM4JB1+ lfy3bs8TJxnSx0oOuRTfGxyQdeM/b/9Hh5Puse15n/je0UdKY93r7h9aX3rwEaE4/42Jkf+i3BA6 kLG7/cNlIO0fK+5O7mSixBIN1dK12n9LXFY6XKHc7vT6ojKWvhmmGdgZqhmcGVoKgUdMG/y17UXK mHowXSX/Am6/9DFPkU7pT1VJP2j3mhvc/Wos056nhmXCbxDXNk6iDaaQaISTFqOnCPdMFteCtUPm InyiFa1H9xchvLVdh+HcM5LZKYfA9lmc8rcGvEUp9CdecPWB5d5LD/AYE7biewZlr4G490l1Ohp0 DbxBiEQ4fZ4wE8ie6/AT+pSZSgHDlmDcujusPm7LpaJ2MYErBFLeBUNqjjAybiCyEJxn+idjJmTR cfe6bKYsYMZh393DOVMug1ipM96UO9wQG3PfFw0YjInvMDwcAM6AEvXJob1vR9bpEe8y08wXbP/D eFsG1cH88MI4xQsUd6e4u7uWUtzd3f1gpXhxd+fg7nKQ4u7OwR0O7nCf//vlvR/vTDLZTbK/nUmy mSxoOAObPMED2t6iFToR9OC1QkfNnoj/IP/iUe62qPm+WUf8vmkwfd/44vM+0AD9XggAGlf4S/QW G/GwhSqJ2kXAMEzF//zpJLdyvxJvLsdsx20Ow9pZJZPUfGYDXIi3omfCZ082BUbO0o/ZouqG9hgX V3ksF8uYlM+ypra7ZaFZvhu8G0h2f1DIK8+w1oYUOCzPQyXrKZbAqyHQKWCKFX0R68OWpLpzT1vE T1LFnXn/E7xx2KCZT4YlwsVFpFsQ+G2FM7roK+ppmngv3AJRUzqrqMEScjcCKuC9kAJDF4NA5q7R gjsCXkVsqmEnZKcBYJhUkserzx1zRnbpG4UFxzUCYhCzd4oIPeMbUE4ErLNp/Oy1m4uHesQ04SK9 Irgs0jf5lkhPfhxk7Q11jyUHz4VKmP3lGGmAaiDpBknSBunYmv635zQq6924zFT512KC3Rh2vo/M eujY6yHmP9QQEW0UXRgactdyuibKbgCJvzWxYdEnIRc6nhJODP40ASuhbKyZuJ90GymZz9BZZWZt PczTEFL2AVQhOp/Mz89VAxW0VRmPDKIxpggFXvmc5WlCN+Rc/NtYaQuHIdf3wvp+a65L5vQ5VtVs hhjN0IkVqGp0fIxUNMK3IcljSYhdeD2KsM0dfpzE+TeJ/X5iwjgiFQn3BSIVoqZSnqT5fZ5n5fdS 6Pl8mxGuX/ncNmiO74UnMJO0McYd9h1R1kKOHcb0aHcgv9LrDZmonHxe2FxO1MvMPgKjHDXJb4NL 5FWddEGsbC1KvMqt8g/JJ4Y66zVH8A7fKiX/8JwH96zeqydp5MOX13aoe0jnIzVpLJN73uT3QHuj nGt9Q6VMjkuN09wEduhx63Eb3f9M0mj+8jGryazBnKX9bP5cLG8JISLFiUkmrYmir2SXTjHP2lVC 0mAupVZjiJ0pHeWw6D/tshn7ox3OruRTgmmha4ZYTYe/qm7NwJ0Lt82dTLrF7TCXeVdKSGXFQWRe 6ptNo1ZU8JV59Z7Y0nmOzyGbfYrgtI9BO3gIHjQ8xE+lbYnPcI34zm3u76gPTCy8t4At+dV39VJS ESHmQF8VVf1Lg0azBMyA5U1DRR5dOSZWtXbdUcbQWgECcbGLFzc7COlqwFwwaN5KOBsWkrdSzHXU rqFp61j4bobWq2noacj6BJV9jzqs8NS6qLXl8FRvxmesQNdardTX6Kkwk3CXlKkObqGDYWw8/Wau xUs5ZUnupS6tngMU0PMALBcDMAsD242dP4UnWkpf2TAelTGUJks156lCSW8pjttQ3fLsquiJOMzt Gsh5OfFl9diwRob4REvp/lCo0U51iaMUWWXlZhiqu/3pspX2UPLwv8cN5Wmd9e4SaNc1yLEor50C TtWyVLDU1pTz4FpXPmrqVRJVuN2NW4Sy6SGlu1FYSXpWiPwM+BoQ4qvlBc9BI8M2cWp+X3CKvobS ++Z0DOcR1Dwj6PYWeLFqZTwMH/OphCiGF4QIhgKpBu3lZXxMyAfNQ/FDDUANQ09B68OJbdGD8EEe UIwgONC+Fe11YKt6F7C87PPfrdv5LViL5BWWT+s8eD44RiP0kbJvmueBnTbSF/8+masw8IyB0CzR 4OCnUXgHJVOZdZO2At8Q1dwyNN3TmTzIJlcUlm/4ls57S0pONNgQbBcsOrDXFJH7bTbOJ/vwjH9W GDrv5pFOumHoSVesXliC+RifwUk4Z7Aj8toiQBLTIWAqrp2ywWDGLqS392uhE/2fv6IU/eyYyB3C h6/Kt2bIPRmY12H82drNmCaxZGG+MguG5TuGLr9HWnf9QtB/4g3fNCsUD2iPrJi9+SM3az+Oihlk t/34PPtnZ8/0A3oCaqNec5q75fcp4Wn4jID7xEz71yI+S3giuE9hwxTV7Fdos2qrwHL0gvsQa9Lf 1/CG1pOt31mgmKDvoElfoXrf7IDwn8j344dnOB4zl1oLBSK4b3cVvpMvyNVWS7NG8b2dfG2eUYzQ ykIOWM3Y/1xdqsuVDcRE/gnn1UY/wvJE+tP+Rcv+TN3lPqt7YssnmaG56fzKSAelgoO4bOqsnLvj wa/XxbOsz4p+2LHLGHQE6z4KBSYHfwXLsR/cJ6IIXXGANQD2E5GMZxMFxpL0ZEMMo+grtKSSbUYc pHUmyuj+GlVhh+sYY1pnByWjQT9oeLWeaVqhy6CuIv3vG4SoVzq2Pr71s/YMvhJcE4Jjd7lf1a+Z QYJBXpLmwob/dnVAPrkA/PQscmRX3GdfJGeCc+Oud9Y+LB2osDbGyN2ztl1uPxt5GONf15lCBolj yxldZI3SLShfehhGUVaieVK/waTevDfZvWsUIlZBc8EuwfLA8MC2wLRAC0BvBn1gYJLtCh+E3tyE x/IW4C4tjT/kpi3ubtAbnhU0sx2xVh4ZhtQSfmq0ewl/htXk3T98ai0W6jc5vp9NxGlfKj5MeAwb 1eZixrLedGqk0+nDPsKe5e9Dg6lAANI8ODZvQ5wXlAb21Dyc2pqd0d3mIzOTdyQrsx7RQ6cNOgXD qlMxO9bvdR+DN54u/87yun3aO7/9s1s2kfuL5Tpbk77bbFWYARLYwum13a5hLmwDr18ooEdib213 NmgGEGTzXhOCeE5Nv39cRvY0gD4uhOwUXq4Dd6xUE/Hf6kankED/1TyIAMQP+q9/Bak8nx0FMcZY KMIur2IKDSGsmVdCYUunU9omQbfBsuHVBV1h7FleHT6n9EJnQtlJayO25S0XIdXRsOHu7GCICTKu rjbPN94eT+0JqtC2e+b+aKA6F/oeYhKsINB8uzEVLU/39HoEJZtk6/X3gnh8rB/LLreDtC0k9aic 5CFnxcflaH9K3pqdOYTgrfroNfBE0Qg3YY5Xmme2VVL97iJ+u6j2D/Xco0TLnJN/0glvT+0sr4SI shHiaMlVSNePbfjRItaQ/Xk8cRHFbZjvHzlxdAmD8jC9md1jLZyp8PXJzQ24RkkIbJUhZRSOhqEr vso0EhGVy+Q1huNg9pBhEv8cxsQwB5NLI0Yk8li1+ihv1vcpRhe/pdGqeQq2N5EpxNtl6LdCivfE rNk0M5jtGKQyI1fZGdb2opMsdqS7nHSpF4kJzRceJY4AWNqwno/CUtYe8xktQxHpba/RN7wkRhO8 lYPFQFgFAnM/jiO1IUwOstIFKxZLFgsWK5ade88/3LueBMYLD3w9i08PcPtU9iqFqRlQSNAj2bJf qR1V4CPFfdTHYBLh+L/fD8aG8uDVkV3r5CP28O8jgPA4LlEfqeTOnNwCJxPbPvuY6xwaWs2d6jkm cquEbsIT9s7d7v5lwoH4PvTY8lAf0iQ+TY4DUzvH+tvZ45vDXqglUHBSukQTb9PhMHtfftMAJiMO GilVo81xWz0sz5QaBN6dO4R1crJTspO68Mj5+QPPJFwxjX1cpRsSzLMHjcCu23s9iGaBea8izgDQ e5DLBs0lFsreR+Kr4sx5rViWc51NyPeRzC8z57JMHDfD+UZMVXx55iFbmxkrMhHmZGZAD2gl0RaF aPb3wRd/MfkXjvUkwySR3Ae+d0tdwItDVVLmfG2F2XzZr8b5Kwpm/UBKuneRFnneMlExQ9+AF6r9 MuZi0QKeijvEk9iT6bqhloiTyRPWcowmZadJ8Nw6xzeYX9tvMchSyfLaeZiw1miUx7Tkxwh7VubX Aj1yZCMjSDME0iclBAdsWw6EdvH7g7e+sbcCwtgnbnnmrZZcxRgW+//dKJkjkmii1Btfr1UnCkS4 c7YcLOvkbIk3ANRp5b9yJtqQXmcZx/Tk06hmpvAMfd9WX+LMcO11FVWjJ0oxMlE40EoxskgYE1X/ oIj+1cLwGSHNiMG4bUok4o6qSH10kmWues6WrZdO2FDwQhjHC+V0/UVHOQDPGddZJOg7YoEh6oKp Omv13PqhFmYNzYm81JU8ozzjqqeT3VyL+v2iVD6WHbZdazdUW0ZiunbWGM1S6Wxzh6Xdr9M+B2Dk MpTt4p5Nio3yKaCNs9kBeb1YfL1aPnI5f7i5GqiX1EILdKpAzL9Kqpa3SVknLVmkabHvTGsRjaDm vIDbbakEEpvqWpjK65a8GH5V1KTI32uxgiaZty3IUxQOafLVD6BwCO9AuCxFuJPc9O5WMHbHluMp kCHPWUY0LxJhnfsbnNsqHv19wW+9O+h9pkZaOH0peSlROySgVRhaXqwyHDyWK3P11O7kGl/UfuW8 baJw2bnhpfPbNc+VTEospwGdEqw4xioOx/UdowH/YDnFyIqsqDb3nyyLNEv9ZMI0ZV493EvN6tW7 Ln8N7tfbcfEx1+93vLQD5/j6ODcZrGFrm/lGxHIrE7aC8kx6pay/UC6o42M/4CgzQ/2l9uat5bkI AfNa4glT9HMl3044otz5pTsSKYVDKIWxKN/Zoj+YFSWc2G5k+HyoLqhSfwNIwO+Buf5tsd57+wFI nYy7wuD33q6xJPqRVyx5rOmBT/jzPGxJfGEk1vv2mP/+PNQU8sTyyFTyyIkF/jZXkEc7GTPZuXJ2 1vtTp7WrAZvoWUBUuw06jKqS0erhHllgLzWEj+8su5j/aysR8gRUZ/8twI/9o89O3v/xfSmwrdN6 3kfkA4anBPMKPXtYSyswqHViOC+CTn53TwX8Pi6zHR4ZGmi48HFZpNIvs+oggLbrtbJ6+If8ctUe YWRDv7fdxY0zudp5UamLhwG2ieAyk1cQWpe384TQhhPjHepwElYoUxoLG2rid4iQeKL23yTbrr2y 63WYZevGm+gx1hAP5jHcuksihZgmjABakzT6nqfAWc0+fgnusYdyFuj08i6sKlb4nahT3fgeaKiD 0rOsH06nEl+buxpPBAqcSeLdY081kJZDEmFchSoGoazmoUEnyuE8ypWOQEeTdhvC5eib8THYXmBY FphAjQYeJUOhNOrXPyCWunyFOn39lLpF5U0Ei3qKBEHZXMUdaFxzsXxCbLmSEEm3wKK0Ak1sXBIm mHwW6KqWAbyRJEpOBSmeHh00SeiJumCV85qibdrQohAlhwNi3WDp5Evoem/fTrX2vLCpqRIp5NH1 8765teP/oOibONEdEB4kSa4CedwSXqLyTl6En3WbOmrLa0N7RX+ISrA/2q9k1Nm3TX1z4Qcy2Ysl pyxQru+2UVxOg1pEj6YkEN5QLlnBPidCXqRLT9KXlNqAsM7+fePndaW+TajXlA2VdsH4+dI2L22u R5ZHlnXQ5t5lvfaM6x+H/cM2/vhnlEu8+OEaGcMwoQcq76U1uGld0dKMQI/Lp03b39Px28U3emQ7 K9vvckMfS7J8D9dxzufY/1N8fBn+YDmgb6Ym+DHc/5g5/6yG0rPo0/CnLISOACnLYCC6YH5ykJA0 IAf3JjdiWHPFrU2g8c8j6r7iyix3l/TD15q1JQjuCrH+hdFA5/Rl5A9z6C0DvqTq3BGYLvkZh3sp XPBmMV34EznGtobJlok7YcKMDdw0xaS7p4EBTh+9Bk91pDbTp/YgxgxaZUJYWRZYKVBNKtAuBbd1 5xWgR80p9vnKjRnaYg66pZa9modZMq9qUeNR61Rkgsj86KfU5hO6l4GrXT7vVa37lBn4IJostJhV DXKZRZqV/2mag7ycMbsKhTTr8xNXJg3GCOUron+AO1qTmPXhmfop3R9qazzEAIvZavIiNFt77H/b zHDuMlknhvm8hRnkgh2kYy/HMrM+7wM9y5EJC/Fh1ca80dFQMTgFyF/fcNNgvmBitYYemXVyUnin 1k7f3tGA9EEwoESQxznUOvbOFl/r7JeD/qFhojxHf3SI955CNld/7Fe8ehf4M+2Lofa2lVgUl3qX ijZt6/dvFCyULDQsYWv/EMhnFOPx04KxCqh9XAR/4iropmCnobiWEB1RMgb9iJmIsv6LH6P4e45k 9k3P7/KprqzTJzLKPy5QrY+yEfoWCuWZsP7bz/Fl3w/SlsqdWdQPd5mKPvRA8x/mAHNVc34x6WL2 frIdKaiOkFNX6xTY/L8bRDYldlDlsTO4V3qwoEfdFO+fTBgW1//NB88JttZAGR1MB8x3zPcEtATE fE+Zu88/03W9qvuOQc0EKM/8uJScuJRcuJS8/zfxpDlpIVnDVMFXwf7uIliHW+nfFkT9okqk10+l f8S3SvpcjXaaDk3fyLMP+w163yl9/SdFb1hdX1tB9mkh2imaX8HkFtoSmt8J4Q74DywR+sx7NzTY rzolHaNajnSMUr7S9WanAqbuyzGCdOVboj9AEja5dT8NcJQQLbjWcCwV48Rizsj8eScWpHWOv2Io 0RjO773b7U9BF95u8S7GOuLsiLcPYLBLYCUzwwJy+uNy3Baiblsxh/dhazxVMcE/6cXXbmAiCBYJ qeoiZftkIJoWs2SbbD9CvEZRtCVQRj4TkdfgcTV144c4JmKz2R5FJ42JmEp+7DubvXU2oBKjKJ6k RfZGlHT5WHx5crgazU9DUpRf8lP2/hUv3P9LROKALlJN0kI0pfyzqgpnGqMhQHvs6ue44UaBeVsa xghE+edfffE3S9vQAwIGnSdVpmuWpm3Z7E11Q1r0bunEKWwSyTcd28BMhURQnLQTwuj6+IIdAbPp uDX8zNPEmGZU+URJQ5hCeuujyJ9ELcCPm5Q5svmIInDG1fh4wRsng8qIcWl7K1C/2BXh2YRMVsA+ m88r4uN7SsbgKss7UvKB+ikMzQ0No9R236+biONWoJCShXg+2mgkJf+/kcArrY3aoCRi9CX5OPnp AX8LeROttA8sm5O4yE/c1B3cE/58rfhUd2OC0rLOQIls4Z3Af9QNfLbfC27sqHcERqtKODL5SKiP VIDKcClkA78MxecA4hZiHz9Xvq79OAhED7XG8ON9w/JF4M/+TpyrMUAq1yr+vJ1ANZrY71ZuTpdq 4iNVWd/N9DcNYpT/hnTTTjVXLbbeL0Y2KipnhPgiu3AWV4/6SVVIBCQuvuk1/V5Jxc9alzw5G4GY gDHdPxIoxawsRTejPSrVCSyRyRQn3FV4xkk1UdNWiBx4D3yYEt4qs9383BM88pq4WtadD0jBQRmn WZY2olzWPsDSLVik1Pt7ATAokB5pcUNa/VVNOYorQYNE0URVKLH/q1xfgppiUKGkymPolrTxyuZz it8v73aav3b7zMOz9j0j7z7GSsRswkpomnM43a3mgOLJe7lKXlJt5vzvlCyYQ1yDdkGn8AsTnIwk LTYKC5/TNV6FeRxAoEnadZiZiirN6m/B3t8nCqMZZrMbjv3B34K34KRNHiwMCAqYPYEvGtRNiZQi /ZGUD2QAhvRvAozRdB//KI7f6wr259BAPsAUXKIhrDCdQdySpboCFwQqynXsRWgDB9uaXFrfDL9/ ETWh4UCY7zzmQuwk7x1s95H7i4Srj7zMbTg5I4lak7zhhchJhcG5BoAQQMJCZKy+sDtxDXTC50hn a8DK29h4TOdzUsZXUSQuR6TN3CUI0ZaHDxAVfjKtEKBk7YQWc/9CzrHqO9VOD272Z9CANruFX0Sy d7SYMLPX3zn62NFDi/tqRnNPFvsDdsrWvBbTnkobklIFyfFZeCZC6SnzVXxXwSFlUDyjtPHoAGGA tILnZ6bR9wvzwqkRWuAU971eHbysdA9yb5BeNOp+hjVOhRTNjCLqBXteteEkBzYP7SesDmTUA4MR 8vqnwt6aXS+OiXdyOZTaSvGKWDOTikWyhOsyvJKQNjbhBg52MELNZoi/flTO+otdwhRM/aDa+VF6 Pac35Q1hhnzb4jOBfHPRWGHXGEFKUM4A2xdeXkL427fDVQhHo01Xlf8B8J4I+n6SJqLJ0QZnhOzM jVSS66BcQiOinNoeC2GohNT+jhs6xKUmOJ5GCEeqsDPxKWog8ddnS0Y1IreWoXmDe2JJ/FZ1wJFo bSxOre1pCuFyxmsjfVZiIyKO6xI8qsj32olRI4FOC0mDIenTAbs7RxiLY3iT1QFXXM5MMp6RmUtr u/VPAG8za7qMYHRHU/0lTqdoXmTNMY9gPLhYfYZRQvFGdMxRXV3eIOaEo5Bh+AGCY/MQYD5Grngg poCRiZug1UHwKFjbvbRAFDXHaKBUM/z0zyMBQBoj5IhIafFGybxyUEUOBYPmxBUBu5lViOlsBDu3 y+dNfzxzv+por9sTwW6URDYFads0/jXHFp2V2qs1pHb2OyZpHADn574oMmEuNG0wms7RIIhIG/Me jjHkKqtxSdGeiOWTR/X7ZYFBUxfRZAp3sUCfrh20d3/NoPnEDxxl+Jl1eAuPI/WEe9vyzjSEQyTK VcrMAuaRVvJpycRwaoxR3E3Zn0sdBULinAiVSdEfnvtLa57n+4VU3V7idJNrsnR4udEH+gnldvrj nhBCxgs7z6ZdsjL+5Tmht6L8bIufTMWzWjXN0964oTrQaUtMs1xe2LZMezqDK7ijOAS5MpNHusWs jZb4CHmMey4H3Se1p4YZAdwkyb1f8hcc8mNa4n1J/LVPtfuQ3S7tFhYTSzMJUZ43SED61Mtwkjap 475bVZbLCpWQn5nSnaZHVVwPMO1VW24Wm3Y/GRxwEgQNZkYHLL3cO8ZzpW9/K9FFkoSGlpcYHDBx 3R5boPijt4WRHgX5rJxPfWGdFRijtIotvGcLILF8o5sRMnEYQxZa2PyL/anfmJivsQRZ57frHFG2 4/TmrFlI8+/tkaJu8TovHo2pVFy+8CK4Qa3iLkf2xFdieBo05qeWlxvDeTNd+sySNp3C02c8hmRP RnIw5Ppm2n2TR821vMptuumay0C6bPay1R1eY2x41HxCFt9zSRqHZ4ZTNupXvF2UIH3/C0cGE/4l 07dZ0lJKxvGQBnpq00jm8k7cSjidyFnQEog/3zcPpgPDQOCE0YPIVM859v8CSTHqnWLvCtfAkgwF DRphXvrNUr+cxalLOeR4aGT3z7pVIF2JVeyLkVH7NHvPcxPoqsoWIyntbpmKU5kbEym6Do/jfTVL llFPtixbdgRPzqlVWjthfYfg710BuCKTNWIglkKnJaK5NYr0SR0G7yUS3ZjftQSSOVU99SYvWKgH we0hp4Rv3M4oAhogGrk58P93dN9qhwhkA4YX501acgBr18F260uUsSd6gk2dRdJVzqDZiORxqaZN hxqpJSQIIOgQdCyiwwqH/fGAalxDZmypfP0rBtN7rSUDL1MH7nRSIZNc6Z5oS7P9TpAD2L+zX+oW 4fLcKyQSbGAsuYQU1yccj5PMgIGLosnqiucYfqgXsnzFkm+JqwR/FBIKWgPr5VfpepCTQSssajxv 920jkuHYVXks3udZcwt9cjpcHi5jjG/yfxamWUMExbF3FPtyBpmNvsKrwNaE7OEXLCY4DSAgZF+3 aYEDqT6mB1opP3F7iPyRkhVKVt6BbHt4GN+y8V4ZIg17wiudMeLtkLLsJj4ZTC33X4ByZgTtG52x v63IDQW8MTe+HAb5V1O9WKpXkXEZKfpghJj14YLhLntRQI8TBvluTbl9DiE7SSGGVOKIqIzOfDcl IQl08JLHgnKFx1JjMj5bIR/8uoLB43AG+y9wxCg7sHKexs9fuvj1Q/8lFA8M54vCTJSxkimV3HNk Pg6gBC/dwB7Pn9JSPoctrcn1yNwwv3l4m9xFhxSJI3aNaEzAhpNnQFuaXYjEJ4S/Bj9UJIFy5EpD hUG2xrgraPuEA6EEkSR62DWOJHJ2C38Duasld7JOeOG30M33L7W07SLMs41h3NQjnqMeoBM63eo/ v3naUjrFvqlOBcALIvZ9l4P0WrJkK2ZnKZ2Na1srnhEykS/fg1HABqB5Y1R+zF+QoMECcezwKT5n poRVtVzMMMP7KAV/hf2z/z8Ct/ZsQsTPv/pGkkIo7kioafutsHcaIy9WseqXQiByOnY63k/ZzbQb J7+nOMTxAiYZ1v4BnqASSe784LaIa/p25eZ2zGbIoA85Jf6fQlLsy3cLopCzDFrV7sQw398B5Hef UjvTJZ4YY9QRpsN7wrYPQYxlTIeXflfqIc4RNu8ZKZ/9fLJ8UQ5uhSVoV0xB4ZXimJqibfSEEwIR f++Lz5ksCUEyprAUWkPc1/diwc0trM0cSVkMb5U5Un3xDQNghKjFsxlltrt5/yWRL723qGou8UDD jT/zdc71OGMB27D9yW5j8BZ76IfPQVbKxjN31goQ/iQNpesLh9v81vf1mL4O8+YHODwE+f1rIpvA pdpI9cdA0xKUYOhegtF/dUUAl7u7QQF5dkaModSB6iXZwicON0dORxGB+SNud4v21cea402guiRe XyYRURRqOBMbOiuEwvmbAAkIQW4tpNWkWkCbdLQ6v3sLro41cckYVQnGLhRoHMCVh2g0uGYSX4lu 596T70HyxlctDWYNjZt/Ed6YWqYVdzgK40dehs8qaidCWQcRxWtJTOlMlYGN6+CfeJ2pBIr47QQS lbwtnih0q/3R/Wur/JX0Pahq4NKCY8WWpMfGar9k0p/KdEWa87whulfg6Kcc1VQRLWNVitb77p81 1SE2mHo9o/9gleZI0di1oT4P2XSEUDT1wKQOrYWDEbbM7/eq0m6HR6ZgRtkeWobrZ1Cr6BK/+DX9 lJ65ROnI1/lteI5HmzfyRHV+0mTwSbf+Tvi6mxrSATRegdWi/Ix8lLI7v11542kwxXOnHS/fEH5o pwlAg5p36NV+yl7i9BSNwGiE27TQHwdwpY3njjT7Dfk+BSMbc/zQVeG44Z7oh5dZwUFyjbsmykvX 7DZgy4aeSjGo44wlxTPrJX1nkdou8yLLoqqG94myc5TIWtVxOqyAVwwiAl2D5dhwRx73rPoy5FJB w3ut9hAYFVLv1uMbeHM+74Yc0UiDT4kXg5HzkXYyBCqyIcdZ3RXWTlg2xRnvuQfKRIPgD0DFKsB+ rZz0z6HEk0SN3L6qv6s+10Dr+jsK7ksQa8i6AxfCdW/8yvEQ0zoB8VDznpupDdotRyYBK0IgDMrV +ibNS+wFJwETtdsivxQYSihvQKfaoWml/ItrcfyO2j5T3BGqb0eTL2L9huL572mzz6/CIqPlpSi4 lA+FafBUQmmQJUTcITYqBKrzzO7L/maJHrjeAHOHuWWhTrtD/mmdPgg1kWiMM+dyYo0uEcoDwcjM DCYVa/SUfQ0NwVYsf/dQCql4w9dRpheBMGpsMhFkdBjFUIKmGmk3pCsUdFP+GHj/QlHam+F126GV EfdWrCLfiNbyeZB0l5ZyGBlY2U76iRUsp8vZ9yWRBixpqBOK4y2qBy2P443EtE9p8718KpiuCv3t y9LLqlencQxvb3RfovaIJAA1m6DLK5V7CHqLowz5lNp+ClXTsbCRQjuuObnsa5UTI8LKr65JQiru OqqVVK9H2GP2mGZ8syyp3lVjdeod1H07AhPCGxrtqcYtkCtnHcKIwOR36TPiOmgrZcncGtYxEsTn zhvzURPmYu1PPoP45bLh07vEUGqiKxzQcJHPFyYmrZ0V3j2W5YbpKdZt9YVB9Er9R9w7XnAlxs6F jQOsSnCjITcnDU8t6NO8O+qgIoZu1fVVJjchUCKuDISlf8LgPtTParwD807aYARP/oz7rgExe+g4 fw0wIN9DLbxEIog7X9qU6d+U1/4heUvnbgnqnFmmPLNS6aFWKPNArb7I6DRowh3qdxlP+JyYj3SD XPIchnWG9n25YcbNCFOEDEB0wDZEt76FMUZthsgiZns6ua/tVjPyfa1ExwGkicVgvYh689i+r53M Ztik/hazeoXsEfKzxJHbtPO+ZN1Msg145q27TXBklB/TCYLnBRuOnjXtUUjZgtAATMCs65THybXe f03nsIGVfI0qZtuODp9C5N5z6PaP8Z2ybp7k1jfz4X30RpE+dKpIMJoT1JZl3FdCO0akbi0T6u4q CyYlq7d5hwCIzF7e7OAotjrdToahpNkOvDuhDXAl6WAyGciPZ05GJ3Ba7Mx55W8A1YLgo3uwUHr/ pd4FJq8KT3DqLb9n1K+QcYu+nky931WdLWF66SZsGuPuHofbnOaJfpk76jrwd2AUedmWLfySxI2Q AMr1KGmfs414ANpomhxW3x+5sSCMdfpFLdRP9FECiB8X5/5oeuSA+xBnJmAeWHJy58jWvykeV/rI eWz+hZBkp+T6gss59DhLlz3TDf41qBluM2z/nMA57tCwyMETexqM0Ods4d7zmw7ZN5p7lhJfR/Z3 8u6aIPufzZVA7XUXDgaHRiVfJ+UzXfsP1E+CwF84A+gAb9hnWX3pqMUj38BFHivZW43QGGdWz//S DF7kCNn5E9PCWf3KbxfcXbv6Ks225m4ZyKW/7zW7XNuiq/saTFcyPAyOrX9mbHwgEeAuGR6ZX+GX 6KWKyA5d8Y/p2Sp5ZBW/YRHCq5qy5xELxOvKjKUcn+W3vQiaLowcvpPim3Xsyhw8j97nod7PbyUW Ic4KACOBNXU/QTo518/VYC395eh9ReTEU7AqhOVUTEAIjjXEwnXmBMNwuN/SbtgSVyilsabfyk3T zo/1a4zSEKGHSKLDsFklV+Y0OT9GGSGRkyKj1+8vXjTvLKl4pxWDbhqXmo/sRhqRWxVSfho3lzo+ P6TjNmi6mbwZvTkCLiz3s0C3K0Yga9GmjTVo3nmtQC6iRJd50Dn5x3wGyeiZiylFQSVEYho5bgmW 5MUCR7WcZ3WQ1yMzRdscE1cAq7JkRzH0hRwfmXLbuN/57rmGdYM3wkFcZR1fkU7w93bsG4svkHGj yNevG+LsVBjQ2eXiHHf6juAGGYU4cw5gDyhS9w/Mx9BWTs7w7NBSlY668dRlGZcLcs6pTyFj4LFm RDjQTz/2N+CNYMofB91hleaGX7yH2QZ2B0BELEL6CiGFfVnftpTxIKVFYHY2ovORxiI3yMmNpsQd Sg3uuexN1cbkv7+38fl+VP6EbdDyVE/QfT+lnfESWZosQ4Bylv0BT/DO1G1wz6RPlBB4NgRNaD3T 9vgU/U+JS0f9TesnJKa7ouZ2uQkWmbvO0OeRuL44xUqzYWcx7yfNJ0PdeZA5k5Ek6QGah4Y3t+8J wrQMJ4Zd7MWX+tTgKV1q/U4BU+6EbzKBhDxxtxeOg39XDTvlspWcYa+aVcxMGKsrz5lG/CA/vdjw 5D9BdKbMOOPV53oeU91EdnigwxV9aFEo3BaATC9l4vVKxmB7ng7GymqxB45gQ+JxnPQH9s1j26nJ 0voSejXLCqm83vgFExwptmA4DaHkK9xkDMonwfs33c8gAG6RrSSrA3hJkXvWZth6epVxl9CKolaS lQaZAWVuje9YdZ+7vsvwpygV/oe0Llot0z20vI0gFtHtDXeIGnyV0x4Z6R5jWIM247gXCh3cJpFN NZIKs7eM/9TWkrQIhr6psBnmqHddvQO8GigDzMDltRtsyeN44Q1CMWaF4GfS2O+Tj1ra5wUfnc8T nW84FRHmYPR1Z/tFnNkieiKyusYaFTWij6tQiaKj1xGgXSlnb/w5lLNDc7/+nH4yjyOhW8lrvNlR 9UYPIDG3VBnXmfXtp9oHpsGXcnrlFHNLxN5U3NC8+RzWEy9z/1HdlFW/E0+qONB5NdlPOx+pjaNu hGtdYV9XOvJJGFcDnqxk/8CdTuJjv6/jcNHLsNXUYYirZjOmsp01P+cqFflZtCBPXR16jp0j0fIX qePdPkAyF4MU4dGk0QKAFopsSDQ5G+PZM/nd3zusLC1WbKtOsLF9i+xc49ZBPg7ynTM3YeehP/Lh cSXuDnxy59e1WQlUh8SKhWTi6Va4T2fndqvbXsm6Nmhofmb3hGo8Qgf4HZSLrwrLoqoW/XMsm0gF VmS3u30b6fWoQAZKaeinqIcd0FFFMzxXcxvhaNCoJzKYAlJZlUuk/+nIAYiowH9vkhk9ORvWise2 iwuFiZtsNJQ2ZzofQwcWvJ2R+Uiy4adg0+5GSVeMqk95neVUmkn9vcDxwVQLr2BZ2HCMSU2/vlCZ +jIBGECKcJNXiwCsoXedU14wA0ZXqlmmJPK+Thvy8GzY6MB3gpxHr8RAM4p/nHavF4pBkb0Dx1d1 kCs2GF1BpF5JUdBuRYOC2r262uIvi3KmReV71VXb34SVtMAT29LMSlzG185stYt0SZrz2cbt2rDC m9aLAyPCcmJiq0w7tuHfD1HbQfLaA96SSJ2he5h+TJpTpIo1HEcZZsClh3Qh0Jr8lv0Lx0PSI4Jo HnKNRA/dLgrlR0eSmUxAnP/oV5sJlc+BwDQVjMQIZA330/bqAQP1KNuqS/UL9dLTCl+gOINsrCp2 7JHron2zGLMq46Lufc3LzwtNxMW002SB2puF2sOlHdklBt4GphsZc5Lhg4R7Yi2prcM2jhteN/+B Oi++HsxVkIuPOdUwToIXf02M/a+//I48osy8a1cu/lQNYXs3I5p/GSmv3PQJnkHWrHH+1gBdk6bW /9ly/rOh/2cjc9EnWLVp0pLyzMjTJLyI4/8PcvI/SIz/ILuJtWQeCC5SPuNk942s8auHPtOEbpC0 ephubMAZ78FW6HC5/Pjeh5zz0w0jR8GBPV/eXOkh4zsgVlmYOGI0oRsLcIJZsOxfRFL+YNkeZCFX DsgIEERl9N+exHufSMiVFjLSGiw7hUDKj+e97w9OuPqIlLUE+pziNL+J3o+EgajwYOP0kYVuAsAJ 48GyNeCELhCVKBymGzdkIi7YCoAsdMuJ6cYMmWYNDgSgvbkKQxQB4ASYM0w1a4gcl7kwlkeVbGGN NzVhC2mk7VlCuZUwVqx2nFTREtWsxCdaXFetJ/D9NOJ6RMdDxwCFv+C3dci9HNesL/WpXpwUyn8c /Z9zdJRs4b//YP5VyxbS/Cdp/pPy/wEQDf7H/61L/tON8pgW8upMSynqTUuNyw1KqVUFFlrAfiaj vKmJQMYnXUtmF0CsODC96qhvv75DFC3O0j5bZKeGhX/RQOQWQVSLMHHqGEK/qCByykKJuN7FmuCE tWBZRyQhLBShX4hxC2hCrnbgBN9g2VNE0nZmiBys0BwbRK4IRBULG8eFRFn6Xy7WI9Mtg60yEXPl MYTcwu9j3mJNCHi98q0mc0Bakvt77G68cqoa6hNPlSW2tR1PeZkK25S+Tk86gYEgyydE4wwZTzZj zrdpVLuwrSPorJ1AaOxuSeisvm2iiirbyj+WIhzqVosD6veYp6rci6LEVydyXWVF17k9MY/uTFvz 194qdLvCAfd6Kh/8A5dRLWwNt//DQLSzMMeDeYiTcecQKVS7xgwgIZs9eYroiYw7VvKX2h6SdecR KYy+xjSIijt+fYpgGZY1dxVVF1RfZzJWECyZ9K1LVIv0q9dpx6kZZjD+ndibefS+aZ+xGOeX5ppN ZuKwW+WQ3Rzd2GmS2Qufab8UlcJ/y2FlsBMj1BQodlshFe22mk0xy6G2eXcVUHKY7jHp2mwYYHpz RJfEDzge+mlbLlNuWK5TrizX44VO58jeYhjkENv4GGg2Nfxn8s/F30ZhlxbeqYc+c41TwbwvXj8I s6XXy1yq3108oQ4Jr3BU5afEp+IThE5G6HMljxq3TzaOR9It+cnol62nXEXi9F4op9D/re7wCWJZ ye6dj/MJ4loNm2A2Ov7QBFo+2Fauq6sNV6Fl4ykHCh7fS1tlzfrOsjPCW+U+P1MV32ZfyAhM82O2 3muAoyNuk5Psdi2Cb6Nm9XeZ1JCmXK3aGU6r3LfU/2UvThFq9OucvU1WPRloDsnT2u7XEo521GpD 0iyMONBqBWuJsuxies7s3XkYnu32/3ImbX9L6yVicLG+FFBopGL3WMrYm1C1yGmf0teYWlkpHrvN 2p58nrxy/4ApPxO+VHYxbwV3uF/RtiHdEI/d11txbTh1N9RIAUYYrzTiMf90AJc3Gx19WjP15qsv ljyc3Og6kjZGL9W9Ml+TX5sE5wOmAvpyjljcjVyM3Iy8tp212pw6nNqdOok2HzcwNuI2Ni9FHoNe w/wWhHcADvY5Xr1urO1pHtw5pU7Lk/ckHWGOQL2zlo4cx1pOD6tNDa/lbvdAYW2MxYF7+ne693LS WrpTed+o3Iqyk5OX7zmVeYuc90zCetOzbvdC3WKsS4p3HN2/amfP7rbvBH2TtipaT3J847bKHs+m 700ClPIWrO58AuSPTvLuWDtAbt0Racc491F+NN2/DG1qs9sv1WtDtGYrzzWuK3y4u7hqW/BuHe9P /dC6aQ3drtBrw5Ynz3bu7//Q1SjoJ7UteflPq0Cin2jeiN7nAD69iUb/ag+XIfNvAoCA3oTtBZVH vWeHd7+3v4DU7X9Xh4+Q16cbLUZDj6IaJv6xzoNJIXWPSoZh7/bSjHBdR2Y1stM2j2TPs877lKMf znTlEa/pr+lRhFcqmmEbw5vDGiGveI+sDLMBcwG/ni15cjXDNgksEaLT/xuVcbg5b0MYDnuOe8qj OlnbWYFYl+OX4xXFGcBl9cSM6uVFNMuhrZ+8mTp6BQoZGX5qNFmrfoqb5pYQB421iV0ZjaGJfT+G fxOHiBVVnQObBWPtZJ1klTeWlo9Adc5ORHV4zgGj8ijL1LgKBctSlXTbh+bX5o7V96V3TQ2X6fYj dQ3O222g7aX0Y2HFJeAKUGubTl9eapspJ6dm0wF0rLA9sezIqKie9+jokN4GXqmzY5Mwa5BgU1Rr GGzKtKq2ZsrZlJ1mWNvUnmZFjKq3ZpSfVBGmj5xUEGYen9QQZnw5LSE8A3Tk2RYiZpAoqwlLYai2 nhHnFGWeJPgW29YMH7MzbEotF52iY5vsLebQjtFW4NLO0QJTaddKyzVpd0srlmhPS4GdSvvKWg5K d8Ila5lfJjQulL6JVF7yJPCpWaRbZ5dcsmPy6zXzqvLLerAl8Gt5cM3yq2zaUboHj3GpdmhvWlF6 RI5xzHYoeXBgdv7y4FHtlNmsXT5troiWqn0JjdxWPoXGHtDT4MUeXl/oTdfeAnZkeW8VfVib+uad Fogu5lXkvnC+Z5xa7L7WnTqYvqWfmu2+FZ9W9s5ulwNeskXKXs6iXwoJ82uPGW3zP1Q/yxEynj6l 0ZbgO8QssoScF0Np8ShtI0bDpbgX9qVUuSf2pV3u40djExmG92W/c290jnbKx0LGfC0WB2i1GCoS aNUYKtlp9SrKRTNigKVDmVXAgo/zUacmYduGshZCKw760iE/j+4O2xCt6coy2kx723LSW0K/2EXq 2oxlJeWHuW537n+d851qwo4cVVmZtg1V4S/Ry8NnRaU+/IZ/fSmvJwd5F+8GFyMrF5MinWh6SnI5 Vo/Ky5QRfBmWzU1CfIfMTTHvq0aHsGz/jI4QLSolpZQsugH4e7MzD7TuGCuOlP9oqjYqp2qqsaYr VRccptsrqwXemwGUJu/Pnu8XogGSvQWZVg2twEwnDj4DZojeC/OiIoCoN1b32OqJwDZh9Pivbf3o KdN9w+g5yylO0ubmQiXtgF85De34a/nym33SmaJyS57WwCayowfv4ZJbbZtK23TbdGegx1Fn9IbW 5uKlwCOJFzaOW1rn8uYV4JLUM66TbtNJqVuotrJTy93DYD5Awur4r4Ci1+ymO8amLMbMqm86aYHs Wb1vAUCadXH8ngFb0eks88WgWzqwXHSuc/P90Psn2ZzsPdJ7s0gl6/H4S0VP6a3w8G0XXG3da+wU xNGZ0deiy/6KJ8dC26s2bdkoT07/Kvy9/Or13xu16KrKtdr7GMDhU7M3eHvQ6bIVcnVz9SD4lAGw 6q3c3rw6eLwNT7ebLCj9bqsbYXv4c1K/Qie9ogSoRZrCIFES9QuIrArEKlePVKfOi1JPj1L/HaWe HKUeE6WeHaUeEqWeGJUsJd0RHOVOhQP8hvM9I8odGwfIhQNEbaYP01VP1VX/q6ueK5CkkAMUywHK 5QClcoBKOe0ZAmphAmopAmqxAmo5AmqhAmpJAkkyOUBp+HJl+LYw5K9FMAsFMAslMBsK8OWy8OUq 8NZi8NZy8NZS8NZK8NYS8NYK8G05yDMxyDPZyPE/4NtCkZ3pcPLhcfJpcPJxcPK5ccAsDGJEDGJ6 DGKCDKBN9SBUBpCwetCDehC6etBf2sfxSr/RA6WGJ5EGvuiJC6lDT1q3Kzq3zvjqQHK9zsRqjPjq zZGlQAq9zqTqQGo9v/hq4dElw31LJ9dGjPbVtI1zWccHOl7E+CzY0Unx/UNjV86sDf/4DWIJR3Qa 3vCELIyELP7e8Um9Db1PE8dL98e2vI68jA0hGcdMfGTXxqFAft7lM0LfIoBKYL7XcdymyuR10Afl yKTTvdeL33voh47Ro0TuA/I/t8aQ0cm+fUt418a80UmP/7CW7p1uiV4n3wTflwCCve+fB4f/o+F2 AmR+htnz2s5K+EOWDpnuypbGTuFqluvs3wGNFSYPqpafhx/Gpj6Fr0V98pfTCGUdvfj+Y1kVxAGd vGvGbk4xfYJd9Qh6b4i4NaY7dEz6A/212k8ouKR9/Xl1ECum9Pe8x3Jr0NC/1Se+rK9W2Hvn9XxZ 36ySTM7L3xn737u2qUvXiLUUjJafx9g9+s6xlR0gyVankiFRmV2Xw1fdLXtIv3A0MBj/YXll2PNY dVgFmhn6eL6SZeXVpG+uq95Fte0pXWbx+LlPN0gmk4SZOn3lsCJNEqa4oi889+5l75y1uEEd1DH2 +nsqZjo7SPl5ORkWI7+lrKFuM9R50ncbknNu4fXv8b1sv5asv+dv43wvu1Oy9edAN7uTvTfV0W3p aNtY+34q0iMGxhcM1K2NsKrUXxb7TtXUFBoWpDHKTJwzjOpmClnfRXHRpbPhscfduQunftCr07Fr jsxzR7f9sKk2Fe7+nWlIT5y5AkIKw9vA6+RNfRCUH+t33VNTV/s4y/cF7tiWj2kGLH65/bS8Marq v4oJS0qdzm0smKioTnuVtXurO1l7fh6P8xd16RskIhqm/aM4SCuwjNv2Y8QlquJxAVs56wdzT+3q 4tZRXMkw8rAsIXIWO1qlGqfmpptgGLaipj27+woVP+wrBn6CbrXX/YJALCG3XLeV8VV2wUD4A1HC mqn1VN2ax9i/X1U3aIHbHFxlRxHBkuELwK+MrBeOo/uBdtPEAu5SpyQYcfhsXFbgCFnTAwUcxwVy zbIfTEvklh/Lzeo7HfUCHk7V2G9PvWyFkQVRvV6KcoxepuXlHDdwVqb0xYZuPD285+5J4xfj6lmf b8eX9Y0oRn43h6IfyZ/6Q4Uez6wsSg48D1thgQZP7nEdoY+bq0cJKOMylyMC7s8bG9+/q0znLTjd I4YO31W419nPs0b/yRXmPHtXbn6ZzODMH0PxIypzuNk+/XXQvbRNzWXHx3jRbBubmu30upJDR4cT YPXDsyx3nPZvAFC2WpVgu6euVCWJn0TtVIqRbjLwIsvKljavJ8DzqpjUwH372YLIXORjrxLPSoAs 9dldrUyz8pMDoLZ3q8O5ztr7cZqOKNtklNBlp1lgi7Pw3i6MwON9dImVUJqDQvpk4dL7+5gxT+nY //Nfs3LHNp+J+tPMoldaXCBL4MHwHnqPrkCZ3nwcj34USwW+3oXy1n9hUx8dHSZehvsoRFI0xTb8 q6xt3aXD8y2XjY5n5/n6H+mK4PkuKNsn5TKAy2ZRWAXn3P/7USDgg/YjCd/LAj1PMKnteZRxmm75 0zGg/OaoKMroZKno8s0nUjDrxKpUpLvo+gQ5jXVTlOqiGt7L4crjennak9tm7r55vQHhUAtQ9/zX QLF3wSxuyefm4fnfHzRful6p8P3grMDN9V3z6xogydTDy3xUCa9D7Sr4UPfqIQA42JQV/WB4Z6Y5 No3jSdy1o3DYQMF8KlOjwnQ/v/zeiLLt57H3mLHOA7gFnC8vCISVpgbU+J74oSd7GH4A3ly8JmF9 nEg3AZ9hPQ6tFpbVBnuajKrxfpBfdyeyy6KffWdocz9i+ZvNF0YTUBa2xCe3X/dbbIav6OuLP/I5 QtGXRetFafxt5SshDzWtPMSuKgo7hmdYuD8+78Q0b5fIytx9LVZ2sGLJ8q4hb1qiOsYVEnErUrwD mmG/12rxROfq89ejBXk/NdXGPpxwYJMe0c4yPzOQfy5/CxXwmIy7D2REiPspHotZWzx/0iNAY/bv INx69PerHzoZm7PcJ2Zplmk9JWVMcoz5w8UteIYiAECk3R/IU6dQj+xpXBK4vVXmdBrw30tj11QT bGnby9MM84h7ewb3VjkuWst3W3igv/u7vbcU8Xz+Amy1aGIYbCy/THyc6CFamT+M+fWt+k4fOTQ6 ATeqrko3U5ZoWnR4L3eKqnlYAjrkhjEca3x8+njDGFO2vWQP7LoNV9zUKtOsmhg/+4crnYBtzQbV 9ZK9bQX6SSexUdwCHfW+hr20zRIeKDeVLT4H1ecze26Bz+sVW3u0HxsOfb/lk/J0fXzeJ6T9CHvm XFyBFXGtooSdFY7Tr5CjdbouwYPOc5napRovD+ULHKTAy/uJY4CbFQarkMW/g8fa4p7NgsGkbq/S ANXWRWW8LRveSvnh10Svx9dl20kh4tPmzz2zCe0G2ZLz15VeziWKfnLVh/KfnggDxvEBZGt8AqnW TLP1jHSvHInmJL8TmRV/FDBFRn3rJVDJWTjRP4rbvhUymDZyC7i88Jt+BAQaPr73WCnBRI/vCjAt NBbF7AkX9DJuoODSZgpUlhAlUg/sC5n9nbuzEl4YDhW+zs+adEmyzANCoCP8MerU8slhTOAeZmYS eLnok1MzXwJhcZiS+RvUVB0k86G4n2HBBd/YJB8k+eSEuj/IqxYvUmY1B1CxHTKEHMKXoWBLMuFh KMowAVqn52y0bfua6T3HWVsykvqX39mzfxvBf6iNXu/f5mPfGtTyDc9ipLtJavaVt9TwzXUQAGmy rHfu18Q75YiaktcSrtM7UyleydVuklS3OK5nDv75b88NIpmHrHG3ylhMiL05FKgk3UpavxR77y5x lYsD7gNGEM4MCY4ZrxeMmjdMtrjHItWalHJ4aoQHvyh7HfX/yfwD91zDu1BFIe6EWNpEG9paWqbY uqUsYlkBQjfIYa/QnEJLABTz0E4b18JN/XXH7oBMrVHUvynB3kReHCSxh+9vVRiOR5pOCHsBJSoO h5w2aYreFr2CQ+vfiJWwYkvtMtWsgjMq2dw3hM8bF0MSt74wkwVacpiFjMTUf07gCxLWj+RgY21e CoUk8t9iN2bCEFtw2Hz9widhKB4MQxzk/0Ye7pr8NSLmI24i1kaWz/xE4gc+QRbA5sc77+RngrBU 3hhK48Zq/UWbrp6drTR3f9ldPqqLQd9NCF/jPxqDFE9G+lALE2W8ZC5vITA9T8uuz2PxuP0WXfZK LcuqCssvO1iHK8EzQQ3vY6amWPQZdgd1Undm3MOt37pDU6JsxTg/GbwXGWn0qhepoJjxfdm/NNof IZ/iaBVfjArI22pj+mvQuyfJd1nc7rxznqLbXvwaxg+BNTMaZvXDVrWyvGFI11RxjFIS3iPLnuTL esvK5mLaSDwrJqKS8FtdHThr5jAh0E912Tvh1tU8HMg+tgr+00Gs5pFG9mLypYQ8pGlJL2mN0+7I o/DIQoKayN4Xfa1vLFHVj7TNxkGLwnHzG172iijvU4bwmdj+OlnjkR0uyv2rAjGdowjeE3gyq6f2 EyRj9/Ev52DPpMBcmD/BhsqzrY8KbgfuQfaN76L5O9oTuW0QQ9CE6pgqaLx911kbR0cHkQyDYCKN O9kF0j9iujmb/EunKi6tKA92SgvXQgY3F7X9y8wrh+RN+z5bPgx9YCQ0m+HpbRA0NLQo4cyo1bJc 2xWWbbgI/bUIYuFwDOsh4AUb1azLNivXKV6udoGzBKz0bF/402l+v86DPEuwE0k0RTJn2q8jo+Un duR7nex74zLNC18Gwkp30iAeUwSRJEa6uZOgvNmP4wi9p0F8EgLnvdkmVuSmH96bpM71RKhJo/Z0 ciK1SfmBHfEP5z4zKY1V15a8uWuE8Pq3LcxNErRoqecHoVPby98J7dmBnQaCHwn2KsvOPmbr1LnE FPQXZKbIzDa9xEx/G3Cy1mMS9i/C3enupNmFvwsFz0GI0r0J6/xn13JoptjrG3pKewb/6YuVaW97 LL2d06Dbpd2i9GqrNdLOWiDf/h/G2wG8sqbbFo5t27Ztp+OkY9u2bdtWp2Pbdjrp2LZ27L/f73vf 7/zn3Hue5861a69RVXPMOWvsWqueXT4tF7RSJ47r7lPH3prXbHINmXyaLF2mcIH5isdevV2IeHD8 axQv1hEwvGpY13laDEW0GwWkI2w3+pbgi0QuBvRnf099xU/JwSG9YPp68CtZVFUmI/a2ZCL0xmUW RrU0UCjjlEaLSNNSESvp4yg33n1OpzM5A24lebk+SAtqjEduKZyhVMlTvyfy+urJuKlmgeb8NGeZ 7fxdexc7l9uFQ8hRbPloCGzWo8reEaoqh7wAK3pIZCJO+rAd8AHKwxO95AwuH8qMXCERut7StFoA Q/M9lHH6aUx6GD7EUm3qV3wK53RJ9AFnFJ0AtiyWdmW/A76xB7OH4IyzdCurD/qdFUdW65zsk1S6 w0p0gnzFtBBChnxjYlHnaiGIz/DF6Kn3KsW9cWwvu43r8K/eSmE8m6wlTksbOOrUb44yd76nxp7B DtCCPrkWN0qyVwQQSjyHE9wXFSSkEWfbUjo6wErM3BzuR/ymmqcZnNdG6wSCjDUzKl4/PW0aPN7T UJcNzIon7YR8TRORj0OjQXUL7mxhyzM1BEKbtlBjMp7D+PWcwyTnzw5k4G4iY0PSS39m/WgJ/2J8 3PGpR3D7wnj0wYZ+It2Z95X5nnVECPxNOubp0jS2wl2+6Cyuupft56zGiIA4s+VQG9sw+reYOHUa gL5MAmwiN6cpng2kPv+QALKoT+SRALpy/8M5W65GifwDqQ2m5HS71+SLpDnhz6Io67jv8Wu6gCtv tFeulTs702VsIksnF0TnPJGWiFxDVhBKbLHkC1Cawyk2jzzyF6HhrvuyS4f+t/NdUvEMcdun19uK bkK99GHmMq4L4Rs9JrLEAZgUv3UezguA8HIB4aAKEs8c2JbeQ4xW7GBzUf6yoTSEvGcTjPiaJnOh 1Cw9AtVtQr1QqtejFZC7kYxE2SEbDxo/5ibkYxKSjWKSyu0LE9gNWWo3q8B9lK/IoXCsq8Jwa4CR q7EUpxVEZEpd7OlNLozT+AeBiuBojG8ZKhFjrVghahLeJxjrI6bDJ6r9SCofp727xam3s9v9WUU2 uz/V7o90EbYLdpbLCL3v6bjcEL0wlfJOOXuscRX2zCeI4TWMb+y6Vow+PrCxrgKMR3zquo142suN 398tr+XCFoL2GnxxSDGQGL5oYkgltn0uTieGNi9OHiPGb/YNSg9apzVdMLpqJL0lsj6qTUUrxYlS MdTsNhDWkYnD0wlExeSJQB2aOOiXBj3IqXvlj9K7pF6RvqplEWcLKsAfhpro7I+cUSRyHlsiqgIt RKWFrdVzZVAbmKtG3Dl+IujeaqC0z/RsTb+SpXnST2yr19OTU6WbyDQC0Y9OLlZRag9bjOREyT3S HSfPk3oiK6rYOe8WQV997cmhoce8S4T45xR+obrFpIZ93oWeCNBEjYJcFh0j7nrczCLgGUCRXhMk YI8hmiCKBLL1Nlv533oKAn0HQHN4yEQ4gmoPwPNq0RxNauTSTvYcDZHeK55eaqE2alyJmyjL5YEP Dh1aqdZ8Ts8HzWRty4G1dZ3MGV79bg/qiCZIzUDq19rsz1ikpZNrwkS/7obJHl07MdHHJ3oQkLPI 66H9hdow5wl7y1VTs16oWp+vslPzFWIlAZ5unyb07mB6qHc3aR2CQfkBl0HV/0gSbcXbueDZHdbT YIFe7PSmgtr3zpdkfjSQrWRyANHZZzoKBYkjdZYNx/SNQ4Ozxw+Xb6+pUJD5W+xbM8jZuNQEXvhq 6Ek1HlEdNFVw+/43S4ISEqt866bMCuRoBtkpblpdTVRZ8oQJ0Cm572E+TddQ3cGSwnaKROBlRSAk +35FMm8jvH7ddzORZMB4/jWcMTDyMvCbL6g44uD5mMl5ODNtb1m5fNm1yKA52Cu6nYhIr2vIIJTW Uy8Z7tO3J1D+lYGrcaNzFyetb79/A0Xr6mLtegXYIbgPESdQjEGGQKwG8gm9E6kkoI6F0vEhOl04 i7KJPNtzftchWpocHkU4xxn7wp8jUvpOZLjyjevIjpMKJV/kK6FQb/a87NDEf4BI9efOpWWXLrTt ez3Lp+/DiuOvn4XOh0+itlrhhPAVLHgZ01r7SCyPtMe/rz2IbQlkxnA0YwIJPfyBg+eM3L7zR8w2 fUu06XYBKuzP71VN+Ekcaja7J+UlUBsZvzBmiMH5CgV/sK7ip0FSJzVU0A6HbK4jcoJgtMDpy1Wk S2G1I2hFuGmwxrJI0xtix4mVvsrgO43Z2dCkw/Erl3qqE/oshUv7c/xrZqkAE7DEJqJaKFrF3NzX eFWmIn1z2+ga4kPKKFwPxzuoPsvTIPOCWE33oScFGyX/vOJeWRwZdxv3dfrieW18txcNRDwscCKB loEYAeLsq4uO44GWkagj9qSPefjkPceZFvTYSOVsAzSzuWb8/MqLhP6S6b8ktEt3MI0O3YcMJIIQ 9z0g/yX6fn7e7KcNCLbZe5VNsbxpSmrnWLynjyR1lJiP8QDK1AfjAz0a4Xo0opxufGamfrRt9VIm ffJxk+hNaVoWtmzm5950Utwa1AESrnzDbryrtqgN4La+xKSZ5KhEwdqrnP9I2cWuwT+xV9BafhbH ya6wVt0xN7wOiyE5T0W7Mo5RyS30I9F6sGTwnhlcrnlT5+wbXxScE7Sf0itznbx5y1n8ngOGV956 uLlPbjiWNC0ytivdvs87xDjM8vLIxSCJmOXc68xCz7JCZ7vgurcZC88vRwDNturRTn+yXwYRuXDC GvRVF9pL1Dvk6PLdEyZ6qcqbtM2tutp5XMQOi06kGmhSRBNvncbTQIOxvU3z0kBXS/s5O4yp91DK dTdzCreQ38cXpJFTXgw8jKmdibOLk6mh7b+gvZEVPAwzCzMbERPRv7A2Eas2EQsn119Nl4iImV37 H8T5H8StTcTOzvEHsf4Z4+Dg/Av9GeNkYfmD2Nn+GWPn0ibiZmP7gzi4/sX4d2Ni+g/+K89/8L/Y nH95/vH40yPiYmX9L9a/8nH9qYb1r9G/PP7h/sH/zszN+i/uXxWy/RWGjftfZXP+Uy0zJ/e/6X/a X10uFu1/Z9Ul+m9asP+XFn8lYfpfr/999n+b+SPM/8L4e56Z+f8S57+i/SPH/x/9y++PXP/c/4ds f0b/h2T/Y7l/efwL8/ExSljauJg6MUrYGLqYipka25uYMsqa2pm7WPyJzCEgAA/zz9bxyNFN6P82 xIQUdu0ZxX1FkNbkjRSiPIdeGK5a/wpkyVINzAu9cD/X6o4yCYNAxvTyZf/M+jrP73qAesKJ0DIK Vkw52haSSj8QkEypqr7TJeetbseb/aOp76OFLIcXJ9gKZ+6ahCGSk4uvjWlH6VTdbSyPgstHz+v0 jX3EPicR5ftP2/5dquAaip4MbGHMi9/cv3zX5AfeuQVaIhwYfD9wRyDCZdgwVudCflaUaFnklWqF Hnye8rLHPE46uAluRb7pLD4Nd/eaM/hfY0zUTCWVXxSAjSPz7drKMQ/JHt6BwmXZc/xvTwrn/5Nc rKwc3Mx/d5j/7EcmFiam/67fhS+0D5r441fl2RV38vhBT8ApE1nIBhgUMAn2WD/yFZgcEhkxtAkR GTFkeEcQJQ7y/lkHLcFJUMTEBJkwxw4wQWclSRXMuVdwVA0sRP8w7nyvOntyxq8Cw9Cv0UP97aLe h7PFysZKfXXKTWAooBCSccXkXEHDnM3XW5ICCHQiwIjjKnf7JW+cK1D7hQoQ4LDNUuXOHoqfC13q 1jCg8xo7XdD54nXamp2oXA044zr7e4LgJ3D0NnWVA27A7XrFy3hF/sf5lq/Go7VNqYfWUklQhrqE ubFvBqIlprkCQ06L065jABVmwBd+abSMldqWkgpEyRcO3YJyR5Ne98n+yq6Q8hpQyt4LOywG5oVW DoRJAOjCG0bK70UhLKz6nliNfFfhw6gXRgXCLhApLawAP2Xx1b3DdPmTTnQDKY4+833aCZkJPUHX xUqNp9SqD5jvGiPjbrKNn3A/NHR6u7ZNJ3KBmpCIPB6LAGs0SVI4AbKMfe9+qYul5LOx/hCj3krY Qjv1w+ST1j4Cvyc1PuGn1Cu/YaTbcz30kVvoI+5YV1fUVC6/9ueu9J5r+MnZek4/+/TiEDmqAW1S GDjXPk+7bTrVOdboj2CGOYAy2fzwdcOM/nJ66oru9X66B1kQ/nAXWuXqh495KOYtE0o7Tbze+nAL OyUSCyToKI5dxeoFQ5982RHuhxlnQpV0Y2+RYU7/xplEodhXUKUSJiSIMr6vOV/JlA+BhWa1NJ6i TJqKGCgNqpF3aIdZYOCUFqWcglNzcd0WAvcrnoIegagTwS80mkpidVwCpmFmQZMHhGef51UBBU4Q SFPugPDMD36OH6RxRn3TCf/7J+fhCWmCb80biYMbkT+poD0Z0f+0m2iDd2UFqBNX2aWHn0OX/JWu gok8iHMz7qAgfxsmCVkCVDCJdMgeB5Psy+8u3B4OCwOgYDecGAMxjkDoVTgzE8Ib4UdwfRNYc8E6 Iu3+qIt4HxiQPv03BBBiIG4okMRg7nChhEf6EBEoJ6xjByjxuACmAykoyavBdkYxq20hwZNgm+Ce MRrAMhL4R8JbMPwqAg0AKEIkLuxzTR0J1O0gkAmIO+2OKGKpJ4QrQjguXOMAbCaSSeoNJIkIgRt7 L1GFCNiTiYykXAQFgCQlQQBDveZvgHXMhhXDh6ecuGAIBYCaITWkAlBhlfkiYCeE+SAf/2LC40ad T8Rn+sYLbMwVHwp3yWXSL05lPmhxgDfTnhD56rgjRIBonEBJ5A+BakjnRGBCrBCEdzCeEM0Xevcd K5wPfoRUIRx6jTmjn5uQwupSEchzjNUQBTDMpPmGxhBIPRbKhN4OVUY8u+dDLSuZB/8y5lwA9MIy 42xY5gYWtYtygEIlljfajhbV5C+KPSXCEC6TeDxocwCeQ2uA0IDKIKoHNTwWzaUuAg0wygjXAS9d o1ScboeYaPLvR6GSrAl9GXPNOS8EaQfOGZMxRAawzEwWKr9hqfUZHUwWwrzAzKiLsAPsCyTeoGqC yMdoC9V44SoLEF6sfkj2QOAk1IaWji079hCkWRIOwNfhebJXCfUk3sk5gDuR6lT4AnEO2icsO/SA 14jowdI2P+2qaYRuDL1wtEG8tDpUu0ERJtdI9gTfXe9AHPAasgOuExEHCLm2wTmJa4MlDjp3zQ68 DeAB3TnXwdpNTwb8G1E+gmzEggHvDO/IdqJbQL3iW1Ct1td9wTmc/fhjiP25Y9m7T2OIzn5gnwHv VBul3fDaBviAfC5BCHdS+1DvRF0HQifWYwyN2m7oagdBAMczKWC/DtiT91hwUOKAw0PRG9Stj+Ig Nyc/IDwhP2R6TKF/cExhkHSsc0fpMr8Ot4VIENRfxC/tzvkm45GHD1G72b9Pvy/0Xd1C4hO3iagX qHqMcYDjIH3H8YC/Dv/F9LnRDehRBBcgsBL47j5T2yd/oL4LbSvYBaFAcn3sA5Q3rxfs38dwsGzI CRDk7gWeJeqFnrWqHdC+wQOs52wH9hL1wvqL+yF+lnWDQHITBmEmbIenJwgG8I8ROgnAMZL6g3k3 9w6O1imsQ34F9ZL6D7xs38AAkD1U12ElDQUB5Tnru0AA5mdIgPkND8BxhnInfyx/MHvsK7C1KX2X 7Jhxx/aAcRffFtEH/NqKsX/5hgDA6YD0os0V8o7fFe8TdWf5DNQOKiC2tMPU+JUPOKV5OlXaKH86 Fti8Olzo3RP4oL0/BU1E5aJ0mt1KVlDYEeBPfLsnu1pIbk4+WcAuLzQXjBTwZWK5O6WcnSiPFyMY zHy5RzW/OaVsUxDs932FvlqId873y3m7398oJ7xuVhAc8X1l/jPomL814+vF+3R6uVHe6vyfjiDg VLJdQXDC91Xpj5NTvl/I2z3pH+auwAfU06nkn6ADvq/If6ZyUPN7Et7uQzfKGfcEupPe7oe7b06b N8qXHfP1tq3z/V4Yb07/YD/8p9PlPwUE35wOlOeD5veEv93zb5Rf7wr4Ij6dercpbA/6vhJcLTy9 I77c2/uxC3yQPZ1Stit8zX6h5m+9+Xb8xfv6OlpAdMj3C3i7B/3DPRbwFXw6fWtX2P6T6POPYLVO /759qgv4Ev6Z+RN11PdV4E9Ux/ye6643F6F42JHaaQnQt124r7zAxzNJ7pG8xa3ecN7rbUmp407g vy0QFk5AYr999cnTf9B768m3+7wy4G8TovSRo9goGYdJ9m5NZ3mowngT+Iekz/7uM6371rP1cfW7 1by5n7b0vUHvg2+oR0Ho37ZzYdD8XOdL6M9b6/4mIDNrda3/FeWb/3fkvlq4Twz9jRLqY69t962v taznGtH/EJEsmv8mMh5qeqtldysf+24/Vb4jLoL9bX7DUI+texRy7n8q+spbFNCj9p2VOEYw2qb8 +6xwcIOChemTy8r7Smv5EwX8oerxc2NwrvFX+6Cnf6DiP6lARE2kkN6S39/jG+/tGNHnG9dmaV3D BAHuV0SPvv+cKubhPYbEfy21OwVzqXHtLJVnkPCF1x3pv8RoDMbBHvm8k/tUlbh+9E3krwTtUj7K i53Bn3kLJ/3P4YRV9BrS6Ev4RVPs7l0hwF85/F9aqcee+Pn2gVH8FUBg4HK5kWeF9nDhX9V+OYj9 V7U5usNyWYj/ikDtPXumWPsb+7Pt7n96Kcfg+/QvTxxsXZYaealJepS+e3Hw/Ld6Ra104DT6BrZn zjcl2xz5K7v133gHCd0F3LmuGZFgoP5tOgZSMnhgfjuYY38ivaF4q3n3PmL+JWHwyhP03z45+BJl ZAHoVe+VMX+yKXupVepV9OnPl2/tdPlzkfzzYwQS0/Kjc1oGvsczv33mMEt6zZ5Z/FW6Srxz+NaD 6t+VCxWgemKWijKB3QmObHTGOzCeaV5+rOk/M54vzu7/93CC3mwhIhb6FNreqiSd5q5J6mdw/hsv G/1ePbhIf1tbH5O3MoKYkBhasvcT80hJ3qJol3KL/lJl/uh/V0vTj+A+UAA0409KZsC/F/kw6fVw B8WzDQ/1jxQeCXyShER8umHUKWMiCYZ8dcufcELCkB+GRLIjG1rsOgsBl5cdpc2IvIOF3vwPLqC/ hNOTFGE0thHhbhLQKR6u4sdL7qsIjlOzVit/+iG35IdecmfLjWaASB6dRLNIxOIlCviszBFXBKsk JaOg7u1DDCPERBIYXBOWrr0+XKJiIxNg4KDgoWHt2D80Pr9myEkE65WPoZAnJBjP0qvpMg8zcI8I +PmQyKzLKCrNyyldKCulntvuK0e3Z57ZngpNvgjWubTR4+umDf00E5IwCsoyVtf1bry0ws1k70Y6 1G64FP9ZmTuZ3E43ehPCSFFUVBeShaqWWN0hVZ+1P6Gr9StDJSf2gT1bTvOxyknFCIQte4oqS8kp dM06S/rEYgAcJ4u1ITOoH9P7MKrO/Lht4HK1CpaBmqe8ZIrd1stQ3s3k+3clo6Bok9S14/Y+gaVD zFk5omjO/XnT9vsu7MXxMFDOymnoTtzlJk1DPccuhczuKhO3QhkaaiPb51HjztWauUnEcN/8oQnQ Bhh199nYFBzngRwaGQ6OGjXdJwXGizzc4bYfUOd9DWw8rW3MmNl6g2bMdNi8Ax2zYXsE39v5wy2j MH8yFPtWdRc5GjLnJURIYE5pIC+iIO+uFOIHReA11xfMERxOxDRhppo8WSIEjWDTag3iW7W5yxuJ NC5u82dPYwjG7+yv61JdT+yjcJorb8XUnJJVST5Ct8HpWFVE8VM37QvNY6eWixpb8mQRR0GlOaXu Wjp0xGgOxy4lys5OdKZYVOravoPcNK2vCz4spXiwdVicY/aJtXB1YGAduU/UPHuo6+BpY77S8SWu jP7i46djNrTElWtc1lCNcXg10CLGoMXJjHEmQB+eOZu2RcgIh17+eRp61QRzR6Ldl4inf1A0TGfu bi5/I5vW+JO1vNKjHj/9msMPGbITjln3672KOJAbnVSX7ICyYXLzxfPlseu0EWYxZ8RoduMI3aN0 4+VU15NgHD1DlUpcOV6MlDwvmtbRLZ1ZBu217cDivXyftr1Kzr6vdIxdbNpVM3q0s30MDX1xUsR2 zVEtSnIb885lgZ1li5d/gvZykT9fApqXbnSuK0gzNpaitkvnnjc2tt2NvbW+rb5ETpt9tkbrMpb3 JPi+fyQrZ2+Gda3ssot7PrWzDApSSVhiz6qUqWVV3i5n64KI82iWZsMQXNGejsqmMMQMPZ7eiiDA M5T3+32TjkxnE11pA9oBss4p/e++RhJ3LiC1W51MWo+OpligZWweV7Bv6z+0zQ95xEiEnIUnUO+R p1znpulJw7jWTo7UrB1oorXv6V4cKhWEziaYP11QbYaNMQnyd4lFYQDf+Y72iA1v5ehbWd7k6J09 f/OYep3RYChk5UwsxN1erRycx8WSbjpOIJm11rObc8vY28jhn8qPwruVQ4oZ36l1IL89Y5sLHpjw sdxqRIbHxNrbwF+dM5jBGQ1zNEmIlb1eFuHOGYGmrfd1tvUbDlwEVHRUeL2uZuweUC215N19m3Hm NneSP7o4Hucf0Druir5TmxnPYeVWONSZzlxPdoPLN+KK2oXi3oMKAAPhMBrWTozlQokYlHBDImVu hWveXJKYitsVtZW2SqNHjyc+49IGGeHgq4nAtZcZIqVhWOfIMeg2IPNQCFR87E0Bf8bFszWZzOdV e8vTu4Qd4UhaReEc5xiRkhiQz2RPDxvl4TtIa9NaX9DQOpTWcb3/hbHuHml7sIex3trCAWpZ72ts XTyEbPG25rbymHoJvY7ZEtmCuU/QfClU6UrfwqGdHaP2NNr8SxLfryXblrXOOdx20ja1hSbVXFXC 8IBp/Vv9XFWbZouIi/3KBFpqK8tM2KJN66GBmZsOLvG6LcK6XAtxZJcFDW3HJseKmrVMw+0RysY0 vNMTfZr4ui1off1nVyreuqx+ca2jxwLva9n0a5nca1nlvZzxvVzxvZzla5nhaxmar0pDD7XeNlq1 /VklIgsYVhVEdP+oAQsWHE+wTQEEE1izZTjerQ0iVkljgxQla1q7TWnMqhtyeTQKaGjkDkwKwELv UyPpeE0XxvPu+3L6yyOHkch24cooiroQwQF6DLxz6ehx82kzds3urSfDR5MMbDa0pnaIFmY3MuN0 0AAHysz3ZckG7zsEvsrd5W2UcaPLV+2oKCITSzMNsz6LL+T2VX7F+vD9XkmNLkxAWfVKoHl7nap9 p1T8uI8sR70JqkzYg+tmZrr+iVeJfSJtKrTWdhHf8uXL2cUA/gFzAzmlN+QLanQUjLsU9EF9DrYs I7kJJvrhbsWuW9sFobFbfD3UJVytKEVjsOzg+YY8hR0vb+ug6XELrFL/zOUF8c90XUEApRnmKEkT LD/YR5tu75zo5kWW+5pzQ/bl40yHm1N27lWHDvbGkJloMhUuZ7/M8IicTYhT8sa1HAo/hbQuhXQX eaSPvbHz+vPPXI6eqtJnvUIfGx+fuOTqVMvQaQgs7RB3BoJwDWuJu7srXIHX/rHcmywXtCmPO47d q1kbQtjMTMPbJbikqjvHU8XS0WDN+CiYThqncjgT1tZH4eZaSlpH2T2stNDKdFPNFY75ZHS3xR8/ xnJNGikno6z8bYq1Bc/P/xz2aftTV6/qx8LBlDXhfOo6fnm0qPZZ016+CFdVDdGK6fMVrNnOa02b dqYoNKwZykkdcJ0uEsWjSObGb7/BWBYlwowxo/bO62hXFJ+wq2r3YzB/NKAOvNRDkxxgQYHOfYaO UtJdOViNauhJNj8CfwAxLo/yh+MqDDBogFbXQYuyakTGKPDQ7pjBzfYhW4QIDtia4P7uP6xDPqQc U2mCMOungQrF8UBQjijpBtHe4RzCzM8B2RFfgcUctF2rJkOaQkLQVITlLcEs8bcalWKoEHFHhl5l Am2RGd2BJ1mITmEqlZcBA4+5UV+RoTTs/SDGChsEywBprFdANNT/ArFP1iCX4Y2YNUIYG01T79Na AWJM1Lbkti3ALcVMyVzjgdfuz4JDAm3fEavk0YA4d8DLR0aFJptNiC9hesmLm+Xt+cWxNwY5oIgF yj0XUOxJ8NiXfYPsI2eW9MKWhyHF3kDCOCfSZLty3JMQNWNLIgA+E2LUhqK2F7MJO+0S3FS2/xJX Owf8DQulfnnQkCzOH2NmUc8j+jnZAUUOIumWLJ9r/OOA92c56cmiC+nHN+USDTjLeYhTx1Pd0wIX EQJGxnTBpcxmDXqFyrk06/Nm3bU3rnKOiFBpjWObNrhvDt8nd6zaMOyGGl0Rw7wN+fkiFDptAzB5 LsKDbwR8EPSRYaXJi6UgMhVoxp3uReOTBZN7k5dP8LREvqSevrlZYrT8eQSjbDyzdCh7l4DxT/Gt ebJ4Hy0xqsXfsh8r3HDMF8KcCWJZs6BCFePo9RFb+3VX9orr0HWw3AbWbxDecc1nIvq/BUlRYQtB JIolyc6PsbHkTpHASvFrCtcQW0ujtkdviOqUoHvfsb3Aekb7iMQlzzqaOWRVZL4q4V4qoFqQyBWp nIB0ZHH8or93fCULUz8BfoXwzfYTU5izJ/OnhhL1p5bAYZRLMZNZnHeyDHVJvaeaOSY4TaDbf7lL Nj4Ee+F5EfasfHd/+fEea6S2RNNK668ooCwwHzjzs1OKU0698C23Ru6pTG9eYXl2Wb9Uv6JXohf/ 2s9tEMOiv7IYW3IN3oWDD+htfOGGYJUM/JfkONsrUnuyRgmTBtmmnJ4qYIciS1jXhAU+8VM0LakU iY5fVn5AeiUue45TqusdqZ0wb4jWEl5XLH3S7wDlxfCFrSJdP5ncC4vjl3EVvm7CO1JLC9p1bfS4 RQpGn1FbPEQ/wcaiLqLMjmabgnmJnMeWfSgWD0FYIvTFxtzsDpUe/icZKsaeq1OWjeLZKeiB0ynq GShm8sI9EXbp70GfrmJ9Oa1TNEtE7hj1reQ2PYAUOL7wUb/lc8Z7oo+s+YCJF71NAiYV5FgnWZ6s Eo3DR6CPVBbRdHngfSThB5kprc0grSGjbJJewOpBq8fDdektU6DaYPe8ysF2XawONWMCTV36ZIVs zbC1IWzTt31T1phQ23kOjyybND3K2zpVPfmfY5daM6fcN6F2ye8Zv6tKxn2b0nm2iBGT1Jty78Hg lvWSzNzoiJ7Gdj109SLV7elnErAJhgFPBaMrYBApRbdeOtHn7Fi+2ci1AJ17neQdFgC3HvPyHl1p okaGyNsgCY9E7VkQ0D3oLnKs7rgqU0QXub3EVx3qEycXFzhonDwiaja1J4h9DM/cwi59wZgtmWU2 GAU/KgElkt0cNV1+kFiDVmy6QCxnFSOrvLlsfd5Uhg8PKItSS54ITg7KIeEhYWxIJw1X6bdOBW60 Z4Tvnpxv0jr4yuivdkf4xzxFNkMStklyaQuOw4r47N8aQjp1ReMQyGB4kuclPveh+lNJ6ZmP5sjH Oyo62nmkMe1wPI01+Fr4zQG7C+GgEmSt+/RspKtr8iASz5Axc+eQ5QncziSnSKz4AmJfSq5H66uQ AjH+3Hm/v/lKiYyilsu7V212YrLFgslUo5wrwGW8B570i5k1lu+ribjMSQA++fyIvrD3iCIobZal TCpSIW4+GR1NuAyKRazRisbEKL7RkZNppwWZaCpDiUNknlT4ZItlWdBRQZJRY5jbdxIMuKbrjXr5 ezQ8MJmMmAc8uEh0PdQ149ddk0b4C51ELKaVeBxyLh3vf7QbgeHOoqBEBCdGXLC6bDOV//4G0vNc tI/ldabJJbhtlD9wYiJ59AqVRAG/jMhZpjl6OortXI0KElUiA0pTOtywUDd28uehVYPkAq0kVQOr immT7tjqZd7ZDeAEQZAQq4nnwhLOdmWrLHDIhiYZSOW4TFYj3C7E6t2LqHtGbNaY9g2D4E1IMYgG G8IDggC9amVh/XNp1K52Zz+4gdnZfDSJ0mOoPpW04KLxmdi2DjKMR4m4egUL3942a0z5qfn7yxgo OjgISVloaNzEYgQr2S5MaKcC+fv4RbhOQVE8A1VRfYAEBYOgiQrVAZv6yyT0inzQSyRX5K+imHBo O+A/wcIiDOCgoWDwRePQq2MZwaPl1w6CGIG+f0ybJVNjwEkUj1tYkMLH015ERrUkKiHQMnzSDsT0 94/U1a2jFw8HvaUsCd+KeuLhTRtLhg3z/E6y0bPfskr7OU07DTmdxM1Nwhok0WUyIK9jyJZtz/nz W7JItCM51S4yhrNDxiIeDkZWZ6j9fDV2WzPsqKV0XiPZJ2CfjI77E/CErS2o79TuOpNkvlIVWjx/ NrN+Kc+U7HBu2MJ4QVH3YDSMHhwCk+OF0WretjxjRU5NgDl9VsJEgM2k1gG7MmdVefhyPCuVkJcn P78Q7dBOn6nCGwIHDQcthysfhuRtoFUgr3ChPCWUq5clrqyw8WvZ41d1it+v+uvMzrBUsxnujy2V VkjswcE8Fbe8rOehNF55Geue6VJGP/GwjdedCub5tMpWvsaD78heAd8uUV/Edar9PAi3ukBfrcK1 qj9FQVecV3V0TCSkzRPfwmTk8zm2LzF8I8h/XBN183vkHKJEM1ChXfcplYXsRMvdyU1IJVlNQM2Q GsuhBrsa+vkJmDkn/IIksZXozh9GMyk2206nDxVg1P44elV927ymfGtOBF4vrvqJUjxyQfSrj3/s 4JF6ibEdN3DKTWf8MvNCdtfm/eiln5rJHEF+KOf52SK323+qrhDYUlRZFNSRR0pRaizh967lYNjI ypv2D5Put93t3rbPxkN/ev2eauNtUXxqaFhKPSW3QVdTYwzu0Vprbo8dTZajT12X363tBxVnqqzq /IBLVWvJrXce77kpCUifCj6c4/2SfZhil+Bbt0FbCc1j3L3O8RvOl21AaxJD2EhRsGzxvuOkI+ov 7fcfIW8wgrxILldDGhZzmbY8/LHkPL0aTEpW93e0YJA12kwoRnB1QTDUF60MagXDHq3e4HHF1iOl YCpK3vXoT1xIHeaQ40AteqxQDD2zxzta2Y0lHNH8P4D14IWVMvtqIIrJ2VDxeoj5FrOwJvbT/IAz fd70QkpX12IFdzXHr8DPBdZY1/lh0RwqtPKOBbzGE/qIX9k4qr1ypHPJTHvd/fdivP+cSLkZOQJP ociNBxmctRo8Ds5foPiX+JisiHDzCy5tDfDXhOhxCcAdbPiL5zFJwsL+ldon5a2nFT2xegsw3GJW xedavxAD1ivEeaaO5uagLGmnibUzne3ZddfG7IwpFQjzklTyPhyR9eSTqy+XFvRnLJ8Q8QOfUOp6 xryk567PXF53Pahj4rYxN7+WUL5KQQ/9Lzcf+659yiQuDTpDEvMc4K9meAd3nTFPfjTCzOZyS6V/ zobLkUQQBUH9H18OnyBf1URvh5pg/ppj4ZOshryyA8adLbHHxzKSfR9lvH0iMyiMpnvUFMbSLKA8 2xG1ZKB8DXCGJeOktFSY3ib498TZ/A0Ebm6LxgFoGseJsXNSeU9jPffIPKXnvleGgGWCzIAiMi8T GJ5D4Hg64az5k0TTGyU3bxPww2kCTUiMQ9P4qnBu3QcsItnx2zGJMaUtwFiPSdnMyNZNOrnNZJH+ YaJpxNyys+buqytB5umyk+bokWTvNOl+zgmns+bsA6O3Sdn2tCnosv9ZYuYnUnps3ov75NX/UzNv qFhfkdscsZPwTTCnM/tdmVf/XLBllcDfAOd7r++8GvTnFfowxgKGHdRmY/qAG+ZlUrWNNHkoVJO/ l5jpR5ce3DFtqNjKDXf0iE6QuTp75AS1rL//Z4Y6fVCTP8ybj2XJ2GFWm6x1+ygxs9t769XNutW+ 1c22K8+XIHPxji4d8sZL4HGsKq+1DW/0XuJmTNY/aTKyisA4RHLEKwaDArdjurdw/R23I3ZyzlZH YPPCt2P1zYWXUSD3+NBQkRhdXQimpPg7ELpi3K3JjzAavjND8N8OchhlVkpmOkFelK1SAznMipHC odg/tAMOzwvjyieYGSTPS8dMLbghTCnTTFvk7VSCJPlra+FsMYx1YKMV1eHvvqJ76rQqPWKvnFiZ D4fQrHVDfVK+eUxsOqFbJXvC09R2Bj2phirLshvY8V/TN8q/KiFKeMWGxroAp1UcfKgbgthXoNzJ vGRLVm111AggDL4qE8GXalSlr/42kscndOaHA/xs95bbPkftvk92zPPjEwXXVebILzb1scMw8KJp Yc1PN2mP7PpaZJpldVfxkAe3WrE4IwJ2XXjuWgTgUQqav4zB+0BsGqsYMsX0PSTDiPs8fvdjUDfY 6FsOeMtpm33x2Vr2qqmUYNh/xdnaiqphLS4qS3uq2HKW//nc7lwu4yHH3vUw/I7nnnfo2RU3g654 im2uqs64Qc7zprQ+3RKWH85y4UhtP8hPOOnRuxpzzwfhnrWaZmQN7yMx8ax6O5hpQE7Tjhb9GMxk RuuXV77Nv6z7ADvy6Xtpqnvck1Z7POO86rl5zxZ0tZzk3ivhyitpQ3ZV//vukadWSq3Xu8r0h+aI pN50LSBfC5pcz7x7w9n08+bVpFEr3g2+i+z8cr5m8aImXFOtaFihurAkfPF3SopLc0GRTq6Orqpu b1GZzvTPmuqKGvoKdzV18gpjGtpF7Blw9AfXsxhAB2Ct9NBU2tgqlzz1Z6M8vdK5tczEBGb6bwbl yuP8eoxFzdIl460pGnNfz8wsfX1l/bjQyomkSutFq6kKVZlK3J9n1rmHrtK56DEurSzFPsKiptLV PIU9JfOaPIA9wBqP2n5dSQobu1tDY1NLR42X3wdRa/16xGSknaeTsHo4DJbpchqdsxq9YvlM/jUd vTrqIvbiXZ27Sk4p+mIquSv0WRPKhURFo9g0o+UPmsGl3/2k8yrRP3F/D5PT/g7rcMKDjvPxc1Xt 1tKvTuM+t6JhBoUsXvrNo6QZxX2Ilf67gv2wOTr3wWbsTu0Gug8hVb2ehil4UWmymb150RS+9MEm LU3VQLKjOaC+8WdTQyGcue7lhZir6iEM+xK3FL0+H+L5lZnuQ3K18x0Lx+sagIfjm5tdj32fbxqf a+weaZSrEe3DYfRqZJWrUaXp4uRPmkqZiS7KwiF+F75Y3ePGjsKeskI9elr9iTJsW5oJWusu87E3 +YxQ2lVff42orCvuaI+Zwzm/MDz3zKvXLrtXqytcnI5jmScZBSntEjXL8N8+YW9TKHRKV6npcmXG Ol/BAuru1uXHv1L2HzZVttUKBKlelM6vvX2a1W2dQnLIeQ+YnTpy1kR1+afgpE9xxklqURYKslIc 9JUeggnUb/mjUeMcKrzlEZZcuZ9cyS88xXgjR4Xa7iSv1YOOT4Mvdz4CLbLeonfGXdRB8IlHgRy7 Si+GmtY8q3/i4YCwNMcxs1LISUkDO7gIpL4YsAWQGdhKPwc0QkB1h26Bo+hKLhf6cHbjHnqf8FNt y1yLenaXQJJgk4FKJSkBxFdJdnuUAMlFSnGJEEV4tMNFfFI4IU4592QTCtIKhe9NMQo8gHXAOtH4 9Zik0ud3TYjvmjVNASVNNOsBVPG0swXvVQC6iVnq2sIufU6gCAYtTMgkBr1WjENtV3+RF2ZRiisx /DC6BLjVsEnFPGuHoq45B6RD0TBExc85qQCsCiXg8R+sWUqPL4JbPQJUP+km746myV6QkKlHi6ij i2zX6qkmG6hx6MSi34GcUKIaqL4lpWtGsCmjlcKJJzP29ibrhD8Gc2isE8EFE0MtOUKPGlCHU2iE O9IPcugsP1rj9wbV23zTDa7THWmxAX10tz+SSZg/zXsx3h9pf+q6u+J/ynGe5X7aPJYxUWi/jd7D BFaIU4Do4eoheF7y4Bsf9Sf4euqLH0EE/XJ9723I7xC7EBtHbF8y9B3MknAJeeclspWcYtjpNCYy lDWXxbzRH+5LYoY0+vP6HHrnPyueSzl9RvwRbswkM1Vr7AfvQ2aG9uwf/yK5Y7wBUl7Au+BlKiYJ c9kCVBu9DtONs4fTpuc0VhGh7vCCfdj4PCtkGcIgG12rSBgtCDEhOGQ88mxYpi6WDzZPU0kalb+q 1ZrYNKvV6ifcgNO61Jz0bqu9liXNvJztcG10vP7MvcyFnBxy0gxH2Q1GQlv527TuiznhqYDrlj5i Z0oFdXyAsaWFIzm2a2vIGrX2fKVMAsdzc+qcqBbx1svlDXO9l+jY0zd1eb+rR0bq3uXzIwugwm69 Os4d5lsMi71iv5w8LpIkhlGoK6s8RmsC/QI79k4jTS5IZHnA/ok5t09CehznjRwrMjiU3iJIYepB w7EbGWjKSgmdlFsSjUfkaxIAl6jklJRDnj4G7xTOFxRMMZ5Wj5VyOHbfQKFZOcVwN8lj4m262aC3 augWRc6iKbqCilkevk54jdhKmzVwqZ+H0Er7NmhrZ9423Ri23lzm8PYJpVSXb4tuFYkCkZzKSP6N rt6mGPeJ+NuwVk31hbGbkWiJfxeH7Fcbyfwfbj7e4Qeaanml3Xd+NqoB9cUOKxVXGVcmH/IYmONQ 3oHkm9Tbltt66v4UAoKv0zIH7WKE1uz0Wz3HbMJlit9mv4+W0haXFrWs3Z3PBl4NPj5fA1/rX2Ue 3M/zbeW2stpdL5caqpu11wfmOUzqcGwdM7RFPds+6AQ3OAigW/O3oZ/eBpAsrQ11l0j8koM2RG6Y M5XTqCbTLE1dGzg0pdzSlLOErS340Ssw54R5T4V5xGrnIO8r+JTygjqEtojsgWPGrmmo3JCFf5Wd KLqMlAxzGYsAwjKAPY2mSE0z56vxVLbUBaJV58urho6GMEbThtWGruK78VtZanjtiOyYrmw2Fp7J b09vuW/ZI3bfoNdRKDBLGMb0FNsKfAIN+7fAjWEpUKT3AEOvQ3FDM0OokekYFHQ6LQ7DA0Gh7LDB sJ2YelpcmWjpKakpyU3E0tlN1BXMFap5QRFjOdgk4KzLpr352En8Em/4a4IzcEqrU65ZQBpszrkf M/ZlyL6HJ9mQF92Z/GSE9yA7ixbgAZZmSb2tg+ME6tFl+QnDAbL3EYcpq442AvSv+pJf/F1fc84f 6Cfe+L61kkdYIjoMAxEmfUZ95yfJCAa+jb9EYbWYhSCpgtHQLQT7u+Us4P8EhK5D0sHpB3+f64lL PA2QHSsAl4OkGnQFX1OYw2mTXyb+IFFMCqSXyB4/7ozbWn7RiR5YczrFIZ2HD7xWDLEn9bqKvNkU FYD4DgLXps8/6Cc6s+VOw+Sn4AIhUaijTEF++IQBanJQif3IIYXgg9q6iRRZaD9LZXk1dd5k45Xk x/bRa3k4dX7zIb6gYDhd3kB50Kox+/DvD5ttWfgneQUxc8EW6APBj6e6id4hmq+kMWF+nG7lsQZz hvnSm4CpzNrTmczolfP02fcwsjG1WR9Sb8gb1L5O1u05k77KALg+pz6YPm3WbSJCI1PTSrPH8a28 F1wc1sb4kdkuSdSyfMUqjuOcmXZ9SjYea5i2a+An/p0eyI0nofDJhErkeQ6RNYmplvAygw3agO9C ODvsQEuoKBeBfnL3cisWwE+Vxv5lYN+kl166x0gUEY18gJJ8Ycd7Qk22RRrsf90RlbxgdPjL+AN5 gCYAawB7oN4sTbXmXD9gAlRJ9q66HfCNis45Je0PXi8y90243wuxepTh8qnSSIDfa0UHzhPqsFDi JpYKPqB3dPt83oaF9kOBbgp2hJFX64aIVxqQW3ygeDkGaMILpJk/kG9kdwTzVofew2qGHrILzA23 fkeQxSJLty1/darZn+ZrCMPI6IWj1yZ73HTD9aT3P7E860HkT554Y/MzFF+b3nfIYnytNn5pNzKA p9s5vOCowQWocF58wjqcj5zYadABIXQSvS3vNMCef7JzXQYN90CkPxnWA5mcQbQy9lfjpsEItdgN zTJK7T3xUV3w6w869xzlNeJd6lxL52Faf00Z245PORLY209FthMGjuzZka9x/jIrPGR+nrfI5cUh 9ejyZ6Xc6iVOMQfCeIHtO6Ro2wBLz95xQtWxC5qUc2iDRuBkfpJzaI/ktgf4PDJ07ekC3Fk7xwyB AHgAlMqHscNRM6tTCACN6vS9Cr7Nkzprb2mpxaTZVinh1InliyzhB5QtuhbpnhFrAfINuAFvgecR gXThC2uxC+gBLdgPIPG2pUJ68JRpjT5LTK6PND+oV8k+WuHKgRMrnWWDx8sT80GVrT3uHAnSHIae gIVhqHJkBy9MHQYnzU+cJkZzidsYqtN3notUBGjSjmDeptAymnuESS6YmeKc4IAlMHproOxf5Qh1 6HNAz3BzEbdyFq2gU0DIH1VA67KEecsCIKM0Fg2hXXKtoqjY2cFUL7JJ74TANO0tT2MgY8wTzT5b ar5zdfHWY03GTraHPi47KjAGalVRK1tBvClpwcXIrCN//rLuIz6jtIH/BjvxQXaOFTt+BVKD07b/ voc4qTuU/Fh06i9S9kapcUnQumZ4D6VdhVH8RnpuWDiMpQRhHULeDWnnu+OCmJb9gIg7Qimu5sxm dW1kB8/hlVJ7EK4z63eFKLLCIuuU04zJfA0mZpL5AHtViWzXl3k4EehsP9AcYI1awwl6BvQQUB0A IUS64yyEugPb5wZ0l5n/1zINwFd2RGWDtKQUcW8Loxs7DNJIBKw9hlerKHT8YaC0d0iqxTvBFSF/ QNqEfuDO+Y1UOyMrbwSj0UUxiAR5N4HPwTxz9+HUE2i362b8Clp1E7fRw42TnuI6x8cs1uMAQcTe XbI4QHZMHDNUpd+Ey7chs7+rbHUc5gdTYB0DpQNx3OIJo0z3qRLlArgFblMt12dI6hM+Pxo+Ltfr dTLdddZx3OUKXA1PNfpFb/l+h5w5zNgdjLBh77MWtgaqO4mLn6qn3YvuLNLTxXgYF7BoJN9LzXcW NGe23e0hGHUWp2+lXFaI8lgbUb8kkD46tz/o8WBuQMEkfc9A1DlIM1TbxtjdhHuXkZofIX0hMUE7 8gBgCCzz97gpLzXeljNiDEb+6mn+1VPcxXjOyQsaXevHAQsYauG+XYXIpjvgi3E+SrnPzr0zSlHQ mFe6ER4KN4e+EyGAGp2hAvSlHd85D7kZyki1GOfNsl0bu5NmzVoh5+lGxa/qPfV1cwxw8+WtfpLw 1u9vGSn22idqymUVOenGAFSMSsBJ6eeoLuintuicqdvjsrnBzzFWyYlgXZCPquKbGKYbX/twgg4O kS9sq1bTxyijfvh+4ehNkmXI7HYAjt91Eywxt/kHV7aFJwenZsjCe5kN/Xk8od1+yQ58yj3JoXF7 QooLb4lHEguKKwF62ZFktkhfuCDRCsgSekU0hQSEpckWxfq4x0IaInxCGyVYuCOTSLxlHjk8xR/j bODz/BtMr5O+r16b9lJaNvinfgR2UbzJP+JLp38oPUoCIEwFPWcKmNnC6MrrXYhfkHXFMBPpOjIY KOx/qZ9WmqD7xjIEm24XCJJdz8lmSTecwnQEdclsl9gn4b1i+Ea/p9SUVUozTBcKknuyEWJf8f8U d1NVwjfSknlwIaUuIjS+pinO/hGYogL8tiHJZcuZYLUW0cz8i2JNRKBUsFyQ8gLOjlzbMiJMinRT 2D1h9lS+I5kNWXPigPbiLURs1bEhNuESF0grgKAuUdGfY00OCLUAYQ7KIk6nVfxqFXgLiokPbAV6 BXYFkUvKZCZ3pzlt7sivCddDpsVY9UNrZ/S4j8jCq2+EiWltlifAHib+2CBKSLfN/w5+hwv6NRvY 9tenyZthn1Ifcx/VDtgO23H/wZExyV3S5TFQOtCyUKukxf4XcAYQHxBfVF9yRG4ZdLWmuIWvMRpW 7gJQiSaw1A5Sj7wftdTHr/nsI5a3tqecdpGLGz0W3AvULeuBgIwzfM7lFUIPyhDgN9Jr7kK4FMgj r9/xU3KPlFuURxiNC7zT1KhmvwQuVTJyEUIZ+3WupW4EjD58x7He+lp/X0D2xDje0XMuR+AXfAfS j8wb31Hb1zjTpv+9Iv/iNMU7x5qvAjPdiT9JpJBu3F67sgH/OXxEMPrt98eOohmBQ9WjagYk/b4A 6Al3D84d02tKZry2uH73C9kZxR22PLf97E1zRi0XwLfoJax4Tp3iQkIXDmEYa3Gf6o57uhUfHct1 2fDmZTo5DmcbYS6a2W1C6Xrd1i+qXrcvOlCBO8tnk8Sx6dlLrFT0vlri8r7azO3uIToSodddRNbx IgDcCa/Td7yvs8C4dZ9jYa/9teZ7dHMOC/jlTEY4fvLcuXfzyk4G4BKplTtPZJuC8jZXsvpeAFk7 N3LOYi5zj9ZP01ZgX/ZBd5f9HLt6ehBLm7iMp8MXVCSzGHJeK/e0B7cI9359IEDmHDHqNM7vJOMU qw/nkAviV/lg+8jT9wuXo9dILLHZTpGexr7W71NOcMXHOHaBOhzfxtyffYONgMt/4I/6DhYhPDjW bziiuJbux1yTvbLmzS4fd8eL9TuGLsNtm5+H9MKvj358u5O+KxBU4tv5/gYY1iufae18YTNrp3/k ofigntreaZWtla4ahtc3FBsANqfoslvJPMxGQeSe9IWu0y4VVK1yganbRX4D9e/gOtA4nUWTzGn+ pHOcWg1w5R6+bcQjFM1nNwp0xj3q3mk7V49Sz63+1LlNKx7XJ9pyhPMaHX6LCJXhc6MYCpev1Le9 cuxwfKpnhfpWybrYW/YS2QhqnM/N60uPcbYBGRsXLYlllw/hp3fx0GzTe00XsFSt8WTEnLibxnUM rF9PPr46aTThCfWMYg5sYu1AcHs+pBOWDZk7pB/3AHijpbecIfaPIh8U2MWko80h/dSapKkaIN8x /oSw6H9e5lEwfFh2+PzticGF2zmddNm1oxC5Y41tx8FV6zVKj5vT+l6NUX0XZ18hfo3VR4ebKWGE waUzqIV3U1tv47SV7uAxLGoSZujhAc4GwgDHsmFk1FYat6sRracfVIrsU5Vm5qHkoVslknlXv21r 6ZwH0BYPlIbq5L9L1byYGY0oM8QEv2o+9x1MS6CdeRtqWEgN8apNdvCB7jrki0aY9KtfJhSTtwC4 a2TpWn7KTwqrh/nnlyK+I2aEh1L4M86SmdIFv8B6zIraYHwh/7rU2m3Ngh8TnxRvLSZQPhQaMLGY XirijulUAxakK3tF1IjTgv8svHzKbNWex2v9IDVLfAk2DaXFTZxsZsoX/mJhJo9pxIJb8MxJgw61 0RN2QRvEGdWx/hhiOVsLWOQOFDims6xR/WSu7y8LacVzvn481Jhp7/TR7evk3hq8pdr0ml8L/gEn AmAunCoNbyrXxU2EP9PdHxvk1xiFOcd+81AMtGnhyzDgn3UDPkd392daZbnqwNCx8jzQwNehoOio 8aSs4twA1WCMG2RN9K5u3QzuP1zqvDLUj3adX0PTsRSwy4OpMcsUzAiuD+33uUW6EYnhv8pukudO Ch4u4AQvbCZdbcW7T74JH5wZ7Ye5S3mLuYYDjCiP3aDdQyG8ZAdgejS8p+5l7NsZpGqcagZ7fuTp eHziIKoBL4kSNJZ6/547hxuchlim8MfIjj5USIfO80TIu+tzgvZeaFs5/3lHTZeuE3tzZl1j9jzf VjnNaZHpsNq9TIeoo2cyA6ye3YviBvuCEuK1LG+SCnNfBTRr9EV9G2HNWH7xZC86G/zZmEZZI3A0 XjP4CZtmuaz0pZpXYaeJ3gJxjWoNskRC6B5fjz/RAJz0pFX24V41XqN0XzXaYa6ZzuP0/sS8D63f sHrKcynTwuCcK+offJ70hHPEA1HLddFx5G+x1e+memEEsW137rTzspSKcXbdXFUH/hE/TeLSZULA tvyWz8wnVA1dkyAoQ+VGBz+U+VETKZTEdIKDSCc8kwlVoqnOmwWCvYS3Q5vAnAC9W5qwoHX9q1m7 0F6+c53jgNoecU2CL/USv4U5fm7LkvewwnbbnPfc0kLQoNPADUKkpTLP9rK7RTtv6VG0hZfA+g15 kvTJSV9cpmh0U8Ck81rWnlBYR38YFeTRunfxcQ4VbGt2b1PtVMmb0iaeH7/fsHBqIXIl/AuMw8D3 6WXTxjdw+xbPgpA1//aehGbWG6E5v4H/Ds8ScY26hMc6Pvg75oV03iqe8jV20NIK8lqtXS/iNlbI tlFrc95TTF/tjszNODfXa0yhAuNdPpOd/sDT6LcLtWN6YoUa+5U8jBF8lf7Doj6fWb4L7lC6boqo xnpz38lL7DzYy9aBNs855351e/3ddpqXY50NOq+RtWsNNQ+75m3OJ+P482bXqKXH8Ban44/H0ely fvcE7JuUQ/V19d3xY4683JHdcMfHyBGZJYb/DzFAzr9HU/szFh3ec/YlLDos4/aJ4CSLXG69cHSk YMZsz33k7TRoesa61HknsMo85XoQyLbmO3IC2eYKPEFVWAvhCWuxDzYhq18QOwIbzMPwW/i86xGv n8AaQ67pgFYkqPXIG00BPfy2KbDRWuxWBDYh1tpg+W53AqsRfcXWMvA3CaI72beS+RLWjs/F6kAd MkYPsgeiX6ote80VgcZwbT4p9gaazRXupf77VoN7WaCN13Zee3m89DL54fnc0zBjDtbC6l7pS7DW uFez/Mw801rvzgnstDYJA6jrrcsCey1H3fmB/bxuZrWv3toiHPd3st2caeq8g+w95cwKHLSK5ppA H4umwGGrExH9zHzGOhg4avVbdweOmSdRHxVvuRMQpz3uQlgSz4dsrGj1j1h3uIt9XSLygX8EtsoB BbHmz+QRN2pdjVU4IXSz2robfTotjWxlIWeZvxP0rMDp8FMZcmMZxnaBcs7a7a7AKtxyFAdYjBsg CejYF4bchsA1sdXa47eCQw04DGKXrLD2uGsC46jrAxOomwIPrP3uCv9V64C7BdYbdIuBR6idgSfm ercfTxE17h3Y73qRbVKsw65jgWm+RxiwdsuDNTYCD1yJLDGNfKsUO4IKW6J9OliPna4j2MSewIMt thTseucsjfCfafY8HxQZHnRy3C8MMpztmMEdYiv6nGZ0PCmdAX6CZbbgbstp7Ds1DPerw/j2++wM YktlT/viIWtPsAvPezmBE7Z0nBeWNz9h8rAYCXYjj00He2yZjC7eidL7OX2A44MMD5y27Lc/8Q+x 8wI8YRX6L7Vloc+wZRx9KrguZRw/zvEExB04mI/bM4KrbWuAn7TlikeCZzj9JKef5/gVhgf22wpc o8EbNrX7vO+GrcB9heM3fKy+Hbxt07nvoi5HfC3n++mkUA+97iI3rg7mc7yb48s4PsnwwGlbpXsS UUwdhf77Yvosbj0JG1baBObJlj7IPGWrdecHn3K8n+HtxLLEPYUc2+BY2a4Uj7ingn6crVa2J9q2 uafaU2ytlul2ZQS3Mhz8p9pTef90yyr3U99Km1sca880i+6n7VnmJsHfvmYOnsvxAoYHmrFjtrWr bXj2CNQxPDjIcJaTJbxdx55P8Ay5Fl6dYTkMHStsHc6s9nLLMXYStJzzEF+X0GQ71V5pXeYh7YL1 vCMBOjZ4lMFhnCkS2FiGg86fEzxKPCfcYTsjw8GTIvPX2jo9yvYGnAQftGfZ9gHfJkLT4DLbAU9i e6ut15Pi67Id8qT6ztiOeNLxdKH2ZPrqQxOhB6Fx+0Gv1tfC6tBBsRURoWYZCT7TA5uns4zt22E9 jmhyh2v7Ws/DELVv8DwOxdm1jv5Qkl3veRZaYt/opaG08BnZvsnhD2Wwk2ZoBTtFhlbZTd44X0/k hBs+24ZPtXNOrJGzKj+l2uu8Sc+fVcOnUXujd0ko297sTQuttbd5M0Ib7HbvipDW7vWuCunDdZiP PeTNDm207/SuDW1i84ZMfN4aNm+oLnKaZmfnGnZ2DjUySULNXJKaWUlCbWEtIhkSJ+WQnZ2RQ/aw XuzkDs78fM3yEh+7Gucv7CAhL9tBQiFGCe1kMRhqs+91rAztjXDr4XLu924I7bf3efWhvsjbCf7G wH7YMh06bK5h5yz7Ue/G0NHIuwh+6rcf824KHbOPek2h0cg7h/DpPvxWgZ/f7Ze89tC5yFuL8PsB jkfeV2BUsN9+wlsXXGY/7W1sJ/a93ubQCfs5b1voNPtlBf8ajcz5Go3yr9EUMdaY3SSGf4G2jH+B 9kP+BVpmzEDMIHmHf1+Xy78u0/CvyzbGbY5rIJXxNF5BTPwruM38+7efYY5skknWE0K05FOSRuqI j+SQv0GpJJ3kl+QT0kP+llTxvxtbTQbIUSLwv0C6mZwil8kWMk5+R74k35IHxEIekxniklFZFvlP sg7ZTnJUtk92mfw32U3ZHfJ/6bRcRv4oXytfR2bkG+WfyOTyWvlnsni5U+6RLZZ3yH8l+wv5sPzX sh/Jx+SPZD+WP5b/QWaQfyf/TibIpxWxMqNioaJAtlXxvuID2X9WfKyolPUpqhRfyfqVXylHaYzy H5Wn6ULl/1Sep68qLypv09eUv4sl9K3Y+NhkWhL7Suwq+mHsT2L19PO49+Pep4E4bVwRDcbp4j6g obg/xBO6M35x/Pt0X3xX/N/Sr+NH4kfoxfjR+BP0Uvxv4n9Dr8efjT9LbxAZ7NKEOpHwb7RKygAV AAOghqSVVJQYSmpK6kuaSlpKRGDOEn/JjpLdJV0l3SU9Jf1oB0oGS4ZLjpecLDlTcr7kSskN9tUZ X1sSY4uxERrjjfHy7+tS6Cq6ihC6lq4lMppP8wml79P3iZyqqYYo+LtVJf2AfkBi6Sf0ExJHq6hA 4ulmupkspHX0ZySJv1tNptvpdrKYmqkZPJGuyCv83eqrsPcwSVXEKmLJD6DTVXKLa5bCvrLTN5M6 fbO+TW/XIyz0O/V79fv1B/V9+sP6o/pj+lH9Cf1p/Tn9Jf01/bh+Qv9A/wjtE/10qQIloTQZ9dLS ZaXLS1eirC7NKc0vLSwtxnVZaUWpobSmtL60qbSlVETt5GNYuR3F7pZORkpxtExFir/kQemO0jOl uwHFpV2l3eDaU9pfOlA6WDpceqP0OEp/6UncPV96hX35pbgOay59zs/ZN/w5/K/s5hMbfF7N/byU /63bD+Dhvybl8O/L5ENyH2Ujt9FHimqFkVQoPlV8Sj5RbFFsIZsUP1PUkypFg6KBVCu2KbYRQdGi aCFGRauilZgULoWbfKr4pWIv2azoUnQhXmTkACKJWXk5+zOjJVcANwC3AXcBk6RAl6RbokvTZehW 6FbpslGv1W3QaXV63UbQNulMujpdo65Z16azo/YCQrqdur26/bqDKH26w7qjumO6Ud0J1Kd153SX QLsG2rhuAvfiSp7pHpQ8Q3msi9PRksfAbpXcKblf8pB9JRfzX2L+K/++MeE5a9lQcsj/Qvkp+QYl F1H/O5JH7qKsVYQUIfKe4heKX5B8Rbeim6wjssSphQn8d6BZJJaQKkRHVQ2RCTlo6wGIICEfUCjP rqoQVnIwCKs5MLxGyKmqF/L5dZNQWNUiFHO6KJRVOYUKTmf3GU3qJ42TcL9giPJmdDaWAeMl4Yy3 hO8Qajiw+6xl80j3JNgt1PP70jiGs/lYK0EX5uuK6MPm7kbbAxlZO5/fi2SaK9tceNnY+cB07Rea uF0GhZao7pJcTBZ2n9lHsmvXC2AAc84FNk4CposEkmzMZmwc4zmMOSXbSHPPXUPGQ9KxInJPsmN3 pGX3pf5Sy+4dF8SobSXerD0ZkYHhZwQnb88L/qjdpVaam12z9ZRaSUZmLyYX0+GKsON74yXdpPaG sLvqttBVdVfofk7OubrMl7Vrnh2ktn6ObEwfyX5MHqab1A7Mu5Z8VrKlZD9Gk3hMCj3PzSG1hpfo L+lrmKe/dM38h+HSOMxVvTZMm99G+0wJ/VVPhQGDWrhr0AmTL7XLi9qTf+b9P9Xv3zPPfDvXz1uv f6s9OXtdvSGs98tayS7zbV2tDdvpT7XRde96QTtXj7m+P9cHAAYiDBqUwjDHI200J0fi05AoHI/2 SQnHpSFVOCnla0O6cMaQKZyP2qxi1jcMWcIVwxrhRlRH1j9XuG0oAA/MHY3zyBhDuTDF/ZLxkXwS raFSeMplEYwk6q9SC6g2Ga9W1xlvSTFQ3Wi8U91svF/dZnzIwW7UVXuNjzktZHzGrnm/nciJLF/O X2PYsFoPXvPpUvwzv987O0d0zfebaPVBU1zU1n/K9wYieV5q5/vU/Hw1Py9FbFTdZ0qqPmxaIuWQ 6qOmNO5bDCRbSXPOz8eS37xof5pHN9QalYYGY6JhmzHF0GpMNViN6XP3KYPbmGkIGrMMHcY1z/GS 9tl5YOg05vI9VwKJzz5jAW8PGNWG3vBacf1fAoZDxnIG3IeOGCsNQ0bBMGKsNYwZG+bupYZTxm2G s8bMuXuP4YKxlbdXjdbn9vS5wPz2ltHN9OU6MrhjDPJx940dc+1leGjsNDw27jM8Mx6opsbe6jjj oeok45HqJcah6jTjSHWGcax6hfFU9Srj2e/lwhftfdKeMjcPv6yd71/z+Ul05scDc/ztRXn/5Av4 z92LGEhxIsV8xRxfYv2YL26M7M87ZtvqTeH1ltoo/Ck9X5Jrn/Plua0UN4Z5cTR//5uTS7k+c9ro vj8vJz3Xvkze7nn2nDdfdK+cv6/Ob4fn5Lu5rbQmUr4Ww/ZuudVyR4qx6mOmjOpR04rqE6ZVLB6q s40XOJw2ZVefM62NPodL/CTeTL5Lpg3RGGbzzH0+luJPejaW5r9m0laPm/TVE6aN0VhnsYe4Y/E3 l1/1A9OmFz57R/hWPzKZnovDeTlKykXVT0x10jMRi38uB8uJ06bGqgpTc5XB1MZbBqLJXtVi8lbt MIUEhWknv2b3d5v28vu4JySb+jgdfXgr8WB4k2k/75NgOshO8TH/I+ZrQuI+Y79QjI+JZ78ko2TF /+f3K78iM/w9ymb+HmWL/LH8O1kXf4Oyn79B6eVvUC7wNyj/wt+gfKP8KlZP1fy9yFX+XuSf+XuR 6/y9yL/w9yL/h70Xkaex9yLyley9iPxN9l5Evoa9F5H/BCfaPnJ49u1B7g2iy0vNS8/LBGTlrclT 5uXmFeSp83Soy/Nyc2/kVeYJebV5DXnbcm/nJea14o41z517l5W8IKAj9ynqTpR9eQfyevMO4epI 3lDeSN5Y3qncydzJvLN5F/Ku5t3KneLlaR7BLKwk8oKr3CkOKeibmPuUvQmI2cN/u/f82daOFXER D061R1De4+fcfPJbcgEn2Uso62W/kZ0hG+T18s9IIXtfhZEyYiA1c/R9SpZHJEjMS4lonsg1l/Qu n9UY2jYwbfOCeR3QL4jSiV4Fefu4jN2Q8VX+XSCB96wAbSUKxVk6i8jJKhQFWU3eITHkJyQb5+uf krUkHjJpyUJSjJJEdCiL+P9llEzKUBaTcvIhJP2IVJAl8DkDWcr/ykMaEVFeI26UZcSL8jo5i5IO 3S+SN2RJsiTyQyJTWpXuWV0Lb8uzC2+v0xXeLZwsnFrfU/hURdbvXpeoUqoSVSkqokpVpQMyVVmg ZeVmq9aoclUFKjXu6nBVripY36OqVAmqWlWDapuqVWVVuXP1qqCqA5SC3IOgdar2qdyqA6rewtuF t1WHCqc41yxwmC1D4MnL+t3hwrhIBTzCJVF1BCNHCifVes4rVXVWdQGcC3A1xWEqOj6VlyxWcJUI ybK43L2Fk6oxYAeg1yloW4m7V1VDhXdzsxmoysE3UXVLdQf9ygH3VQ8hcQHnIAGBPgxSIVsm9GTA uD9WPVuXCJ2zICsDzMZnnFJTVSrjK83COEYBMjBQHQIQWBKc1XGqWsjFQZ2kXgLbN6iU6rTcCXWG 6oB6BdpV6mw+P5dBvZbN/9zcAPUGtRbrtY9pu76bYxIw/dlI9ILd7nLZvgcvooM2pT7xnPzPgfoE l/m0+pz6kvpaVMI58CI6o6nHZyV/TotxDge4zAAmB5tDkl+dBqpOvRG21jGAbdJg4Un1JrVJXadu VDcDbyt8qrarRtZ3Y6SS+anaqw6piHqnKlW9V71ffVB1St2n3qSZLLyrPqxOYpZUH8UMo+B4gK2h +ph6VFtZoIdHBLWntGe1F7RXtbe0d7T3tQ+1t1QF2sfaZ9GVxAxFVN3IAOMyVA3hEexeUVxRkork jkYtGrHc+t0FGxjMrmnUr7gVipYUpRVlFK1gHlK0CrE6CXoB41CUXbSWj2C2gc+uU69TF+hVY5q7 LDpVY+syNZOaKVwzySrX6bQkN1urzB3VJoJ7pGhTtKnadG2mNgv0NbkTqjFtrrZAq16Xsi5F49Tq YINabbmqXFupFaB/rbZBu03bCuq29YO52RhjVZXnTqu1uaPqDLV9Xcr7jesS1YchVXaBPjcN93Va N3gGVZ3aDm2ndp/2gLZXe0hFtEcKn2qHsHqbmGet0wGbUD9QP1I/UU9rFEwb9YSqXJOgSdYsRbtM s1yyl+qhZqVmtSYHeebx+h6et6ToyWKtJh/xqdQUaoo1Zet3I57YqiOCNBXqJ4VPNQbVPo1BU6Op V2dompDnrFHgsZ07oWlRP9GIGuf3PDgduY0BXx+Nn4Fmh2Y3iz/1I00XzwMRnHmRplvTo+nXDLC4 1QxqFJphzXHNSc0ZaV2RcTo15zVXwpEJzXIxP4OCsN9pbkDv27DHE8T2PtAS13dvyWfZtmhDkRag 145ox1QjRdnMguCWiFzxsCg7dxrRUL6+p2ijug7S1kaycS88cFORqaiOU4KqgqJGzcmi5qI20O2a piIvslCwKATaziKT6hDaVUV7tWuKKPBJ9N5fdLCor2jv/yPvfOCjrK68f59n5plMkiFQTAIGiMlA A0KEERGB8iJVTJACpYgULUtRKKCmiIiILksR0bIUFSkiUqQpKiIipSxSlkUEpJRSXkQWKIuICJGl iIgsskgxec/53pvJJEK13d36fj6b53N+9zznnnvuuef+ee4zz+SZ7kev3Si91VrXXF13xJslNywn Jur3QrdS5osk9o2GN6y6YS3Xwp/9L9pB6a+u6Wfm+g42066f8YSy2/VuN7FdfzkGydFFjiFyDJfj TjnGyBGWY7wcKpsoxxQ5psnxeLul7WbLMU+OtnKUy7GonT578IOngjlSR2BuMKUS1xvNt2Rf0Ud2 BxFzk0QvU+L8d+YS48WOxk7hEc+6bvCNVzpJ0qikU0Pte5wvnaB0g28JPiqU5WTZQnlOXiBU5ORZ TpZVp1w1X2zTpLzAUV4Kn53Ct3eU59KilLxq6uTys1Ns+S7Nq/Gzuj3JdlW3pa69C/mU6lsqXaxs XdK2dnN19qhpe9KvLJdfXNvfuvS5+rNSyE+hat/au3J5rs7q2BTUyJN9mFXTxmQZv05aUKOfLKd5 vVJim5pX3Yea9nPpwJS4+3Xq9l1/urSW79kuHXyB8tHS2m28XWiU0Og6fqa0pa6vn4tD3bRundmu bRdL8+rEv3o8tU+xMe7P1HWh9tf1oW5anNIP1XPGyeqmSZ0HhSYLbRHafvG4/P+Sfi7OF+uvL0qr 2/1Fad0Yuzh9UVprftVNU9tRd3xVnys9KjTD8TNS9FLH8qyUvLnO/oLSmvX6eaElNTGrNTaWC62q U/daoY2u7tQ1SsvsKrXzs3ouVqf7nI2DpbXnYdRSyTqhTaXJOVCyVWiH0B5H+4UOOdlRe44/uib2 +HzfJf2p26fV9bavXUd1fskJodM17f1SY63uevtn1qsLrktSruRc6YRSUyMvjbixNbnG54utQ8m2 Xuj6VFd+ROi40Cmhs0KVpbWuUyVhoQyhBnXKtb8wleSW2mtuNVXbaerSuFArJ+90cSppa0n9Lekg 1EWou1BJaa1raUlvof6ltdbpkkEuHZLS5roksSoZbttLG5XudOXG1I5XyXihiUJThKYJPS40W2ie ULnQIqGlQiu+xPhInYd/bl3+kuMtabd6bl3s2nOxNHVtzL74GlTrunyhtOgi9EX1f8Gae8H41Z0/ F7j+f1Faay26UPqX9E+q3YtcMy9Y/4XSgpT6U+J+S6I0OcdKY0INhRrb+VCy2lJpvlCLlP1qdflq 20KlrUtr5nB2ae39cfX8q94bu/KlUndpR6GuNT4w9/rb+Zdqr/S60gvvvZ3d0p6ltedh3TXKrUWl fUuTeyKd/9Sna+KA2vvy5LhwdZbeWnucVMe7dERNLJP9ljoHVGdo6QT93hNv3zP/e+41vZn6fjgT 87L0JZHtzgidNyYhwkRUKEsoWyhPqECoyJ0Xu7z2Qp0cKd9NqIdQL6F+QgOFBgvdLjRKaLTQOKEH hSY7G48KzRCaJTT3r6AFQs8LLXG03Pm3yqVrhTY62vJnaK3p3m5bu53t9rY70K6i3bF2J9ud4ahI Oc4nfMsloomsRHYiz+YnsoQKEkWJYjnag5parpM9a3dGSmS5st2kbA852id6pRz99Luen/+mL2+c DPOuyRzeKZnLOyUv5W2STXmPZDO+41vAd3yv4N2RV/LWyA68L/Jq3hfZkTdFduJNkZ15R+S1f/P6 PK+hZ781u8a0MabtUaETtallnqW2p116TsakTMR2kRSKCTU0pvlmS6qDXmOX5gu1sOXRbS2UcNTC 2q4mzcsf94XUpu20to/XPi6fXleSIp+dIpl9YT099G36fJPb8EZR+y7RgG9yZ/BN7nq8S7Qx7w9t yptDm/HO0ALeDRrnraBFvAm0FW//vJz3frb+H7PrmWVmZc0zoMLjpk/RnKL58XVFC4U2Fy2Or4uX xzcVLStaWbRGJCuL1kvuVpFtjW8VndXx8qKFIp0vOuvl2Caay4p2yrHSHXM4qi1uE4tJe5TbypG0 I3XOL1opkk3xRVJuIXVqzQuL5usnh75+whXxy/3XZFnf4P/G5Pu/9Y+Y5qHXQ6+b63X1ND2if4ge MDfwttPGQg3d+0WbJcuHpbysMf4if40J/LViK48yTUUjF6yOx07jKekbdBX1rbWmk+lWo5G/3DRs JqbzV+WvzT8luDF/S/5xOZbnb28Wy98ltC//YP4RbMzVb+D6L/ovSt2v+K+I5Jf+L43vr/BXmJD/ qv+qePYv4k0gbdpiorQmQzx722RG3xH/GsiMm+Zt4bO7/uZrxjSRVbnwoDGXTZP0CP1Xm04JnbW8 6qCn8kpLl000fQrXxacXborPLNwan1O4Iz6/cE98auH++MLCQ/HFhUfjywpPxFdyrjqn42sKz8WX xU18fTwS36zyeCy+DR3RjTeM71RS3Xjj+F7kyufHz8dbxA/EW8crqomyPZsXKalN7HaMn4z3bd4+ SQOa+9WEnVubZ+Gj2I0PbZ6tPL6MaF6Ab0LxMrEjvqlflO0aP6OE/0l/xLb6M7Z5XnxC82h8UvNi /FZ7DeNT44n4MWyoP1r+OpEJTxslj37U9ysb3o7sRWZGfmr8yFOROSYSmReZZ6KR+ZFnTXrk55Gf m8zIC5EXTCyyOPKSqRdZGnnF1P/SY9jzlnpn6e/xsm8xhY8LzU6heY7KhRY5WmrpUhn3hetsmkqF m1L4FTUk5158jjHXl8mYGBpvXziicE1hWbxT4Vg5JhROL5wkx9R4N+HXy9lKzmeKzpzCssL5Kov3 EOpVuFDki+VYJjorRb6G3PmFm4XbJsdOkY4Vfm+8qPBAvF/h2PjAJE2Kjy6cGZ+sFI8Wrlcq3Ft4 QHRnVFM8K+XIxsdR+Kg+zYyPjucpH+8RL4g/KP6VpfjXK14gfk2PZxWuiQ8W64Ol9Bqxjj/xIrGv /kyKj5O82wvnxB/Fb2t7uuidKayQ9h0TbrqUPSmyM8KfF22/8Iz2kv+Y/5T06dP+0ybdf8aX1Tny ROQJGQGzI7NlBDwTeUZGQHnkeZMVeTHyormEN11np8fSY6ZRelZ6lmnMe60v/YvWuBFC/YQmssrl 8z8mK4yull3dypeP3k6+ceCZozV6Xr6n7+DNTur5sg6ljutXZLT6SPGGuvOpW3/JJsq4N4z7MOM+ wrhPY9ynM+4zGPeZMu6Xmnr/zZY0NobYBMTm61+xJY3yHNcbS4kovwhl1tMXntmTIqtwvXGuRub6 wvPyncw3mf+lEaVjqfFFYx7BksGShyUfSyEsRbGRftHSwec9o+5Mas26aFT/2nJfzlsd+/PMVPrA jml+Q8rNBk/mRbXMN1vZ+bSqpbfN9oA55GT/nWP8L5lZF9O9UGT+q7oai6Vu3NpYFCLbIbv6mjXE ys65cZsiq7OGFP4Pj9ovM37+a6P9bz9q9Q3T29hT6i96mdxjSerTKNYoln2+UcNGjRvlC7aQ83yV NWoNWj4mubFGCTlaNOrIufIxd1wnR6xRT0exGovZx7KPCX8sxV61pVQ7CVLN6Ur9re25tjnydORp ad2iyCJp3cuRlxl5X3JnI3NxDW3muXjOGaHzpk/O2Zyz2QnFnMrqFLRHZW64ms/NyM1QzBmc0ym7 tR41mrm5OYOVqs+tpdywpikWwtWWnJ2CS446/RaCo3PyckbnNshtoJgzWp+wR34WWfBXt3CW0Fxp 4eyceTnlOYtyluasyFktqOm6nE05W+F35OwRXJSzP+eQyDblHM05IfzpnHN65EZEc11uLDcmMnss 5XAWcxvmNlYUnXzRUWtLraXcFtaOWJiXm4/tpZRWOkoOv78QmRtZ8hfsPnyvBavoUjf74/oORG+x t9BrL+dzU6V+lh/15sr5lFrScf5or1LOy2pJ9/m7/OFyPjBVGuoe6uJvlfPutaSLQuWhhJy3TpH6 4UhoTsqqFE9pW0N/of+ctO0Ff5Hce73kvyR3XUv9pTLHl/vLpeWr/dUmTVq+wUT9TdL+dP9Nf4es aTv9fzX1/N3+blPf3+vvNQ3Ey33ma/5B/6DYPOwflnVsb3SvyY6+LXdsOXLH9g49/8Vrx9/WI70T fQx88ius+5mvpO4nv8K6Z32Fdc/+Cut+6ius+xnWqCKvQHbV1b8G1NztWvSzoZO1ZLleAznbX0uW xe5mSy0Zv75iVqbKTKXRX50tryU7I/Y9M6OW7AT3XxNqyY6Yg3I2vJbsgNmbsiOzsj2yJ6vZkVnZ dvGtZkdmZZu548hOyvQTL113DLsRj92I7kMWsuetmRXJURoprzViFX+aIrf83JqRFZmd0tOPpfBP 1vCpOq7sUyk2Lf+LWiNG29JK1m6fT+Vsa1rU6In/qrfC2M/19BdvA7l3zkie19pVxZYILRdaZfrE lmWuyxyfuS62MnNa5qbYSk1ja+R8fWxzbLPw2yTdGdsrOQfkWCnyitix2Bo96vk2lWNl7UMsrZd0 W+a6etHMafWyxJ7oZI53+TtjK+tlx05qniutdJJjc+yM4JnY+Yvu57/s50VZ3gDaPFYiYWIdhLqk kFw5YyVCvYX6Cw1yctWbVoced+lsx88TGiIk4zR2pz2PHDJ9gsqMvRkHBCtiGRnHMk5mnIxlZEYz zgeVemT6mVFNYw0y9mZmZVRkZmVmZ2aJ9jE9JDcvMw+9LHvYUtUWI3eqxcid1l4sV22ppRo7saZy dj5jb2RrUBmZFlkUHInkRqYFR8TKkf+2O5Evu9875OUSe/1fDROtEJJdfPSkS5Vklxs9b9N03+WJ XnrUUZbpE90nPhyJHo+eip6NVuoTmPSM9AZyvk8P4TNIw6J1So6D6bnpTfVcD0nFZ/Kb2sOWqrGY 3iXVntpylpwdqfOg5B3EVjy9lRxt0zukt5KzVn/l3fBfNXKjsspFrxPqKdRXaIDQrUJDhUYIyX4x OtbpbRPaKbRX6ECdyG9zUZcVNzrJkZy3nWb6hHpE86MtBFtHE3J0lCMR7Rq9LtRDj2jPaF/SjqI1 QHQGRG+NDuBcjtDy6NDoUPIH2MOVqm0xIVrYU1tYqrGTkLPrhDpK/vbQ8VBxaLCkxXJW/DcfuXqN O5eyR9bPQCKVYz6rqD6+4Bqi+h69p6vylqpO1at01SWRLMFOisaEXwdXGS9UkNZDVukT4L6IlPc3 KIYKwP4qDzWBX0/uDvg3wdZI2oTfEOwB3gg+oXKvEn6HoncMfgM4CJxO2QR2usFfq/Kqy8JyxxLu Hch9Xni5/pph6K6QXF9C94XzBEfA/xR+oaLoqObrqhnejn4aeBR5HjiO3DzwF4peM3RiSB7mNxPv he+E/ixwoGJoPfydmpvWCJ1Z4OVY+CnWKhVNFV7FFM172HwDbx8Ep1rUXH9k+Cr1UyXeJcH3RfMa yna2bQR7KlYd0qutv6Bqu0hyqz4Wfq1KQgXKe83IfU5z/UHwu+FXgNPRL3Ny1T+NJAH2ABtWDq7e aUmulDI70S/CQhGljoH3o1PJ1f8cvN3HvWGSvxoYulHHYKgA/nHrZ6WOsQfR+WVVRPgxygfUEuoP dq7U/cMR1xbZbXkbkT+rGL4M/j5yr9XcqvneQMFN4HaH+wRP+K/yHie9Bz0iNqRdoSb6XQz9TM07 6Bep/4qhJv4JjYPy/gL4R0I9te/gT4DvqsR/DtyhEq8Z8rOK5lxIfy3vnPKhEWBrcnfQdwXWDn29 GH4kuA/NrfDPgYPANp7Mfb8v/rQBu+BtGL4Ivji8XNulvHkPPKI+SO2qcy04CPlJ9E8jeVex6lLq LQhW68wKy64uvAmcH57LDFL5VeCfwksEK5X3RimG+iL/GZLi4F+k7z5RPvBAE56jFsJLhc+GP6S8 1LKEuaY6GeAlimm9sHYYzMN+B+ZFQWi64G79ZU+/KNiqYybcXFcGzTVb9DdZQx0VvSJ+/fNJSl0f elnHj51lYSIQbia8L6PP8+aFr2bGadkCRfGwiH4pYp6qZL+WjQyglnPIB2OtP5r7LK/oD9K6/LXw J5xXrbCpv9N6F/imol9k+dBeXaOwsN7Zb4U/gt5Av7Nofs/vL73zqj+ZHpwO/ypYwYx+T7CCfqyn ub7H6O0PzqWvfyyjWy0/jz+KP1b0GsOXK0pMlH8PXOckPxNsqujNBE8jiSqKNZX0RpKALwa3gauR z1aUqCq/FiwDJ6MzxNqsGieS8eA94GhFkf9OfajaCY4DWcGqNgsOR2c1OJNc7jiknboCROGHwCfg V9u1ixWGOzevmNzZ4A4kE8ndwtVxBngE3AmWg+/xxGcU/H74b+mv6xo/fFj474V/oSsSrT4KTgX7 K4bzaHsRklXgm+BdikErdJ6Gz4ZfDj+BKG1EQrRDc8Ex9ILRtpsS0GjETLZGzOQjyUaSrxGrXK+S yl3gKnK5S/Zesiu5XXsVZTcg7aq6XlHWZeXzaK9hbHRVDHXAq1Hg87RrB17twucSfNsC4r/ZDy4B T1rPwTngDHC0YtVQ+OFYw77/vTDPd6r2g4c0qlX/rHGoWq79Dp5QFLmufisVvWIkq8hdC/ZAPhM8 qBjujU5/sACMgUfRfw6dQ9jcQqnTYGNwIjrT0R9j6yWGPwTtJwZ8vlB1HL6fvUaDjYk8n2b4vcBl SNDxqpAwGnVPKZIjTiIrp29H+EHkfDbrDwDjXAHpR58ro8/nrqEeIN+q8Ye5uvRKx9U51AbJPKxx tfVeAPHcfxTNEnh2Ed4n1kJEf7F6AdhY0TsJ3wu+H1iFZCL4FJIj8DPBg0imwA8A4+BGsLtiqAfY EMkw+CL4eWAzLOwEXwBLwHLwHPgJpdrA31wlewBvgENdN3rDfxv+28rL6LKozx+voNea0Gob7X1g F9D2I7nmeSSsOb6PhP2Pdzu4WLGSHZrZg+Qz8I8g+y6P9SfUFn48dgaD7Hz8EeQugv8VuBXk8/oQ o8s/T9kV4AlwM/h31HsMnQfdHkz79BS5jA3vJrACnQ5gLhLWRu/X4D2gXSU+BRkzhhXV6wveSNkf IR/ILO4KspqZfmA+yPpQ9e/wU1hDxoLLkFzqVrYzuqOmjUTAJ5LhCJJV8L3B+UiIWMCnbSH7JGMO uduR9IQ/A/KUQq6mKreRJOYh2/aiyjG6N8CCffaRUfmg7jHgR1PLregTJdNK9f3Nit6jyNcjX4mc vvBPKB9hnPhR5QM+AZSrtbUgu+sIK0Awx7ZUdcLT8GQMeAprg6il0u7GFb1t6ptZh539mmtmoD+V HjmNneV4tQvLsym7UzHUAc2e2LwZnhUsFAP55e8QT2n8MnSW2fFDvc+jTysC1jp/h8qDbCwvRIdV Lnxn5S6dQSrx7wF70JbFaLY2+txoQuV6wfaK/lpFbxl8D/iD4DYkg7B2WjHUGq+2Ya3M1bJLr/iV c3WfTO48cA86L+sdhM99RHio64up9JTuu0Yjt2t1e+zcrihyxRIsTEc+3kaDaHdFshadKfiwETyG ZAa5RUgaw892o2Uh/bgQm2PwfAztVc1RimFWA4mYtnSqjRuSLnZsY2Ei8s3gZHq23NnRvmCfE2Qw BvbSX/0Ze3zSHJ7ECJlIK9rTX6Owz6plTmKtH751RNLP9elw3c+jOYh61yJnZYtwJQqYEZGxjJ+F 1LKN2HbCB549hpZqqfB2xXRWtijyNGqPzLQe6tiWyAhGmY/BfuUj7OUC1meJjNbFTk/6ws6OnsyF nlyjI7q2cEe5i8isBTvjSQf6fQZ40pSIzdF2ZfD2676CuNk7aztzzxKr0VioIJKMCnOri6HaXIUP xUgmgAbN4Yz2o8TKrleFXBf+EFQa77PFkZjwH0UyBT9UrHpV74wEf68WIvl69xqejeSfwbFIloCj Qb0v2Au+GnoH3KJy8NXwGtDaAYOmSN5Acx38i3q/rDvYqvmhQ2hqbkTvkavmy0qsuBz5cvR/BE6n 1FBwO7hJr3dpcpX5rCKti7YrrQxJGW3prhiwl4t8BOpnTe0jr4HkRvjmlYwgRd1zmrRHwC5gVGpZ E7AjjcTh+VZW5Icg36uLXA8+JD58q2oSV5Np4HLwTrAt+Cqon2kETv4deu1D8AMkm8BJao15YT47 CzbU612wQfc5QbngbXrX6b0YqS89PlDbG/xWMXxYMdJZ0QfDBrwX+RLFtMcUPfR9JMHA6Fy1oBjp rBg11oLyac2sZXScNeX97sqHrkJzN3YOIMF++AMkv6PeSUj2INkLXo28BPlY8I+U/RQP0+FPovMb 8BSlvgt/C3xDSm1DkovkNXAhZaeCq9H5ELT6I0EfZLSEp4AvYacA/AYSfPNvAu8BvwNuIfchcASY D94GNkZnELU/RVvuAruBxDwYQu5y+JepEX+COBZeJ5cxHO6E/Gbba/TOJPAWxbBR9GyvLUGSQ1l8 y0CSTo1R2/tdyH0ca2AUCxmMgajti4/BwWjSa8GtYIR2WT6Kha+BMfRfQD8Tfhx1EYeA2IYsnw1f Tm4GEloXYpxUfU/vtiqXVskIr2KvJdfQPoKHwXsUQ00VPdA3YGfkN4ObFQ36HpIwOqHH0ZyMvAB8 BrwT+UfwlPXvAysodS38XeBxcB7y5vDjKHUeyVT4s/C3gw+AxWj+IzgCSSb8AfAtSm0E9yMZD6aD V4EeeD/4TXAAdhqAzZDgj3c52AlsBQ4ntztYH0yAMXLxzduKnVfBn4M22r8kdy/8buTWkyfB75P7 MbztiyVgBvL1ioGNP9bC9JH3W+yAYRvDCWBbcl+HfwV8GMkV8MQ2NA18FEl/ch+B74KcFvkbkM+A nw7PLlFG0WBG0WBGy2BGzmDGiV4lA66SN4NNyZ0P/wk4U1dawQ2skB1YITuwEnZgnezACtmBmdiB VbEDM7EDs7UDc1N1kETRSWuGHXi/u2LoKvjdyA8goWz4AyS/w+YkJHuQ7AWvRl6CfCz4R8p+Si3p 8CfR+Q14ilLfhb8FviGltiHJRfIauJCyU8HV6HwIWv2RoA9+BE4BX8JOAfgNJPjm3wTeA34H3ELu Q+AIMB+8DWyMziBqf4q23AV2A4lnMITc5fAvUyP+BHEsvE7uIfhOyG+Gz0FOvRn0SDrWorbXupD7 OLWAURvbj8HB5NILwa1gBD8tH6XU18AY+i+gnwk/Dvu0KyBWIctnw5eTm4EEb0P0e9X3dOwJbtCr P3Ut4pnUPeAJ8DlwN8+24vB/AsfbJ2VgGpLFrmwz0fyIp12FlDoN35DchjwXmwnfQ9F8AL6HpAh+ PzY7UCqK/lhwNXgJNjeS+wqSbfBneWaXxmrfWfkgG5uzuaasJZcrYIjrr+grnmCXMhN81KFoekOc HdWpJ/cBcjdBvWFsdrHPCqm3i/VTJeHeNiYqMeeQL8bmaeRco/3Z2DmouaHWSG4ktz58I+zXA+eh +bZ9bkhu90B2mP5SG3O5t/C8b9udAPpXI78cyXPUW4m8jKhWwa8lNwYfwv5b8NN1Byv7K2m73wY7 7dDcDPZFpylyrtrSUxIT//dY+Al1NYYfpRbMOfiW1LuTshXgCuQTtUXhPOz8Efln8Ala+i6SyfbZ aFClPrsx9hONpO6TvU+JXmeVhKZisxj9s2j2tDHE2nPuqas+4e+O5j8hudZGgPHzE/rrPfhl8OXY T0NzLfL7wY206CT8EPg54BGsPYP8bWp5yT4dDqboXRVedbZzIdJY+GddPDWG96C5gggssLFyo2Ii c2QiUS2jFuWbubk5jFGnOhvQfwT5TeACJCHG8NdBdn1+D7fP1BFezIxgrxsabHuWVjdBZx99+hA+ P0S7PnLjZ4GOedtf6FjLRei8Zmc3+Dz4Qzsa8fxt8FPFqN2p0t5IL8U0RmnwfWp5RTH6K3KfQt4V D8fY/rU1sp/E8zRiGInjfwe8+hTPb4CfSCl2kv7t2P8PWj0N+QDivygygahOYIx9xDqmkv6RTrqX Qyct0Lvvm4IY69IJvVqpjvmV8r4HZoEG/bbKm18Shx1a1n/ZroF6/xsKsLzbxTaflS1f9wbU8gll TeiPepfN2nIIXA5OonX34/9WopSFnJU5MOAVSJ5GZyGRmQq+aWefYsAaFTqAJBPsZMcAeJ8d88F/ CP8hkqPgx2j21ntb8a07Xk2g9u6sut3xobv2C55MwIej6PRWFB3l84jwdHCt6suqMoGyisPBKxRD CwMsgG8GXJUCuz4wF8C1iuEW6ByAz1SMPK8YZCNfr56n/Zox04gI3Iwn26nlvsB6i2+Bna0TmL+a uwoLn8IzusKsnGGfaLyCfCttaWr1afV5bD6Jzcvxcwd2fgo/iNg2UQx3wueB5O6iVDkWRtgri/O2 OyNhArzKS6nrvF03rH0XT63xYfgu2DxP332IThutMe0J7Oyn3nGMoj3YfJi61lH7AZCZGJ4PXk6f XoP+NvhWdixZHp13rB1wFppELJgC/3PkefAdkc+AXwZ/L9aGw2eAb5B7C6UGEu2rwEO06FnmWlMk l4PvgKWsCd3hPfgsLO9HfyT4GbnLwTNYm4tOib1qMFoeoSxXnLQyWzteLUHzSSTH4bPR4VtAwQfw XMWCdVheGLRk9Lbk6nYT/dKSsdqSsd2SWTZL6kqnRq6eEVanyA3wjalrO3F4HTyOfXu1WoXPm63E WgPXU+NI9Dsxy6aDZW60d2eE61z+kVrIuFX59FnKR9mDRX1qH6uY3pa5w/4nYJ+W9hwW+jEy8+CX 2Pi4lUHRc6NdMONeSvF9qvAP3HhWjAR2XHVnRij/LbsmBHacq4TP0yKs+ZHvEvNhjPMtwRop9U6w S5C9Yrh+uJvujcOLhW+gn+kFXAW83yovc1bxIXCwojeEGBotFb5XIxYs0vVZ7OgnvS+oxNvNPGVt D49B/8e6Sn/W130W95Bgffj67lO4jiDfOqt6GCwD+4EzZO/9sWpWnanahWSWXrvVgn+PYigXfjq4 Fkln+N2KXhzchmQQuf3BAiSz4WPwJ8Dx4GLkb8I/Bz4DJsAisAeW063ks3/TXTrtmgD/HhZGkHut Srxj6A8BK5G/C39Qc33rw27lw1fB7yC3GGyM5XPIo5/t030jfCtqGQxfhuZprHWxHmKtNzqrkNB2 s99qIqmH/nRsHlQMpVmfbdtV4vcH1yqaI1h4g9wVthc+W6ztAmciGYn9tylVhM0C7N8P3gBuxM63 0DkBXov9X8LvRqcYvp5rl/IJ5HH4yVieip0/2MjYXiZ3BZ/JX4L+RORnkW8gGmNsL1g75IbAvkhu tLztHRdJtfO2jk/vLUUZCTpWzyH/lFJN4W+h1AB860ldPeFtDNug0wudmbT3A9tG+DngSXSGgFdS e8OqFopodnGeqLwNdlYrBk8qhv+kucK30PUESZ71zc6Rym7aI+DVdr7AJxS9Zlhrprx5TzGUS24b +IKqJ7VfeA4SQr4AXGwjZhHJZLCLzQWbgrPBFWj+nph0s+Pc+gOeAG8H30WzoR1pSMrw7Q/gB/YJ IHa+a2cBOpvBHZTdR7t6gUPAj2jj++j8GstPID8IjrIrAPww+xQMzfHWGhiyPU5M3rR+giMpVQkf hR9LXXsYn0e0VLSD8mnM68gAsDt9d7PmprGmRVoqHz5OP+bTrgfx6ibGxnA0WeUi1n7Yjhnr+Wfj GTmKG63PdmzzPHEa1uLM9wU6QmTlbEHvD2bda6FrlF2LWK9Yi7xHbCuUDzEXzGFs2jWqu10V0Uy3 6x6aI+x6iLwSfBt8C/s9KlsLGvi2aE4gqpux9rKdcUQ4IJ6dQZ7m+PPx5xM8aa//R+IVK/pDyR0a rlA/w30lhvaOb2jld5Xn85827rsQGWa4WWvCwx4YW2byRo79wV2mxagf3D7WJMpuGzfadNM3Lst1 Rr+RU815KbzcuOj3A4zXe0DPAn1zDfm+ywsZ2ZoPG/bDMaYITICdwOuGl90x0vQuu3tYmdFveYTw R59yqs2glqSG8wzffhBJusk2TU0LU2w6mK6mh+ltBhj7f049jf3G7U6bRrrhsZd2AF+9tAqxIWn6 AnueIajlMrLdeStXn74vJ07ZNP6jpbfpIw3X39X0//ZvrgrulJg08OJ+h1BJeJC0vIu5zvSSyN1q bjd3mrHmQTPFTDMzzVxTbhab5WaVWWc2m+1mjzlgKsxxc9qcl2UwFj5uQrIPPhz+kLRC9iOavh/+ iPRI+KSkh4X7mPRw+BRpRfg/SN8PnyY9Ev5Ev/EXPiNnFaL9n6SHw2dJK8Kfkr4fPkd6JPwn0a4I n5ez90X7M9LD4UrSinAV6fvS6ZoeCfTbhO8HMn6k5KEgRHo4CJNWBAHp+3LXq+mRQHonfKRORPQd 5hPM5C8TkSBKyw8F6TYyQYaNTJBpIyN370QmqCf1HAqybHyC+jYuQQMbl+BrNi5BQxuR4BIbEdmL EpEgx0YkyLURCRppRILGNiLBpTYiQZ6NSNDERaSpi0gzIpLvInKZi0iBi0ihi0jcRaT5F0Rkjllg FpllF41ICxeRr7uIFLmItHQRaeUicjkRae0i0saOmKDYReYKF5m2LjLtdMQECRefK1182ru4XOXi 0sFF5GoXkY4uIte4iHRyEelMRLq4iHzDRaSri8j/cRHp5iJy7V8QkU1mm9ll9ktEjplT5pznexlB dxeRb7qIXOcicr2LSA8XkRuISImLSKmLSE8XkRtdRHq5iHyLiPR2EenjItLXjZhvu8j0c5H5DiOm v4vPTS4+A1x8bnZx+Z62NBjo4vJdF5dBLi63uLjcauPyF0fkeDIig11E/s5FZIiLyPddRIa6iNxG RG53ERnmIjLcReQHLiIjXERGEpFRLiJ3uIjc6SJyl4tImYvID4nIaBeRu11ExriI3ONGzFgXmXsZ MeNcZO5zkRnvInO/jYy+hVP95ls7s+RKEDOj9VGHXA2amiKTkHj1MH3NoPRxstI/EPw4VJR+n+Na po+Hmyay+x3XMn2CcH+P3gOOa5n+IJzq/b3jWvJfny1MW9NJ+qO3GWiGyqo+zkwy09InJmv6h2RN k5I1/ShZ0+RkTQ8la5qSrOnh6prSZwj3D8EDInvMcS3TH4f7e5E94bg/59HUpEePJD16NOnRj5Me TUt69I9Jj6YnPfpJ0qOZSY+eTHo0K+nRT5MeyRXBa+u1lS1Cnq//M9Lcb861OCpX83/Va7f4p9/a vPTzPpt55nkZzatlV7DfnJURHPNyvQKvtdfB6+b19OSO3oSjB43Pfw+Ho+8luUPVnP9/hZsLtz3J vZnkdiS5t+B82WXE/J3K+4cF55D3r0mtXUluN1xIWpFlsv09lNgo+Jj/huBT6PwhRSfX36T2/N+Y kGjO8fcmLf1bktuX5N5OcvuT3DtJ7kCSezfJHYRLM/ofeQUy5tuajqar/zup7Vmp73fU+qz/W9F6 1t8qZwvkfCvSBf4WkS7w30vaOuRikeY/rt/b9sv9RaK52F9qMvxl/jJT31/u/8o08P/JX2ka+qv8 NbKrC7EHzJa5pm/O0P1X1L0D8ReS8bL/sthcKfoh/zX/NdmzyQjwZ/O/h/p/yDoe0th56t62uWjN 8+eZZv58f77JFxuvm8v4X8Jr+V/C7m6fF8XbfxdLS3Uc+eW8wy5kdkdviPb43O7PkxVTdmOyOyyW 2HR3ff17/NiW7LMK4X4G936SO1LNhV5X7T/bLr5jyMFOvcm9kmYjNU3uSkxpMjKS3vrRno/+Zz0v zS+f0mSQiAb4cpucmUiPBG2yQn5eYBK3RTLaROSiPuUa3wuX35T4TqI4RdJ0Yf7kprJ91uPbcgG4 19xtyswPZMr8QLb+ciQKU4yFsw/23dXqxfeDAUXf3Dxi7W+b/POP699xonxKbpfElHDDxBT/XHnI 93y/vtlgftK167SvvdXtzLDj73ZP1Et66oXFpzFXtklcHgndHM68JH793WMeGHvHyFHjCloNu7zg ys6drynoc8ewsXffe/eIcQXX3z12TNsr8xNNrXJO7Zy7x9427o67R19ZmLhM80OXNK7J73/33eMK vnnfuFF3j71j3AOJ/Eb1Ol+TuPLKROKahPzd2qhe+8SV7a+60p1+BR5N8eKpYfFkUzvFq29EnuFP kfuRl/zXNow58o1TfZu0+vnTE4Ykji186bGvf/9s5VO9n/t15bMLC7pN/M7Cny18Ymj7u966bvgD J5aO/92Afac+mP9o0yd+PnXEP/3mrgdvb76nWdcD9b1ZR+dsev2KEfPmjSp6ZkeX4tdjrw4q2lDy 7xndOs0pfqlV58XHb3z4usNT6//LvLL/V52Zx0PZd398jBn7TmXfZeeasQ4hDZKyr3epMLbBMI2x ZhvZkkgpEcZS2anIvqWy76TspEIlWVJSPMOdO/V0v+4/fr/n6fXMPzPnu11nrvM57+/3XJe5bUFo QIaNtM+xuaRSe9VkI24YlTAbMXcmXpL9ldp1FJuNFdSByKNkEvkxeyEB3MTVX2+uXXI+pF7lrVmC QdHXbH8M3qCYveMatZgAyPKSDVqp+igL5QGLzRPrNx1pqG73ESwsF8pUT+0l+ECGV+uKQq5u3OkM HszmxFkfaKt5T5UlCJRQhLeW8Puwhk+AyUnCzyLkAIRbACGTdDd5yCCEZICQGMJ0oge7gMalCRkH sd3Tj91sz8D99+MX+g8aJ9+K4dVZ2oaLy4nsCvMVZMLPfJiXrW3gxDTadnVofFRcq8orgaX3llek 7qcfbrFb+PK0Q1X1eK6iGXpDGKPR2pE3Dg0Yg11UIzJhXao3WAzZ0Q1fepDTzMf5DV/bnS3O42iR VBKRrnPIYIkWYURlfTTjXhNoHdyzbFLgjoRTfg3d9+mlkxu98Wrtoklz7cwj4As/jDqK56o4p/4T HvCtxZBJ8tITK3fHWizfORxpNjErKyUXY9m8NPieKi6oIvFxvpLUC/8XOT7T3umgHheNB32K0ZOa LDkKLlwuIwpTA9yQFznakJbjcsru+tz0duU0mTH9T8w0dDq5zW9jR1hUIq94EbP70klUsAFCyY/9 SQUamXzmUaNN69T2hh2m8PwuGJDyXhlO+pAIACfBAAYnmQo7MPDbJihpEQpWsLkpjBVg3jKoWGks bT2d0e5OeNJlmACGrUZKVkoTB3uMh7v9jmM0f+eYECDwp2Ocu/vtHfhN0U7upFX5jZCa/0iFcr/A wZMl2ogc+QLY8JqIwhGfhnW+tGbtMwu9OrMDMQ9dj5nYrSSBH+o/O+ImK6zuUN8lVE6rWx7sNaZd mxfHYPRYRHIpfYZeiK9XU/izXVI3h/atK3p8SZ0lsoIP9aQDPIb28KrGIJgQY7XiK46q0mTwzQ1R 3dv33cgiU9ar7qGCQ9es0wlh4bF3lioSsrqVbxuF7xONNBgDVkFqK01raoS6iHk3RLaM/GqpTDFN oF28r2PKdU/6iOKlR8v8lYYsF1HtUkNwbY531XrXVI1M2bscjf3yCiNbLNSJoUZR7tC7Cg/OCtea OKolGXRIBsm5hx2m6E3r0YsAu0eAbjZETph+o8JngPARYN2CggiEDqChoCJtaFAoJTn5/wYqGLd8 ZCUj24RAAXLSF8Cz1cAA2Qth6+Dp8gZhTxQvDj8ySDbWksnSQr0HaLe6GSEQUhpF7EqdbcaczS8K 0tu/1FVjgM+0EsVLeJVEfM0/luAL0p9re8M+in7MkBmwDEY2tUV2fDLtaCTWWni8R8XdeVhN6/83 cCHSKEWjRIaM7XvNS5OhtuGYSZFmDaYGQihzhgbJnIxlTBJCkoSkowyZhQydiBMnR6iontU5v+/z +z17va/r+eu5nvOP+rTXXut9732vV7mOd7MqZ68q95gzavk1j6G//XFgfMTgEndri2zFiudnLYPN 9U8senlYafLAyGVA7ULf4I5ju3ZzuUTU03Z4NRlnFhb0aBNltfzTre6up+nKW2Fbt9We7LPXds5w xqPrgrTiE36Vz3cUJbX+5Vg71mK3cImwLpmnB39Zm9fWNmJJWeYYkR6ydMg8p32Px3UY0zNbY6/X OeWNl6JnfMRsAz+Lwr4/hn5butTa490HrV6TKk0ulH1dX1/8UW1T6HJu6UbTrZ1v/z45v9afhP/R pvprZfWvjM3DhZB2nfx+jYo7/bPQ2F1z4rXvHTbOXmwxdNSe+vhpl9XN/TvNeh1qPMNzqI+W0OpD 3VCq8vyYlaGfHd+aNZ4PHXk/usrMNKlau09z8pvmon3TZ3yoNwn2jaDzrhXunjFxYOWcLSvOZG96 vbd65IP6xYP73e5zIGuHWDnv3qYmP4f1p9/0snneZ0/Amby3zqcE/f3KrXPUxnZzPzHdJeLYgCzt HxNLT22fL7zvsODU8IHX31uYTdC09r/yYcuWgbYP+7a6bRH5yCbgWUnlq14ZI58lBZRPvGxd13tE Ve/LERVL716v+Gh9LuC4VVZg47VXIwbuOe5ssf9Ov4NenJdRUuSdV45bI/u92bEnyy2z186LWl1n zLlaervi8vxbrbMVol/14F4G19UW1S5wbNP1/O+3dlnYjBmtZu3ccK99RUxF/7yy9+9mtu55Yvyi +U9jOve2nGVxybwsV88mp+8gIW/x+WazZQ5qa/WuBNz9MaDLx2/bhKmXmia9/mpSfsj+8s/HFi83 let206uY+nhrpyRqZrKZ3bCOi7xDik498Jwzp1U3J50J6h0/jP6gqT//ToTdVOepXaIXbL1aXTCh XeWqxBs5KRem+58W9JbZGJZP7jJrdKd92sc73Hv5ZXP4ILHVsVa3bLlWmzY3nD+QkHD3VJfw/E/T OzRPHjbvQfu+5fFpC5O/F9iNWRpzMHbSvPvfao0+bFmaEc657HPr/9CF/1JSlvBs+6Nd+7VdNv4c yb40DBpw2nXugcXv1jnxtlHd/kyK+HKhy7k5axI++Md2PUQayt52yVYMj3cwshh7aYbjn09/3HYo /eRNkh6+M/x95/ZOD/1CDPZfqb0SEdP3FuNXUnjvfYNJ8h6DDXVNkV0cql4M//SiSVlx621MqY2h z4HOkY+LAtqPz+m47e/oY8P83vbalDvBrPTZN8Wocs+Ry+Yutm58YB71x9BTeV/I/uigOa6FI39m 30/7Oy2yD632yc7+vcnZyUZP0/dGvvI80zsw5ujozu/G79nbivgtePL5TWal812zjcuu9mw4tKXK IG/4/uu9XZ7Xrvrl0LDrINHdF+GuvYiPMlRrO0Z/Zd+ieU8cDg0OKl7bxr33kOzGbl/GGnas3+qQ +3kk8/iZ2s1T/mm3T82bfSDlcPrGzcqPlon3NUdr/HFnyPyp5VfqDY7oCiHMrTfd1Ba2oU197LRc XSZd7D3/1POKvZ+ibjsselRxPG+cy/66dcdKbEaoj52ze/ny/gHnw1ZEtDmx1GUKr5Gku/Pl+Hvu rZf9zMp6t/yWYaZmyqleZl2Cy+75rut3bHNlLpeauDWmWuv+gKTDFjmT+b09519SzmyataK6aLS4 7k+NTyea1id+/it8+pqdJCTgzpd3uz4GZXVof1kzaPv0H34GD4IVU8LZypJN1kn11LeVQWPsJy04 sTR14Jal58zvTOQPB86YbDDBcuGjXqVf2TuUVeWwgrNm50Zc2XDLPj9fq/feZ/svnijS6LHsydt3 RkNn1n7XOTnNLy524IKAeSXJqXlvP9qpT9WxMliS6qw7o/E4O+6S2re9zuuq36f+LBuSNzak+UDg L9OaqlXeRXV61V92sfdGpm+762iq77r175whLgbPHn5d4atXbhB7pnGFz907o+u81HZ+HJEyifml OWF0Sm43X91xGYOrXS+sCD+ujCqjIrVHrVCUHB9EjfCNyJqS2Lw0fcbKkg+jUs+ez/Qf9/hLZtmT oOATKztl9J88JaXtpzNqc83c6z/0K764arJ9WlHu/PgzPs+1AnPat96/Z+Epm3m2ugXjtR8oZvbt 6DxXx/R1xKgVMW3Nj620/1ZVzPx+s1+AOj9vn/+KXH27bbFJT+afNN07s/5XnmLL534x7e4sKz+Q amXt/uFx4YfAcfsXbvruG3Gmzc+P+cnFnw8WJ9aNqNq5/emmVN1p2zQvTp/ls0rjhw4XNPBoYn7U wrdn9BbP8JufVmk4uKP9sgyz6u7d3U72PLr6p51GTYFRhmlYnk9X1yUzgl9O+9vqwK4ZQVu1zYb0 qC+xKouc2jQuydHv4w9Dv1dVbYuK+88r7TCUWjGcfA95/atPeVy/i6eMLpjft71efv/wieCyGnH/ ydGanrd9g+7PD/b0CK7SqD7jNi23sef+iW4uFaXl3lVH1U/laN0Wx8fccxvhNfHmszN/R9fcurN4 ide04PtN3a0HPY8KLWp9rTKqm19CKW1m4m5+qs++ObpJGg7tpo6uu7dZ6X/1z8jsBceuPp/OZY5p O2l22LVos3MmnUJfvzTYsMHhWvvxS86UNkxbu2Wba//rczzbLlz5Q5mWfKn5D/dv2QVZtPbRXtrP Ps19PSvqvXZP9ZN7z9nEFa8jJi/dL91dUvppb5HO4/Gfxoy/bjJ12GX7zskZDYGLnk7IjS7fuLl/ 87bQHmPokn52Vxt1928LXj9Cc/59fy5iRfqf+3M79DKweqn/xiuwqtlJLHQa2vhpVZXFmZOmWlmx +66stbrpZfA0v+NgT9PNfYu0ZrYftppZMeBR08k7P9UPdKpN8olXUz4qOW1yfttMbeL2KVZrX8A5 04cTPtzW9HsQ+nmJU+SSHeqfIsYk9XP9a+nQRXPqPfzUBun1C9/cf8mRA3dy3fv2HpI57Kjj3Poe fl39s96u4YcueLq1rKA4qquH32mdyd867VULcY99Pb5H/+cTEwyXPVP/ePmmy9bfsu0etE3Zt33H mV030g8xg6t6xX4af3pjwJR5AQtrHp38PMjuqG/EzTuzzXclD68Zs9/LVNnxsZu6b/XwCYab5/z2 u/eh6ml7j6WNrdl8fXd5nUJsGt3h4d4Mq4VTSrghi8O8NM+upHbZnln59gsbcaN4zdgjs89dfH8z sOv2QRkanr99yK7wC0inNjzI6ZOlqRXdcdTmHLXeVm00Eq+cHv3z4KJfTSW2e++1y2zsHEIo415i +E+dGzs089S37jZXXvhJbH9P/qvLwDi1py8vte/Y4KDf2mrWAJcJswb4he9P0v15zGmn8m6Z/lVv +/y5TwwH79I9sP2OyTXd+23fDAnaPLBIp0BvcOtrIc3D1kww+Tl8bfMi2xs/fez3hJ53C3Rs2h/a rkOvNurd4lddyGvlqjvHKvlYuLvjgNVOXwsap/NTp3sdcjOs71fkefaYXvM9Sw+bbn8d8rr6c6HD k8aFpq8s9s3+1mZS9q4/HqgHeiycO/Rpya3sie9+DZv5q73LgveHCxIyEizS33/cP4ec3Vxbqb39 7/MDJiUHpo++827g0jTvjlG2m/cc3bXZud5pzrkN9DCr0FY+d9596D05UH9k/ajlHgPDfE9GzKvp 7h5uqYzeV3Vj76EHF+8MuLyzOxtEGwT0WrQ7OKQq2nHcSNf4cqGAEhbn1s/I7X93zG8ZExYf9NLP Lhz17Ljx0qipSRqbPm27N3NcvMm0gw53hy6LbRib29k2ROdU2d7yRoPxHqeeZcab7NoQuHZ1/coJ iic/dk3IH3Y1/FDvtOacnivKVy23tra+Mopq7Jmf574k69Wr1omJGfWueoaFI8um67fS1s2v9NZQ v+/ZcLZmnDLspYthps3lk7aV1aFPnyQMqtzyeHxc2ZaipPTKRbeTq6dq7tmh1b3gwqMjYVndQvrF RFloV6dWlua+eDzi3OZ3IQGhOfuXHFms7V+Y6TOJNvSNu/XJPdc2t+1gSjxWuj3ueLCO8c8tUWrD Uzt+2j36WdHP+RMDrG4tG7btoN26FcudIkcu8n3l7fMi0SJ8/Dn18nExv58+uvzrgwjy2XPLwazG mOHvhxzoOm1HfCe/Ru/WOjYDx66ZUbwywdNCTW/ywSWBX+uXWPx2pOrs62mznDbTL+uXtjl5KUtv 5+CG2U8saodqLUgYt/2jZpjhGCtLMYG/HnV9lUOQUbHSbrtF1IPr813+WmN3vN2pY4cOZyfdDB/v fPj8kXrdPSFrm30+FWd9iL7+Z3mrRq3sB2dKdDT9g2cuCJ/v7zPvnw9DfGfraBKKCJYKy38+drdk 3C0pXvCwtCQCJX1IUR6WHpb/x4PF/zzYzs5mypJQfxu3Sf4BNpNnLfW3bPmqjau7JbFkLKUDbSaF hIRLnygsJ9mMCg4IsSQK9t9PnNztBFopPXy4MHyYM0MPZZxE52GCKBDRWXByUgoKpcP//RHSGZSz 5ob7z7dRzvUJ93fy9wuZ6W8zxj84MDzIkmJo2sFBR/M/cSP2sM8W5z72a3Pzy9eB7lute8RwzrM2 9zg4lEt6NOr7vmnb11ZvT7pVbrss4K+9nZ8tc9x2u+LipfIrRx2XXsn46fDe88lfTVEZf/76+HF2 c1Mjf645+cmjgTOHdY/S1FF2Mb1b8GLYVj/NsYsLn0XP07Wea3tY8XHPtaq86AYumiQbFerd1KrL UfhQnv3G5F4KjdSbq+4oHg98s3ZT9O+Xugza55E9c4ZP2e1o23U+Q30et4+2Xdz3BXuipuF5tGjr Pe5N/EmtkPLpdcdt45Z/bpdar/wa3yX8any012Cj5fZ+3WedtnXoO8A1IUGr+K91S6J3VKofeaQT 7Tm+y1K9axXRDm20ooqX3fXW7vt1c6KrkfKkbmrDYc2KSym5+WOqtMczpw0ybMbMnrJr6hGrnbrr S8NTPyjpuADj2+Yx7zV3mnh46q6zo7rs7xxgZj/4XM3nwdl6IZ3LbTsldHlnPyOiee+1H42ajnFu I9fknI/Wts6y7jZzTWWTdZZj1iJjaXnOrHgZOnfV7TkPu9Y2/zyf3jhzfZviY4v87pnHHuhu6h02 YJ3zacMdBZ2C4pRuprfvGY7N1N7xbct5anZ859Otp/uIWUN+G5CwPfNM++dlx/SW+nXOGmqTvua8 W+cTB7uW+S0Md2ofruwT7myUvpG91/VlJvd42Pja/Jyq2E+ZA88P/dbU4GMfkpMTYqVd0PC0VSNp Zebrp33tyNO2wxXG1xWGj7qfMzmfHzrl7MVei/K/P+1g67vWyOvylb2k0yUf1+rVE43jl5pvaJPp +L3gs/Eae0WXZX421eujTuvpXhPMN1qFWutevSqYr39jvSdua2iP3hXG5vEGig43K9zG5IcZJ2zM bvXer9+d60mC+uTIPx4lLjQdd8NE6BpYMWBP7IJQ/UEFN7KNfrwOfhFdrDDY6T34yJtJJfmPslvv rOg3Y2NyqFXG1W/ZXZ68afdi47TsNnwF92K1e5jtvmtbI1onVJAXCT8jcx5dbbIOqFCzi2v/paPF 1Qd1essL9Oos7r41sUt4X9PDM988d9POmn6ehf0jdELe6pRcXxahteALV371Ul0nr9dRkWv1aro7 FAbWtd3/dkFk/Kmarnk3+OgpiQ2dHX3UlhdG/lp95YtZU8FfdW1WLKnqF9ls7HL4l03TwtRgZcWZ DUsWZ8Ryyr6p8Yl3N8wKp+9cC1u3afKCLCHHZGz8EaVzasq0Lr6mfeqs/bdRph2vxnkr252lDLmP Zs/iNUZMt1qTeHXDrJ5Ujknn+EjpSbbp523wbUuvlj4NVipavloU+J+vvkutKv3h1tqp71mLPb+s tPXXHZtuaBNjxJYMWWB7baTCKqv0tkbAQ8Vok8oYasS51OTSQo2AP+gck41xTkqzyV2njXsetnzU ty1Z5G+T+rhIZQ+rXYl3g/weKhqM+ly09qy16WQyL45TBlllTXyl4TVTUWY8L85UeTElZWLpyJmG 3GxjNq7GWZG6Qj8vyK/WJsfkZVyW8k5K3sRXRd5HhjSnSPNjQWtt/jZ5E2utnG4VU/q8aJoT2WI+ T0r8MWXFxNyRHlmkwehGbLDyS8q6xKvWrocGNRg1xtY4m0nPWTJyPjMoxuh4rLZ0XYmlt4Ncau0b 9v080FiafcyHGZRjEh/bJD0wXv/Bhlkt1zItZoDzo5SwidcHpPt86j89yt+JpBi/kV4HHavIxKtV XlnkbZcbsYXOZ3osTPqzPi0krdD5S0py6e2WnJOk06SMeNEjeGJukXdP6r7prLGPHDfGuQxL73Qm 9MO91zVn3NNKWxf7mjBrCyv7WMXHBgcsP7mk8cdA/vFnrd1+EweslnZnrM+oAZt6ZRruPkB2H+wr 7b70dYuCYne4lbetnvuwXf/UztP91NM3bM/sN3Vo+7mr3jw1T/YZm75qU9XqcVVxGVWrPletO3e6 y2Nnr1qnkPQ1nlVrhj7taOZtXzvCMT1B7alGG6I9/DRp52cwN6b7U0133zlz/VovIoO7Hn0zpXqt tJ1bdqi+1QR7N/b4UW++OqavcexL0umbcXSp8ZrGTJvv+eVPDZb5dDOPGZ7pqHtNTejYviLIPPp6 aE/dm/rG6w2IyU1vu003wnatHLVrQ0VY63GFo3ZtXBDW7k5hkqD1/nWPPeu1FJ3fVwwryb+RbbjT 2/RIhemM+GJzm0eM58biMPWMa2siWv2oGDwj1jasf7C0Nzvwr5Uv4p6HmQW80X0Rfym02+cb9hHH Nn+c8ndPi6vXIwzPfhEsrhtE6I5/Y2IXH/jF1DP/a0QHm7edc+NcidGCmsHlBWYRZiFvukbG/agZ VH7TLnKDXo1+XuFRaT9W0JEbbWo6p72LjA2psc+7nlCn5vKoKT/yV5xXZqsrb1x/BRemrWyMdvyi 11R4pe6UV8e8Kre2Z+dqzqnyqrUxNXoT+9C5r1WMfp61Z1ta2itx2soTPZ4k/jlyySG7BtfvYeyh QZOMWjalwmphaWGV11rpjf1sYPKlMteHHfi0LsdjnZQVPbz1L2xwX2uTYiw9cIf9BB1RelKd1G0T czf4GtrMNt4YV+hc0SMyMWeDuxO5ZnQ4Ls3ZIXWdfl6Rd63NNekKtg8ZoJaSfHrQBm2lod+Hjofj HjqPSgmTtotPy9cDb2h4hdOzjbvGFh7ebR4vbYAKaS/d2OBeMDDGKD422/lmSrz/Atfkpo8bDW0a pKd7K72Tw/S3aXi1bP4b0qd3eiyU9o/HHwMmGZnEtcRdKO2AgPROKStKr7j1cqrzdel0YotbmpOO 1ZrSK0EzaqU9ulFaB8PUbYk5Ldc4241bfu7u2d39pFzbPTx0SPyMETqpyROvW/tPYdK6sNJdoK6H dKiGtDotKxrcsslKH27wnan4aGYiPZNZ6oPEsxpeDxUufZ3JbGmVrJWGLWte5J1Fyoxbdm5zSnxp YctGbtnxu3bc9pg3OO3UVgtnhVXMxFtBflnSTxgt9x7DlpvW//i0eFHG9+lpW7PfOrezSkx8PHLm uVHSzUW61frfdF2miI/ldkTN+FQYbaR+IcTD1aPO3VCntNUjr0E7C966af92gOwonBS09l1QTO+g dZUTPCrc2w28pznwdOuyAzmbLnSa7uf80K9r+rrzbuonUroOTrFPK1w4xLUF0KGLWwDVsT8tAapX e81yiuv7hhS+wdtDO7+han3TUw0z3zZTViSYrztovHpsprRLJ8+damusTOh706nRIJpkWCTMcxUW m9+68b7d5BEDD70JfmWk3KFVojMiyuVYyLS63GkeL5tbjUwLvAm/+YyY7x+go6mQvnOkFNKf//5H FJwlx7I0axnwv2cKwlv+86dl8H8/juJkM5oQ2YxTyB5HM4J8xjKsbMaDY0VaIZ8JtMqMIkShei0U oeWPYxiOkc04mpLNBE42Y4nsWJpS8KprRUvLq3peaUbLZ7QgP5bhVHPQFCfKjxVafpBQnTGyGa2Q rYs041XXnqbplp81VGYcJXs+kciziZQ8h8iKqq8lw9Ky9wHDsqx8xouqrznDikT1mhmOYlWvj6VF WTaWIQrV15JlKEr1mlmGZlWzsQwvO5YjPKP6OI4IvOo1c0QUVa+Po+T7iKMoVvV9xUnvDdl5KVa2 PziKo+XH8rL3ECdtVdVjeeltoLpWvEKQnZcnCoXqe4MnhFZdP16KpnpeXtqDqmvAE1b2WvJEYGTn kLa+6pryIiN73XiRla0fL3KC7FpEUbZ/BVpQyGYMkd3XBJGXHysKoupaidJtQvWaRenGproG0ruU V80r8vL7n8gLsvuGKIVTvT5RUMjWWRQo2WsuCiyvcs1EId3XWNmMUr3nkJZNQ2QzVvV1k2ac6j1R mgkK+TlE1WwSRgpWdqy0uWTHSm9o+bEco7L2hEhvF042Y1Rfc2nGqhogzQRa9bySKar3NWnGqt4n W2aq9yZpxqves1tmqu+hFp1VbZRmtPwc0uZXXStKolz1NZK2vmztpdVTvccSmmOI6rXQHCeqnoNR cLL7bsvy87LvI4hCADNRPiMKMCNgRoEZDWYMmLFgJv/ehxCQg4AcBOSgQA4K5KBADgrkoEAOCuSg QA4K5KBADgrkoEEOGuSgQQ4a5KBBDhrkoEEOGuSgQQ4a5GBADgbkYEAOBuRgQA4G5GBADgbkYEAO BuRgQQ4W5GBBDhbkYEEOFuRgQQ4W5GBBDhbk4EAODuTgQA4O5OBADg7k4EAODuTgQA4O5OBBDh7k 4EEOHuTgQQ4e5OBBDh7k4EEOHuQQQA4B5BBADgHkEEAOAeQQQA4B5BBADgHkEEEOEeQQQQ4R5BBB DhHkEEEOEeQQQQ5RnoNSyHNQCnkOSiHP0fIzp3wmz0Ep5Dko8HcAFPCcAp5TwHMKeE4BzyngOQU8 p4DnFPCcAp5TwHMKeE4BzyngOQU8p4DnFPCcAp5TwHMKeE4BzyngOQU8p4DnFPCcAp5TwHMKeE7R IAfwnAKeU8BzCnhOAc8p4DkFPKeA5xTwnAKeU8BzCnhOAc8p4DkFPKeA5xTwnAKeU8BzCnhOAc8p 4DkFPKeA5xTwnAKeU8BzCnhOAc8p4DkFPKeA5xTwnAKeU8BzCnhOAc8p4DkFPKeA5xTwnAKeU8Bz CnhOAc8p4DkFPKeA5xTwnAKeU8BzCnhOAc8p4DkFPKeA5xTwnAKeU8BzCnhOAc8p4DkFPKeA5zTw nAae08BzGnhOA89p4DkNPKeB5zTwnAae08BzGnhOA89p4DkNPKeB5zTwnAae08BzGnhOA89p4DkN PKeB5zTwnAae08BzGnhOA89p4DkNPKeB5zTwnAae08BzmgY5gOc08JwGntPAcxp4TgPPaeA5DTyn gec08JwGntPAcxp4TgPPaeA5DTyngec08JwGntPAcxp4TgPPaeA5DTyngec08JwGntPAcxp4TgPP aeA5DTyngec08JwGntPAcxp4TgPPaeA5DTyngec08JwGntPAcxp4TgPPaeA5DTyngec08JwGntPA cxp4TgPPaeA5DTyngec08JwGntPAcxp4TgPPaeA5DTxngOcM8JwBnjPAcwZ4zgDPGeA5AzxngOcM 8JwBnjPAcwZ4zgDPGeA5AzxngOcM8JwBnjPAcwZ4zgDPGeA5AzxngOcM8JwBnjPAcwZ4zgDPGeA5 AzxngOcM8JwBnjM0yAE8Z4DnDPCcAZ4zwHMGeM4AzxngOQM8Z4DnDPCcAZ4zwHMGeM4AzxngOQM8 Z4DnDPCcAZ4zwHMGeM4AzxngOQM8Z4DnDPCcAZ4zwHMGeM4AzxngOQM8Z4DnDPCcAZ4zwHMGeM4A zxngOQM8Z4DnDPCcAZ4zwHMGeM4AzxngOQM8Z4DnDPCcAZ4zwHMGeM4AzxngOQM8Z4DnDPCcAZ4z wHMGeM4AzxngOQs8Z4HnLPCcBZ6zwHMWeM4Cz1ngOQs8Z4HnLPCcBZ6zwHMWeM4Cz1ngOQs8Z4Hn LPCcBZ6zwHMWeM4Cz1ngOQs8Z4HnLPCcBZ6zwHMWeM4Cz1ngOQs8Z4HnLPC85TP5DOQAnrPAcxZ4 zgLPWeA5Czxngecs8JwFnrPAcxZ4zgLPWeA5Czxngecs8JwFnrPAcxZ4zgLPWeA5Czxngecs8JwF nrPAcxZ4zgLPWeA5Czxngecs8JwFnrPAcxZ4zgLPWeA5Czxngecs8JwFnrPAcxZ4zgLPWeA5Czxn gecs8JwFnrPAcxZ4zgLPWeA5Czxngecs8JwFnrPAcxZ4zgLPWeA5Czxngecc8JwDnnPAcw54zgHP OeA5BzzngOcc8JwDnnPAcw54zgHPOeA5BzzngOcc8JwDnnPAcw54zgHPOeA5BzzngOcc8JwDnnPA cw54zgHPOeA5BzzngOcc8JwDnnPAc44GOYDnHPCcA55zwHMOeM4BzzngOQc854DnHPCcA55zwHMO eM4BzzngOQc854DnHPCcA55zwHMOeM4BzzngOQc854DnHPCcA55zwHMOeM4BzzngOQc854DnHPCc A55zwHMOeM4BzzngOQc854DnHPCcA55zwHMOeM4BzzngOQc854DnHPCcA55zwHMOeM4BzzngOQc8 54DnHPCcA55zwHMOeM4BzzngOQc854HnPPCcB57zwHMeeM4Dz3ngOQ8854HnPPCcB57zwHMeeM4D z3ngOQ8854HnPPCcB57zwHMeeM4Dz3ngOQ8854HnPPCcB57zwHMeeM4Dz3ngOQ8854HnPPCcB57z NMgBPOeB5zzwnAee88BzHnjOA8954DkPPOeB5zzwnAee88BzHnjOA8954DkPPOeB5zzwnAee88Bz HnjOA8954DkPPOeB5zzwnAee88BzHnjOA8954DkPPOeB5zzwnAee88BzHnjOA8954DkPPOeB5zzw nAee88BzHnjOA8954DkPPOeB5zzwnAee88BzHnjOA8954DkPPOeB5zzwnAee88BzHnjOA8954LkA PBeA5wLwXACeC8BzAXguAM8F4LkAPBeA5wLwXACeC8BzAXguAM8F4LkAPBeA5wLwXACeC8BzAXgu AM8F4LkAPBeA5wLwXACeC8BzAXguAM8F4LkAPBeA5wLwvOXfgspnIAfwXACeC8BzAXguAM8F4LkA PBeA5wLwXACeC8BzAXguAM8F4LkAPBeA5wLwXACeC8BzAXguAM8F4LkAPBeA5wLwXACeC8BzAXgu AM8F4LkAPBeA5wLwXACeC8BzAXguAM8F4LkAPBeA5wLwXACeC8BzAXguAM8F4LkAPBeA5wLwXACe C8BzAXguAM8F4LkAPBeA5wLwXACeC8BzAXguAM8F4LkAPBeB5yLwXASei8BzEXguAs9F4LkIPBeB 5yLwXASei8BzEXguAs9F4LkIPBeB5yLwXASei8BzEXguAs9F4LkIPBeB5yLwXASei8BzEXguAs9F 4LkIPBeB5yLwXASeizTIATwXgeci8FwEnovAcxF4LgLPReC5CDwXgeci8FwEnovAcxF4LgLPReC5 CDwXgeci8FwEnovAcxF4LgLPReC5CDwXgeci8FwEnovAcxF4LgLPReC5CDwXgeci8FwEnovAcxF4 LgLPReC5CDwXgeci8FwEnovAcxF4LgLPReC5CDwXgeci8FwEnovAcxF4LgLPReC5CDwXgeci8FwE novAcxF4LgLPRbnnRCH3XJrJckgzWQ5pJsshzWQ5pJkshzST5ZBmshzSTJbjn24q2UzuuTQDOeSe SzOQQ+65NAM55J4ThdxzaQZyyD0nCrnn0gzkkHsuzUAOuefSDOSQey7NQA6559IM5JB7Ls1ADrnn 0gzkkHsuzUAOuefSDOSQey7NQA6559IM5JB7Ls1ADrnnRCH3XJqBHHLPpRnIIfecKOSet7SAgRnI Ife8pRkMzEAOuedEIfe8pS0MzEAOuectbWFgBnLIPZdmIIfc85amMTADOeSeSzOQQ+65NAM55J5L M5BD7jlRyD2XZiCH3HNpBnLIPScKuefSDOSQey7NQA6559IM5JB7Ls1ADrnn0gzkkHsuzUAOuefS DOSQey7NQA6559IM5JB7Ls3kOQjwnADPCfCcAM8J8JwAz0GnLAH9cAT0wxHQD0dAPxwB/XAE9MMR 0A9HQD8cAf1wBPTDEdAPR0A/HAH9cAT0wxHQD0dAPxwB/XAE9MMR0A9HQD8cAf1wBPTDEdAPR0A/ HAH9cAT0wxHQD0dAPxwB/XAE9MMR0A9HQD8cAf1wBPTDEdAPR0A/HAH9cAT0wxHQD0dAPxwB/XAE 9MMR0A9HQD8cAf1wBPTDEdAPR0A/HAH9cAT0wxHQD0dAPxwB/XAE9MMR0A9HQD8cAf1wBPTDEdAP R0A/HAH9cAT0wxHQD0dAPxwB/XAE9MMR0A9HQD8cAf1wBPTDEdAPR0A/HAH9cAT0wxHQD0dAPxwB /XAE9MMR0A9HQD8cAf1wBPTDEdAPR0A/HAH9cAT0wxHQD0dAPxwB/XAE9MMR0A9HQD8cAf1wBPTD EdAPR0A/HAH9cAT0wxHQD0dQP5xC9VqkG0TL/xf071f+0xXLci3fl6jOWnoNVGey7mNps8n65Vtm qr3O0oxXPQclXbFql7c0E1X7iynqn3uO6qzl377+nzOWpVS71Vtm/7MjOXy+z6y5/vP/+VVN//UL mijF//vfyvTvr13ymR/+b7s/xfIiTeto9urlPF7535X/iv9v12czYb7/Ist/L+uf3141OXye5b9r p3rpAsWI3H9d+v8CUEsDBBQAAAAIACt9ZUDK6fMeYkoBAIReAQBPAAAAU0U0MygxMilJbmZvMDNf RHJhZnQgVUsgcmVndWxhdG9yeSByZXF1aXJlbWVudHMgZm9yIFdTRCBpbiB0aGUgVUhGIFRWIGJh bmRzLnBkZty5ZVgcWbcGmoTgEkiQYKGDu7u7uzvBnUYaghM8uLu7u2uCuwe3ENwJ7twmGcnMN2fO d557f90uqmtX7bX38rXeLohkBYWp6KiZEOGIasAfRDg6AC0AqGeGCMfJSaPoZG1II6AL0rUAGtPI 6hob2gHowdPyNJK6VsakhlZUIvxkABoFkK29PkjR1tBQHggEAeh/kkjp2pqLWRkBwds8Dg0NAGAy Q27wBxHO0MrgBwv6v/P6wYNGAGhvBQLQ0UiYGthpABget9MC/LqO4Z/Wgb9sDcHrfrKXN7QD2tvq G9qBSYSBVqDHCx2A6cecMCOA7ieVMBOAjvHniBlAx/Y44uamUZXRMzPUf1wiZQjSZQGw/PZc1hao r2AI0qAB24xG0dARRCNmCWbM//Mi8PMi9igqeKGBqS4/0FEDvJQWwMTGRM1AD2BlpKNmo9cCgBW0 AoFFtQP85C1iC7S3/l2VHzc0CjSKtrpWdtaPKuk70Qgo0AgaOpjqG8qL8IN3V9TVswOT/DT8T7Xt ALS/WojxFwsJm1qADG1phC10QYaChvpAA0MaSUMrY5AJgJ6WlflxlR3I1lDXEhHOMblGfd5qXvSl G8tXjy0R23KzisM1AAxtQNSiBfMMAv4IJ+EJQCK6Sy1o8GO199VNiVkk/aGiYDfz8/mdAwUlt2tF +4ABnVC1ag0g/fG3ruM4Sg3g+Uqsq3ZpZJkHpYqHB2Ic3vSFXPNwJqH7VWRzo5OUdklpWSwQUze5 2GFaJdjxaOjj9/wRIjrPTKglNk0dp7U3OvdObmezbw/wDM4Od4tYaBOar44Sb+3dlIbfPTWMtF5V SEMpWXkhFrpyNnnIE/FamIYn0xJP+1PTW23dZ5JGX15TUdWKQGy4JL4WyxmO0zeAgKLk8ZmdC0/y uVVPV8bQHwlKMRY7qLdgH+aS9iUjyVq1f+9Rw5MzwQ+lGGTLeALRf1Y+cTs7fEJ8MUPWkMkt6Uf7 fXz4fUVT+PCwlgnJW+qT5JImZOlKG8MJ374tP7nh3a005L2Qpq+hqDrJTt+je0wAu44WVjATXl8Z BGjHvC6/DYc8tfrytjkBpd4E/2MDihdx++AtFXK1CBEe15pv6tYHOfvxV1b5B2zf9K7S7F1lkmm1 F9xtNRoZ66XDWoQ7bCA2HLkNW07TyltHNHbrLk5dpi4KSHZh3EOfiPBuviWBD3Nuh6mcc3WovEs+ 4J16qb2YwuyZW3wIAdzZxdMkTkaOZgZh9PfhA3i91E0m4xVrbKQF4l8knPRcqY1KQ0cG6t2FUesP X8OECm8Xp/IuMdnnewzuwHsDmJ44amDmPbEug6XtejqprcM45bHiVDYzoKYFswHKaGk1saQHbs6Q PZG/V4XOzmgtLXl4GurF9ULVaKhQD0ERc3wizK5bZehsRZDSy0kB/uK5Um6ovM4npYEBNVviCy/i I5O3Ol9RJzt5Q1VK6N2tyRNV54iivZqhM4fyj0aouatl0IjlIM3tdi7ic+YjdtNY8a+hqF8b2oCq hjUNJ7ADxlGjZglav/Ls4a5uane7snC+Ys3yW8LDzX2GoBeKj2DBig0XVrDA2mN8jpnPp3/b6Jtq Bvnu2ZM93lfpbkd5xXjVU3hyFQNtrFGOafe6w9b1h4zTm9oabcQAmEnheDu3vnyEYT3XmAH3NsP5 uILebFLpJOg4khF9dI+LiSpPB9Ero2nAUBAf5YdnLVy5me/X+ZvtwoH9vryvOLoZiaTnniRX81+k fEunshVQEDGQhq3e/7JCfv06YLLumDd9+ExiAfJrMFnhLdKRTcHAWCrmFDbxRs2klfXxxyUmi5pp lua0jv39c7dDp3oYFLg0pE6G8ez2KixUl7b4lqULwbxFWpxUTkmCdXNQuRjBQCaH6xUDKGRdfkoi O+gI86Qi70s3nqH8UxWLIevy/lKijpoEdMUnhxnxF9bmGQewAEsM9ffsszWQgkFBBEeTgQUGgMH8 E92aMPlKKeYwaM4MG+EDreWA1PboYMV4SekKf3OBkO3yzTdJpWERTR84jh1CiGN26MzCE/XCP3fr xfHJNUss+B7ivDDHaHqpPKf3jEf/fEvs/Il/yE755vyS1mtogqgICKyqbqu+ZeoLAL/1yWdrIptE 3TzC/j3Yfv7IfUsYYOhX75TyAazzuGiDGUP2qMh9vaNn4rbz0GWOjghj58kwL3Yp2Z5hglZWUFz4 tvp1wlCCFYbfBldF79ES08qyrs1zP/OYKKvXwD79wt7aNZ1n4r16NB0tSNdXPp0GvXGuc3Q9NblK eZJ3SRmTzec/QGEwA1yzQkTvnG9n9qz1hODCXu/DOauW00SyUKLtUXaCMlbc8ysmwhVXNiGN6nqz H5Es0yuEPddUvuA78/KLVfFdFY6tpne5ccbZvNW381OkvpczmgmH+xkf+0/GP0YLnzMLReLOCpON P9BJDejPYbJDKiXADa+yAuOeLOOxosEIFj4/QNofafX1re1a+9Q7uAj1LAKnF2MT3en+PgiekHiX XlmDs3tNVZMAr51EIi44O7aXdc/D0OS8D0L2TSznhqS/U93R4QUoeDlZ6hvLlwP595c3SC5N77bf FPEfcFr0XT+1lIpKpWqHX2jQ6NycwW8eq6n72An7kmF+00sjVfyd1kc9/ZzTj/aws+qm7bqAkh49 HbmcI5PVwwZ5T07Ldxut7Exdxc+wr985WdhkvT4pJ2Isx6w4As0Uz7yiHTK1tvq8QUoUrQyjCjsT YJAdTUeK/65qgq5fqojwOaH4mO7w6mKa/ucocigk9QNI3M+6NutkW5HJ48f3oEgZrHj5Y5eE8d66 /HTeWQB73t7KRH8wr8IsWgsnLI8QWfkD7Kt9upBIx8FYMUjPL09bZ2sNo3knbCsjou3TQ6Hc5cVj ukGZ/K03Pv1HUA6QEvFGuNpv3mPKOmzYYFRl03ahlLsv0LWtsT2USnLW3nL6ZFPKpx0ROffCK20v cPmACEu/ZSL4vPj6/CwXeY9C8VSqA9bdwKxs4Xlrt0UDaQ3l8k4ulXspWgkgFMs6QvE9ZnqTl43f 06jOBsIXJqAWa5ywW0JLo+4m1PeRyehum0gL362ySbuqshmA3E+szWwZi4o8/ftQE82xE+WRzht9 lg82EIZwTTfKPzjnXnuyxAqKAZc3nmU/yV9nCm+d80nSs+y7mQ+JS6crPaoqwJqz9vi4+xImIavL +hS7zwBkOyLgLzkf5v8dhfgT46uymqvF+qouR7rokYJ8At2y5xdX7+CVNOjf63QS89v1lSQrV1ha 1nQFYl4sLd1SXHxudk2bhGlDNDMdgqH0fLGeQ32BC3elJufGl1OQdX6C7Eua/wyTSVRAjQxtOGFe PzuyUiyE4blsZWleq19aaYwnojZ2VmH/uuoy9+HsG3OqKx7+vN6eHyjjd8jwO+Bg+jskewRdNAr2 eqDHG0Uw9PvxVFrXEjxFR8Ova2f4g0LR1NLQjoCeVtrwPfhbHmipa0UjZAUGKaZWxjQqplZ8Vnam f9w/rhA0tNO3NbUGAW0BzD+Rm6mtHUjARNcWwEAPBqa/jeno6cDLDUAmdgBm5p/47U9hmf9J2D83 /nH7Q9J/kg6Mo4ztHnmJgXGxqT6flbGFIYCWhs9O/xF9srLR0Tzu9DimoqdjBsNna1FDU2MTEICZ jYGGz8H4h1QARlo6MC52/HlDz8TM+oOpyk9KRlpaGtXfVtEz0YLhmu6j/gBGejDmM7RUBhP8IOf/ gTCpwKt/8ALjOVraRzZ/Rcssf9f2N3z7h3eEgbaW/wiYwZD1p4kZAHS0P40IRp/8f+Baeno2anrw HB0tNRsdGNdK6YJsTR/nqBnoGOl+kNBSMzOy0T0anBZM8C9QlJHhr0jUXlZKopMWuQX6GG8jHofd iFhsQrtOsS1KFBgErbaDXw9Xc+9hrI7RtEWsG3nlTHPi4M3EUoeAqGvGgEAzhfx89jkdftwzHLq6 5x19iR/YaHFGwjjMz0svOktPlNBPnne0MLXwHqDPwHT2Zmh+RifS+yia7QNvAfFUrXLCZpcrFba3 5WoupB90FJJEkrbo73xopk2Up7vFmcPkfoyqcnKWt6eWotai83HEfF+deQT+5HLZEbG7vlAZEoGH oi86JtlSUHFNvXNQVaERP9eBFn5B97DxXncGWVtcMcgnwJN+46VnAG01QLzOViqL6TgFuAqrnfSP acX6f0kr+j/Tis/WVNeCkh9oYfBfZxPb37KJmeXPbGJm+yOZWP6eTGz/bTL9ItO/5xAbLdOvOUT7 Sw6x0LP+kkMsbL/kEDP9X3KI5X/IIQaG33OI5dccAq/+wetnDoHZ/DWHfoT/f+0Ihr854r/2AR3d v5U0OpY/vMD6dy/Q/cfv9n91w/9XHmD8tYoxMzP9N1XsTw8w/sUDzEz/6oH/eFnwbx5g/NcO839L DDqG/9IpbP/hlP94UfF/aDT/Tab8W7dhYfnFT/Qsv3Ybpv8qU/7sNvR/6TZMf+k2LCx/8xPjv/sJ /EX7f3GOmAFYOVOQE5Xob5oa6FqBHtfaAeh+vs5RBCpZmT72ErAm/+GBP3CJBuBHF5LXAvwy+ysQ +N9l+l0HATHBR8JHVeh/URH8WBEoIiYopWv9h9Q0girg1gk2MHhSwckObM7Hd2IAOpafIfW3QPvZ bVXAwf8fevzaxGVsDQxtwbYh/Z0LGQDcvo1Nwc3DiZQPvMDw8a2cvbW1haHlY2T85c0Q3T+2lP// xeSPaTDeMKQHsND9hzn/sWn9T8WE+Zdyzi8gKCREIaUAtoiCiaGFBfgqaGEM/qb/r+sJPe2/1BPw +LdywsLwd6np/7EJ/WON/xcx/917P4L1T/fRsvxa+sH1/ZfSz/iL++jo/rX0/2O9B3vqkQE4jcGO A+/9V58x/of2f+lwpiALQ1IAGQ2fPcgEaEsKZmCkawUAA1CQnR3QioxGAIyjwCYhvX94IvXE9In+ E9snwCd24NPoCehJ6RPAExnwyOjHjCH4TgU8Y/vEADyif0ILPlh+28EUaCUIxqqkguz0tHT0tAy0 THRMjOABOMGkgAb/05SsLdDAXt/w/wX3v7zt/o/WDsbvCiBLGmkAI8PPMAIwPNr/fwTXzMyMfwXX k8oDZth0qIvQxy/ez5YKlxVB+/CmJ+nBdJ8Pg1b8MqhYpa1JRm/dwoSPO7Gy6edLGVvtQAc3wUoA PnUUCfnUZqJ1UTOpuXCQ31G2IACSA2JTFFJmrn04GwLB8dQgm/A1AgV9+stn6N9M6Do/vJZCR+4w IBAMPwsNJoGutllL7iA6finpyYlNH+v6Tlb2s9YCLDUyg1jG85WWaBj0txKmKDh74l7t3049i3mh aG0/mxKpCY3D+CJb46sH3UC5KkcZwCb3BAwED+rHo7uiD6NaM6dTk8c+Q3uytOoP9UmE+v37RXZ0 qdHceQcdmR6dPPebk6O59y96ViY2rWpIvoc0nr0YR7Hz8HBR0J5tfSM9sWsldAzxjd4AV01xb4zY AVYkZszo8mDg4wVV+hTk4TPqQb4BMp0PSRGDOQD7ibqW85I+RT5N5/dSzB5D3RL17e2S8umzAohh K63HlkXIcpfMQ1MJmQRWsCpVBK+suVVbY8z6CaFRLqq6NAf18/n7G+j2d3zNqdW0IjAxg3xLJGyM MJg4i9obivUMtpvZxizg6Hufoz7LRDmDiHwaA4B1epktjOLpziuPXIGlhK4R2OUXb4KpwmFqFT25 wzvkbVZrphwRbY1UE/iJsILDled8lXjzalNRIiLUQFL3Noqk5L19ZINJy7lSMM3LmqGpeT14e3vS TYMhpuourMQd2eG+RCJDlVpA3/tAFhf1KVgrajk1S4UUffuEM8sHxuAQKdz1hf5qCmYZ+dZal54L c47k5VS/xYZDFhoagTru5JuJS4bhI1KyGxy+U44Wt70HhKJ7t+tQrlauh6WeTxjfOrr2zGM/0aht 5RHwRZoZtQ3sRPsSSfBrDzcjPYxEsIcbccgYpuYV4NWxeDwVIn0S9Y+/gJj/6NEaj6UE8NeDgYHh x/n7/a8UTLQ/z38/WOjpAcxg9MzExPzb3c/9WH78H4v2L6NHmkfaxyePJxsj4z/sCK6MP/j+en3c 83d56FlYf5y/j1l+G/96/tCLle0Pusfzpxzg0a8QhvkPYKDxGwEzM8tfCFj/JHjc7X+zx39z/MHo H2f/fM5MR/c/7vHT3j/983P8eND/ZuvHK+ujzcAzv8/+bsMfNmFi/ouSf/Tz/y1I/pz9u8n/Hi6/ htWfx49w+UPBRxfR/nAg7R/B8LvSfwbUf+7yB38wzY8w+e36R5iA7x/V/CnD4+gPY9D+vvMPejB/ hp8zv5rjBw7+vWP8yzsX+r+1Ba3wNrMOWgS/Q3c43HkBm3EtgXfmmGvlVpTzEKy1kZjos6TDb4E8 s/C4ku+8bx/SLqnctktxr55fh3jv07Vt9dFR6xoG0X5dE5tEYwVOLMXMDxOTU1l/ooLdDO1OT4Q6 bfoo8Q0RKYwawVHxOga3Mg8WKS1O+9o95Du2cfbzGDMNa9b+dIxXQCPhUUgOe2lQWm0UrUdoGBV+ soTOg19F28rLECFmxgwz8gL0ROMC5bcNHtfSiFl39MmLMjX1I0p3sgs3LhvHFwcZe/2UTv1I4uE4 ba+WplEFBhW5eWDFgBT/WF5Y6P4rU4HBKh3dbzd0YKBOx8LK+lfb7aXA8kZPLj14bDqlqqlCQcny IRu9Q7aB8oHC6PTRtedDjUGVhEDt49KsrCzNNISvtQYuos9bHCqz+Pujf6G0Wpw3M50fqi5SrDV2 bqK6SDxuXt5ESDjt8ch8r7107Op3wrXJtvl++MRl2C71hNPY76meICqsXH7pu+N4uRi/Aozw01FD QTqWMHJSykJYrvecFVpUguO4WeIkkqEh164vKzyiXzExhSa6Ki+d1I20eGWb8/jeBVZEDQSis29i yX2CKukOoUjivN69DbcUvFsmqJRMomUbWsxz7moR3FsmLSMfwlNxEFsz9B9156r1lyYjJUu73cq0 zgyWzCzHNqIqLm2ynfzcFFCy78u+U7w+sGev82AHV4FIy0IyOZXSZB3acg2tF/dJ1ODyemEnx/5L 0LNRbVyE4k3q+vzzjV2dOcG9NoOZT0x5Riu+89Mljn7577DpRrbYqorMHWTqQehzrYLLDzgGgqSx whY8fvudbPBxWvEsQZY9FauOuOboySxF7I6Wn5H0ljoEx8Koi1vLS0dmPvK0uZPs7QcVYgyn2sZz Ce3FiHzkPyjlAG7TU0WkevPkODstRs7an2CExEvv7eR9xLcVO3QROCry0L7s3ukfZfjEdMEUNbyI h0Q2vvqJye3iBq+U3bYmZlDgHfbnfXvkpG/z8KaFMe71O6PaFLhU27wJZZuquaO0kY5+gsriWWRb vvYzZaGUI1Gp+BAJiLuImCbpn2hiWWRLUIcRIg1ipaC8CSks176ob/O3KH/QrigmXJZ2CKwTeb1R h1GBoMA5/+1trimWGc+713l4ZGTdK8VpwB7ubH+TrMr45lOKNhAi4qnKfL98ojX92Zp5/uWn/aCv l6TZuFumeM+fefICkGHu696xmCW5zPm/Erq6nF4tAj87JQyuHjJ6ThHgpAAm+I0OfPk6HWIYGEB3 nfW90zzaPoWrdGIqXMF6O27Lr+xZ24juJ4tjAvebu9IJ5O7Gse+/rfokbxCZEMoXm+CzmUbaEcdX cgqsEjaCG50j+/Asw1PTmxQGS7JtDqXSGjED2YRUhcLXzJ8s2JxVLQMFNfeOt4UUZy4JP90tH4Mx 0hz1zO88h9SE8RS5S1bHhCfQr9s2JMt9zqNXuEKWY9ox0Js4HHEH0HQOFM92NPEQ/0AcAcH+5JqL SAEfBCDiS2F8spNpYAKH+KU1S9GWHzoCPrGbKUW+GriNIO7baIrM6D2e7k2mdQNV1MWQLtCHiNvN FEWf3mEKwxjkZ/aQiaI5kq07GhENO7SRKKA2N72WgTKqWeoEImZMEzZ7yH7W74cuj1T9kXNULroI N3tMs0eWG0SJxhtUgMweag6LZgptwhniJZ1ON6eiCMfF+8qUcjwq/zV7gjlmDO9I5vdRMka+eRmF hlgFsmovYv68MYOt2VEaU/YYPuNRtVG7euVxxX34wkxbEyYlXmPbFKGJdCZGrZtkowkEE6ppu22c LZxCn2Ffd+GTfCz2NCN+jFHKLf6tvOqPZumbclTVocOT3BldozKmsEN8zmRDvtSrztxD09y569VP tuFN3o5j2LZ8ROdTkcU91VMvdhOMs77DpfIszc4ZVapGUJfZNL8xYaLyL82AT4+zbQmm9inNQZvz B7FpIbR47caAYE/Jr1POnzKNim+xq0O2JO5kTI+a7bs1xu7aV0PNicbxeciY1zBfQ0zvbtta0izy qgDuRBpfOhNo+SYn5T91ZijxXmq359LK2s/Q2FbPBmbthrem7OJ+gWmJcn+xyOsxes/3fuxstGkb aovrVGSrRfMwK6n6Ysu9EfP6yeIzt/DdNBOu07eNSvNSLyb2R0Xq7xMORh3GskAkIAIVmsWcFgkp EMs4+aI3iGG6Z0t7axXEcwrr/OSaEERSM+o9KnVKsmVUqrGlu4/rHPjG0yqHRyBt4xqBC86SiOaU 5kv2XUrq+jVOwegneYZT4GjdtpMzzvUzrqduEak+rZ1nhmZjS5kqJgwgbEvP1v4zJmdxl6jaCeUt JGesa3aurBY+oCzFOHBcJ9w9aHf+lBLVxbtVwMP7wKdV+nD8ZFTr9BmIpQXGLUx73GGUZ8tw640z ZGOcObald6tMmen8NsQc0l34Lvfc07uP2v7ukkCTsjGSU+JTBWf4a8wWxDuca3I3Pg9/dzGOjJtt rS0VzRej1JbYuNmLox7jLqNl23hzFKc0c96nLNUY28AGd5FDgU95L9Ifcl/UxG3zaL4Y4956cYpy SuuGwMWfZkIjx+EGN7nFkB8/0ZVMvXG6vJTsnvQ4vk9Km1Bw97a7fkqXF8SmxZn3gJc8sbzdxpZC uxqZw5kv86QvG7Qatfa5tIqj7h3rVV2gO8r3grqvqOHus2sikvcn36q9Ic+2TTF+qyK3YtaoOir2 q7D0+bsWFaUvb8mRdwvf8MGF7vxJEkDEPoq3S+5R6tY5UQreSWbhyx4PjTQHoQRIpum3gvRVhn/V S+ytAEsqQKBp+GDBi2da6ZupijUcSF8L7esjdfZofaoD30/yz2mq+65akyEkoubTs3paRJdKoyH2 kzat4qSssIRFLXlav1W5IxJd2NiH4cZCO/h7zZuPMijP8z6oqpzByKvy/8IZP5K/j9dv1dW0kKId zPsWYWfEPsZxDi35WX9AEtTNSNAEEhl+wS+btqQoFxdJLjp6BW+xN530D6btFloVP4X0SpsIsY/p 8tBOduhtSeHa9/qtzPIEiIcBCBIavz/HnLV32ES/bThHScOHkfa0uoX/sHobgN4mBhDJuaiG/63E 3hMamQDp5XjBtrhxSFlsgARbjv92pvYriwzLlJLuow8EQjHnJqh/K+WXUTPFom5ahlzfse4af7ed wvM2stEQHiWn5LKXcNLPiJiLflHAQUaHXkEWvL+llvF7q7a0NDK1u9/3b7nd7DL117s4/UUebprG pF1yl+nZFI2jTWPxb3VVYENud0p1Ne588n+ZNv2LKPf6+mQfvJzTHEM6f4QQl1OYe8TqLR+/51fB re7GHVaPTCHrl6+vw/Z/CZAqylQv0mxsmfC+n/KYp/1uT4+nyPuP3kcYrvzF+wiJqaJtqHNg/6uA ZXqQTOfx8BZ3DQSwQj6TXjj9jQW01OEvLJqMnqiRFoNZbP+uMu7mixb45yT8XwOS3mzKVMNIP8tq yv3FSAIYrGQ+7avSzcLC07MVKbWZ0m05OvjdYZbw7iegVR3lnh+RMTEK+Yun+9RjxTNQdXm+YyX8 ZLMsGXBn+MrzqyN4RRHuTzYKU7/qsqbDHd9OWvkQMN27zd5kB794eVs0T3hZYdkGfDMQkIR0moaR h7txO+AyB/lb3/aQd9VHF5LV2QyYfr0IDihjWY97KKVIvHn0243t7k/K2GuPFnsWCNz7U/++tRu7 ApYu0CpsZfXu3jAVaPWkzGoihCmd98iumMTK+UeUeH3uu/glDA2cB0wCCTXAYZL3MwzvoWIuUfms 4XzS6rd/JptXXt0vcZK90fX9S9y3pu/PnaQfY0WUDTLOHbbuT8G2HwWjZKI5/2ONu/ABzN3H7/tY Fm+7NiLaP0mi8RtF9orCKnpVEgmHcfFPiD4gTdLNz/m3TusC53Fx93EgGMbHJInFfM7djT6kv5Ze 2DwtrRKxn2Pf7ZzngE1s1Fj5NJWU2lzVz8k2SzCCE8HEaTcT3oZ5wDA+AZWTW58MEQVNeCYDIuyc t7SpuNPLvBEWOt9epMDnHMTC0oNFgkOgTQqGEop9nYPKHli4t5RNXha59pqLXWnZQZEg6zo+mLwM V00oxbL5nNzK6NBi29Nwf4SSi1tiRE7CqCZNzDg3dwYe1+GwCBLJBT6JuQJn2xwOB83h0D2VemVb OLUWgIsXBnfens8G6UBTVInhHBQ7YkpaTM5rJ8XneRV6O+tZQPYF9bWPAbL8kqiI1qugQSPOt0Lo RkxiBrWfyYDVWemj89Ny6S5fY24wlKcdJUhiMdA7O3tUsnMd1e4peyRp2I6bM6it+K9cWbT1W6c7 3+unFeEhllSx5FQzay7q5SQolX7FEpE6O7Ut09TKOCQY9L1DdyRQ2Qu6Nn0V4r8Zp2NjYRq8IPua aboUyMyoqXthFa/qbmHaXIqGZgJhn3MvpIQoNHM2udX5rc9hT0pdQ+7A0LxCosmd8FruKhRYmyU7 UpBofAHFeoxjh7WhtPJFkMXRdFzouxmo2jhqSnjM99yv0lakmYWkW05Oa7SsAINJsjG/oaxnqc5O zEw8imlwukLqbQZuwLuBioBZkQHHwKTdgm9iIi6x22/Yut/xOu5X7R1lL3jq938xdCBmGuz3wcx/ l79e0oaZsIvYW2ZWbrR95exWlvFpUhd4GUv7DOfm016ywmKE/h7wLvY0m1s6FIkp+iH+vFFTO08B Dz/XNVnhMn6ozj87lxIYcQD6orb/cdRNMbC1pLRXXOCip2eXxFEryN9Ir0ODp2KhzjIvgY7caVwT TbtAnMb0riL7Qs1Z7C6MSKRIhY02Em912g5Yxra9JZNfIyO4kkxJs3vyQJa6T0GTukeaylqyoD0j OzlW12WYUuu6niAywC6/9PHWlk14R1SMjp6mKz3Z/YvqMumLc/K77/pr3o25XQbd+Wtsg9prNcoh 56ZC71xvYZXNxpB2ahxPFWqQWFrUSofnCdgt39vS1PP5dYhHKmoyl2S8LVdQQzFK9/PD92/JzyjM aBQqStsu18BFTFp7evzBr7G9EG/EJKjWSSu4bmsHDqcTJ9Z3jFxOO8pbi62ir6M0mbPENSqm191Q rYGcjuwTeVkmGYrhetJePMipFMSosly5q6E4SDuu1DcYpMfs9HHHqaCd4fK8GF2Yc+RW/02WGlUk zUj/yQf3jM24GDwXuCt7uYjAJqmEFiFYKyQkm90KLJRtKzmvxKj92lHNopfSZzAvffntkMlRDEqD OcXrnXX98iDHXupU92IMnQgZYqbmvWONpa9WJmpmo+8vMWaBhmraPZvBSQf6F0zQczY8FX8tteKg yziLUZSD2VwvCCRCuNBJndeU3SqK2RwYPqAd7i9fJ9abD/3Kly8w89EauQ3msIMUMQOFT0D2Mtaq Dm6F3QcRxrKRCjiUjJKInaUqp7feY0WEzY/lJakk/iR0cYBJkS5LZZDx6Yp0l2Dgy/zxZ/PEjPgs GLYy60bTgDdFfRCLzbwhB5tLgRzrVIwfLHrfmaW91uY309YW0TPJpRnbk7Q/HEJU/IgEEIUjC450 q0mMgm54we1tSVynQKrvXOpaPzsH7xIVxugvXM/VoHzFoxgIiFCxylR+HjAc9SlHCeblIEthgfEW RyQLM7RffUk5D6+Dj/PzBGZezOVzwNY5dCLB9daQR6af33dnl8nTtlbBKqZ+rcR5CfcX982En/iQ KvvwAKECt8++qXaODNBE+t44Ae3yJ7XC7hYhTlzWgkwAgYdRKuHY372PxQNXjA4L37beNRcRcyw2 eB5DHBMtGBQ0x0MRaANGVBaZb9CvtN04+3WYoZ9v37sVqLs01fWn9Z0UYBSft5GPozcqaQuawlxH VDNCqy6ENLTZwiNVQS7qeYcFH6ztRCzLjiGfX5A0pF6nWzQ1JzoTuItqZ53X1lhFfNo0Wt4ueefx Xr9zS66KqHMxERuwXBKGfGV+ejntClxmJDFsJGMRa00cRyEE7fiLun2MVrqHKyizTmxtL7iCy9ug cPyOBkXVdyNXicdsevymMOq9AkF7iiiFyTE+Gld9AMnLqMWkteW+uHSSYo3R9wgNFEkQ/KARarkO gvpZomvI1Cold39igKi1e567UGqdUGssnri+nWKw9goVE+C11vuKQ830b3B3OBYxu+tMzSTKJ2+O uEOkgj2u5LXVzJGQ7MraZ2k6NpxGd5EdADi8su+U/fRJs8SfY27kDL3NOBilOmbUdgrGitSdJw/r zgjbaGFS30/57PZmMkKWfzKe9WLC2Uve5pUdxdtAOakqqQV8DP1byfCeIibmS245oSbnru9DCWoH p1THjksYq0pJHXElwqfrAfhMn1lKj5MgOkAycPUZEkz+RxYqPURkHEkuQo2Wr/PUbk0YTjXyORHy gK+lh2g1STBvDeqTSlZe3zFVJuFFJBUiMwMcUVCT9VkGF1l7rMxW2TKOZXEOZMeRDZLnM0DITxVC XKHWAZr+Rwj82F6em8pvRXtlet4UpofAvFSX7KhF2+HL588XmfkwGghOKcH5dcU9ErSp7VHn5zTt 2s8hN8kh3bPTKTVrJ1Cq7sOUVMTqHCtnyNW7lMWK1pT6yTvIdwtpq4xFH1DrjFOpvUFifghFcPnw +S/CJyA4n+Y8rWT6/AZQY1JSSEYBEUGyEB9TUbR2EilAZHtZLqyfJTaXij3YbkLT/vR5Qi0DRW3x TKVzaXid8eEQdzgVkGZWwzZdcKnV+DAVwmVtv8BF4UV2f2pkPOVFubjDG42uUv3AkJwKHGZPsphj p2PyK3a1ij5TW6RuL3k0RQxFPMI8aCcvcW8D83AuUTOEOeQ1RDPEORSDIyyNEI5gy25vYYGCin5V 42IWZiyW1yHMColkPWt05NB2JzmLW18QZWm8BM9GhVMrjyPBPxdbF3vritLtXechqNbJoBm1ZN6y jk5Rz0wKYKOAONzmn0pN16HgxC8uC2njVqPwRS6dnUqIypwSik8JumQKBuy9w5+PmIkldXql8Spn aoHSlOTClqR5oa9lISCR46r1faZWNjLO0Tmu1QXS3tKKw+FnaRn7GBXIklWyF9XReTijIC6ilix2 P98NYfG6zC7xrRQYFxQDce8NQHJPnUWjL4jiC0EJ8E24F3ZrtbZUO04AaRtG11WmO6fZAfZ+6SBi zFRW35mJLRfWWJ0FDNt17BT5Yib6Vm1dPoGbnHL30oJufdBO6QI/Ngph4pOWqLzxdDbOmoh5nzeL 5/zzjoVIjSsmLeKplXwexRQSu98bIQtkTSFtVRy9CHcmoGXGVnQ3jtBNq9hZFqbwuXKJNVCYbvCV wmwJCDHdgLo6Nm7RuymawK/sMeb5JL26V2Edxyz+60/9iVhksSQCerl7zxhKTzjfBsTKvKIaIVE/ EKteSDGZbefuhFtu/8Y1Bhsb9pLyQbScM+GdE2mbrZuXobOXoZ6XoabXkiL9bB9+107/8MrcyCvT OpxajaU6De0KDe1qjYNKDfK9WEqOwdnp+jT1GUtN4Df2tb429Pl3EnvvBoxgGV5xaCDmfKCK7Bwm DsLJZ6+ypLJ9EpbtWJPNk+luJkad+brG4GWmSY0BbCZMzZqzhtUH1P7Eo3K9KH7VKLUwb6VNM1To K/yqHU7oCD57pLqacofJbd5Tb3XsoK1wdWz/LY4aB9pM4NkW2TlNYcwowk2eugt0onGaQuUS5Y1P ZLY/Sl0+EVu5+3jd+/PXhlX3vd2V4hdeXJnsKzgusvbEBM689sT4jcsYi1nslh8P5M2h3zYKlLS8 Gds32+cW3J1cg3R2qZOlB24aiX/7Ll9DCNUVNPmyxZe9hhBxzMmsD1nwZHJPBWVIqepiW2nEUAqB IGkyMspFvWSKXU5z1gbAQJqAIZP3tnldzixgiUjImaABXXnGBgBJqeOxoe9UHFD3TS5lm3ZAOUXs o/C184FkzZQvqYKUMF6Vrtkx7lZDBi7H6/y0tDxV/IVRbNv8YX9dAwVzaPxABXN4lK4tphVFwR7t DrIkDrRcdnuKop3q+VQjPsUBDYRswtp72HmU6hsBB/ikzDkkJ/VByRq3tOAt2Pk4IgZLnejqrwHT 52zUK/5p5fu+26kWhFx8tRfJNxZN5q8saDh0VwIqWtZwDFyot/E1JI7RNezEkktgQ53MjeeYp47R 30jxM02ev7MN6pR1EdhnnR+SjtvPzUZf9Of5fAnnhmdiUnKCP5+YPVl7QocaG6NpqLETXDNJlKaf FFd8SDrOPM3WxwwNbUu9M1jKNa2837ykzOTj4hp6ojS/9vb2daD5FUpI3wZkljnJbODXp3C2p88c aZ+tjocUevtZjN3AyJBfDZXNDWOdR/s00RaJqH7DNJgzUzdNNCVnWF9xZ/j8ZRkVGMhwRu+fVLKB bFfONmrBjD0UqEa/e7h+ZjY2x0l9RzWoLVz0BhNNCy21Vrxx59DhW4KgnhEsPBXQR5MSTWb4BMkO rS6+WmxJUqViWtPZwemV/rRyuR5wl5I81fTCnWV2rP1ZBRwz63E8S3N84MBx5ru9mNJO28riZl9T 55AaumsNiaSPFdE1051bNmNz5uTk+SPHyfnJR3vlK0KQWqJK/ujo9e74/es71Wi7LRWOtg0XGTNw ZRoyJhVoXUue1/MySdmQ483tXlLjrlyFpMudG6LwcCTbVxbSfJCDwtYM/bEbHcHipzBG46D+qaFw nrvXDFM+e165exZpY8+nsrFXMhM+h+ReBR+HMUVOV7haRdOUrQq/v3TY8sGbyRAJe2ekyivdKpCn +5QlaHwoMTJyVN4y0mp8TdqLTyEyCUPmtoB1VuXWWOd72tk39G53crzItRPmhMjLN5HZBjP1zuGz TiRyAUxhmq35mh7z5f1yrNgZ/U1WV8mkwDvJphbTsePQi1dRhUbDiVk9k1UtA7hV8M1BOJDnuRHr Wqhxu10EuJBSitqqykuKBwla6aGnwZQgcPdgDNNJaaifaC1lbywbnNRirFUHUiosT192aaHSTAX1 7N6oFx+aV7SWfU/97qrTFXWsamPqFJVwTH6cd/PNiIwUWUVCSdJVSBvPXIv5E0i4U6QkeLYY2SXc SxNt6Z1I6rRXOkbORu7GjlB99lkm8l3JSmhmfgzBN33mKmiOwOJeJLu1scr89gbISzW4WCoOvPSw OOqzM/vosncJReFxHe8w5QdYywXVX0g4WYlc0bM/kGhSp1FR2a/HscREowoPUX1sE3Ctul/YL1QV p44D+lNj6Kaxmt2nL/vzbEFj3hg0ax3L9dUR2VJ4tC97jnanHWl8B32CyECUubSxNT8P3au1aKgx EBHDtrjYm5moFbGSWoyYiyV/sXvEu6wE6e3P0zL8nopLZ8SBzr36tt5e5Cvjy2u5hxlECac2+iW6 z3EjRY2j4bsm9tMyATmt7SdOaDoH42ndtHCnG3Eph9ce271dqBb1sRZ+NpynUcDRB52yc+52bh+Z +R4zf8STvjFuGfMoAlotkmt+6Lttes4tN3GWcQZGb+02O/232ILr2eWkO0EBbqxoWTf4fR/mzelT sYIKop31Sx8+qpkQpPClVeGrhySdPG9EHPFdrRAdyVmegGIWvwlWnkiyoOYKnntB/wIx3caiujaO WL7gnHDiUxKTl1XmGeVzliIbynC2ai4TXTItvqTtw+wxxsbZ8qcl0eOE6tlcYhPb9swhKSVnWXTV H5XHh0AYljlue+JTha+rybH4GUxhGSpgYinLxt5kS3YMf+ip+WTG0Qt30zS6ExcpQTbeiv/CrZDW EslP5Lnh15qPB7kkW1zoXX69V6hePSPbW0ESJlnJCHgiE0qstUN7erVySGMHXWMIWWrVcAI7/FPk XdgOWEhmFKQ4PSyvU5lHW04xnENbec2FiiW1Z1KzQnq4xiWpyTtTqbMGtuVOF6oc72J8Kx2Zoage fPd1DweC1sLGjiGq01qzPKoMmONKom2zmaAuIibnVqN9CE7TQ+gYY9BHCSgDnGZm812SQJ7VLyXW SdYuog3WP8QWcIkIt0cmT40KsJZOb0k5Q28WfYwp/yRBsW7UsT7XdcQSsvGVlDrrxuSV2wAC5QfI Ku3BYfoZWpzZruKYFpoucaQCzVQyIKNmiVa2lsD31xQMJsxmw1kSplRcYvPbENde51UmXyQFhnCU +0vbXl6VjTs4FXJqtcp9J2Uhf0ExQu6PqOtnPK8DBAqU7e5nK8BqM+THKqeXaRw5hzrQJXSVs1Yz RoYIScQUx2q1Y83izXLtuZ8/d/Hcf5dWAbHHIx8NqgF5VwtdJ1Vrzb3t6Zdu4G1VWMrtpGiKxpOc FNGbTzPlSYc0paYSMP9iNeFgfnOltuWPkiZw9VrrpOCNyLKoR/b82GbYWNEpc/ei9v2cCLQNkvs7 4eDc1iNST7aZJ7FeWUn9/bOQxZ5aIweGI1UXs9wOqvhkquKfB8gQY7rFJ3KYxuPGddlkHXobjn2P pY6xj9+u43tjl/kjhmEjYV0kXCfV4bae9aY6mKXNu+vflMwhBwsRCGs/L21oi/anY0E3bvBDX63x iZ2A3MpC2/o+T2vLHCmusSU059e6LN20zXVQdn+NYPwNm51/X7L9ipGWQZt7ecLG6JhOvXDGIllj eVev1k+ry6p7V9kBugn+7obdxbul77zyxWwdK3GkfI6mKWpoviK7RqKnSg6jhDpVSdSbjl2m7cNx q22I7XCLmA6DJE5e6uiRmLJobIOy2/jb2NvayOw18qyYq374/l3W4zE/Oj/xDsoO9g4tPxeEESxt 5j0Gk+7dkPfYGsFpic+kBKRyHClb+k9JJtAnXIiHOJ+sFjxfwru5G92dnRVP/NLLWADZc1ddLeku 1OjJ5bpH0usH5Sjr3QUKalZqvIsUvoK4QjFFjJD/HCSihz4vLDPG3JEkDuzIO/VCldLR5W7mK41N 7ZbnCESMESE1j7GMt6f2SrsQdSGKqkZB1/lqoTiuVkzjViKZAbH1sO8HdWoaUe3PRckVlnOCMCd2 Ia4BE+ScOOTX1oTlnIw0djhLPDuc+rleQ4hjS8KMY8P7pJrAST6UTlzdarAdc66T2IxGFKKGxnry 08jUuNUVcvc9KnNqztjd6dvh63kL2iqyfXGEltAEmlCrrvw7n0QbxNZiwm9w17HMfd6mieN+dqkO aznnzzror+TPU6KDJjD7jA9gry2C2S6NBpWuObH4sele0gYdUVzDO8cQpWMsMx5knoFwLWNdFDyu uAu0x9cw0DjuPOfWbGZ2D2l5zvS9x8b5E4NWy83x6paD0DfkiA0rEyyw0NINGLtM4Veu7uKDOOdA ++gCvm1CZRU2xSxc3rMUcC2OWW/T3Xgo8Trs65OEq+y/LGgLlNSXCVbcD4aMVS+XL4yaOPYexa+Y dhR1M2zxa9bUfaN0513+WqprXDWKkTZx8XrXqd5Z3vpurT1orN6fKpx8rSR6JLMAye4d/cY+52kb Y3JfjokholbI7jb3goB2lvdgINrhRPUrFWnC0hO1mU+Y+6gTaqy7Etvug6FxlUZrX2Rx2MZk/FVh BqJjdT2uOV0INmaVL0/fuAUnCKy655SjqBLL8IHDeJr+nDZavOINYB8WK5TD0LM5hDtTcEHrxDpk KchZ6TX2W1SJDkQ8+gD5uR7zhHFNJ4pd7yZdGGElzIM9glk9R5TAVVb+ltnnWOPccCVcwQ3FX6zx DlqpFzCdJVpiCvyqvl5QL/RpZxGps2kAx8ueBJx1zO4bj3rQdAs6hYntsWUVCDG74Pemc5IopIs5 hcrpVI0dJRPydNmSPSHRhRNqKF5OcVob/D4FHKZksyVeB1hyIbARcHFTchfz+JwpbJVrWXHt0Y2+ MFBRP1v2mc136zw1fkFhtBijQUSDRKXemPotm4exB4rWLOLGObOjWxCKqdvyY9Q3fIIsb5eQAGIZ nfl3zrF09+jU45SsjHPoVEJ5PlDzXjlf0dFXYB27e4Pd9N9bhdm25WES3RjvJaFwL8TULhsu8iyp szZ9XcWMVrBdW01mGFeT45Nri3+2IYpFCzDt/ZqBecDd4pIgKawWFhL6nCuMSpQO8XUys9velvhF uDvsVUzM1VXMZrmUxMHS2XSV+HABDoNVT6nhfpkK+lEk+T3x0u6xEY4arbBmDokwvf8FFmWCvh70 K3hFyrcRup2S3eHcb+VF4TVWtueL4gJ8tWy011Ii5A1Akl/RHHzJ3LI8bD2az5owiURGy6bugjr8 XhjrrnT47z49WM2YePuw5rgZgmk8uM1kbzB2Sap8mIqrFMFVyKrunFJC/SaV62zvbcFmdZnR2fq2 2vpm8kp8VtkEXVzixldMG9Kkr2ovjRHhRmAD9Z/aYPSIbSf4Cjz4t5Q9DTpuPOE6THgBZfQBBUX2 6jVKBI0nKTKhcgBfPxbhFLIADPnXQdbPR8OsCLQMhOwMr41lzUtqSnfVgaXmJWeN3LHqu8eqQGal Mssv16rmWDVqLEosQ1hJ6vohdIN3KSetnzvjmd4fLroccr9wOnEZOXS9G3nYTY6LC7PR3X5Rjqek ECnhYzWespBSGfs8EoLMI6qSZd07+oaM3WV7Uj4RPY6ZmUo7LSMtMzAkCBcbOwz6Krr3pX30W9/c PBna7M6cvM24HIPcPHNEMv1xkryYHEmxNM13omTSaa6EqJQeftmE2M/5KyNJuklIZAiJiHwkJcRC ZMTEiPjFxCvxEZtqsuPhGO3ExW0XXiO+lYmV/iKDTDwYeh1znlatyJERTSRsYGuGogLDBHRaq/fJ HP9SXezlOsXid7auM5QHXEsbyLtaTaPkwv9y7zg+3RgZCuNUtr4xtaD2rdcwQDNrxH5tSetZo8GU 42UTAPbtu4cKDnh+zW+SUgAelbPCe9Z+Qmm/1rgPM5Rq31QrX27e92vyxTNa2Tr7sPNzWUm68rcH Y64So43E3xv0RRF16VujhgXICBKYS5CuWAolJESRYMjIJ7/aY6QAKndfqlrydw02jxiJ3Va5iKW5 ZQe62/S90x2sTqSkEjKmHkIZJleWwsRgIOs7/QwkS2SH5OTqK748mtBc34Y+CQ6Y2JRMwM9GQzPR Uf5SFk9nDzfvPeJbSrb5dqPAAIve5rh2q2XsAflu4rmh5kIUVmShTE6A6QQ+k1jTuLyMZGiIaFA6 ioiPhr+P1g5jeJxHYZ9W1oRp9R62z/rqq8Uo+lWCS57F7DHzfGJ/wu0oE3mk5UK6iZ6RALTUV1t8 fMjEqOXTVcZBat9X81qVO/uPHbUkx9q97CC/aB85P6USHUClHzgr1sdJKsSAO1u/9r22c85xd3Uv kJnDprCraDA/hVGlxu8yx6PWJRlNfnHo2nsedL/6Ag8Gj6ZPqXNLba2cCC7NJs44Z1MwbCie3glO qcfQSGooVXySTmG8x0iaiG2sXgqTwbSQlon5PXlbEWatqpW0VejIhaSWkyfXHPdUqtUIm+qRsOfc myr2UgqbMwMXh5HqmoDdXMug+12fT0PzUUfLx1DHes0Vbvqkag2Cqu1LbQ+eqJ/Hv0dtWAdFITTv yUgmdWR/EowVJQtnlVYq7s7okMGvDXjVgyolRI4aNmQwm/UGIy08/kOzXLKKeW4MkoP7ovKVvkTJ OkmsMaWM0A7cJtRGnZRYorwsIxVdUamw0t329vmlGNR6NqQG+oj74kPVp/usvC1TXX4NfnHbYWNz lu68/csynrk4Ngdch/sq1iOhrhGxWtoaTvGkgpSCkOntTZOE0m1MIdKH9Z5XE4G2ancB+MrONxOB TkxESmahkyeVrmau/BHcKjOFi9ESNatZPahduYC3lRPypwXXFjW01G/pIrIJklTRc0hSJSV0DY7X gqstwo+j++Qm9AcUjIcCqGTcbaX34GL4MfkqJwvI5CokRL98KEc4TBlwbyT7ptk5CQP50jpdU6JS /9WEtdWGpHScbSAaDzUl+bd1QQiagdXVl4FLohh728/EplfNv0uwMdGU5029XEO4TzqbjeR4H+t6 mXGPJYFb+4lncKjroQGF01J1KlyTD4uiZRZ+VTxbIZaLINeoP8lFMxO1W6yLyAKDwEEhyFeHcvYI tM0gs4kxLSgolCfZ+8YYGR8EmeONojMwKWiITu5uvTI/sDHkZOTuK58Szp1XcLI/nnAdsIqGiVmY 8KZQPT6ck4/JFyaDB25ZYcf0Wergq4GsbRx6UeJ8n+/9Vycz0vW5nzxJ5vxZQcRoMvI7PHck64Qr LlaDWJ8hnCkMD1+I8RDAdTmBf37VXxLEyKZ/Etg4InPkBuIOIpe+K9ZOzGr+fsnWj31Bk38svAGz NrDhylmJhInzOWnjCGdIJT7rrQfmqM/QmMd28ojf5lYfHvTpOA6/+Nru4deqhw8S9RefbMdkPt3K J1/JOLfwOIdoZ01vnT18kx9/CKdwOsVquedpFo+GjykBP2b6OftPF4/hoIe56ZPAFx9P+xh9RKng 7t+jFjR3sxJh6X6k+KhEGtMQaQB7YliKL+alsGEWSbIX6/ScjYNSRACu72mCSGRNO1uCyMQ+6PvR ZhkqBU9kA6/e7Ag+W55gwXXrIFq2YA3fhvjLsuvSQSXBvDkSOyYx2RayE5hKPdVQP8KCVuoT0ePg nTr6MHT0fJJKmTU58nJlSUHZDfFIPN0VTd/z/I8d9CqRyR9LkotmNwcFNR+FEW5uc3p+kiRMZXdJ /g1qc8/OFJTomkAhlkrsdyI6+/Ay7pbGpu9fL8EidPNMZ/T++4n0wzV7YXpMfAkUfaCQtVe4dTa8 G6MiVSknr88vMhKTwLz5h0yHzzSHPwwm4Jjeqm509BokdPgnQif3MLjhb/bjXAvm2nEj7X+PcABL ILfGP/zq8nKR3nh12po7NYyHxo65Ne0kgDJXziyBIDdCPlg+ntt2T95RMueckbtVduM1Xs4mp3cX Y6H2xkfT6LU6nI20/Bp6f4/MwWSZVVuk3uS+2d564sGHRNoH8/a9cZ/ZHHjssse/oCArUmoeQih6 XExZUfE2swDfeFlqADP+M+lvxA5LxwhmSNYOQH4XeLyIsNS8ALQ4T0r+ebjB95FI2gwZjN+XEZhR CISnMj+l1GGJIvZbcff71RKL0qfHnTE+lW71Q9FXTfOuzhgSHnxAuotXjJCI3mj5oA5vJkkA4fSm OGA6O0aoGt0aFop6vv2MJXw93z4zbnuyXWTTg8+7smeOBWMhEK2/V4+6Tl+1R6+XonORtxJQB7nL NjrRZukQuUfbF7mAUgCv21Gt2wdPexyUWoBrhLbAsrhAQiHrgXQ85Mo1xWE5Q4CfnUArcVzlLeIn NiQwoMe9ROZSkNjjLxTo1MObCmDoQ1ibkFjQhyolipros+ML9EY1ZojbWnM3tue4EOMIG5Z1Tbxa yJgZEjgtjLAc1xRRDUu5GfioFGsXID/YdKU+YONx2iifEqKF5MLRgCbMPeXXFHExP0agBjD0r1YO otRtoJSoTN2H7MCgrLMBNjpZaCBLQIzsbKzUvMmJu4Sc1VmUIBgP6bBxOFqIqHx/dbTkWH1GcLN+ 4syFtgFhFGAQFFXGUr0b79qnTKDe2LDO3BqFZ1mwtp074jRJeNjqfwE4KXy1yn4lmWs5bb0hbjsj SiF8m0R3naHrrKtbkDGlR09ZHsCcN29Fz6lvN2MZSmwcJDXIwmlZg4VeU1zOyoEQJIlLLBLXF68z P261Q/slvhExyGJfKjMjp2PUwJo9MTj3nFgkqc3oXt7JD33sq+AyvF7QhAEj56GFLb98lAllORsC 8ykrwoBlSubEmN5OL95L2fMjZztLZf1ZvagsbzHKYRpKZgMqE7WDcvuZwWEL7tf6V6O+IzL63hhf kCgUBqzQQnMP0G18V9iqGgwb+mhDyPDVpay29ky2ywOc/LqoBlJkCxr7dBkDpDteMRhLevRNmZoA bbHZOSTLnzInWW6Z7tDOSIWeo5NU5c0OlSRd8J9NbNkfBS7qMjhQv6cfaKKiGqDStZOr/ThQkiIs aT+H0B2L1IQG/xk3ftLr6QAd3MAmNoJA0Lxg0Xz4ZKQlbQ1LlRpBZWfGWJhiwAsW+iTcXKT692xB wjPHnNSVxXn1UGpUql2mZsYZdtXvlLJKNKrnEtsxfMelIgthFqyfW6ZIu+RNvGO0p9vUC+4yqOEx GNNPQyq2hFwu2HvuvmBCso2a2XZ/NBNh1FqGx1IYWbbrusAqJPudocumy6PnTkRnNjO2zECO6Zrq q5aJPgM7Hsfq7u3g9lcZdBIeiDfAdTxr/uqIJtX1F/F39d+DGtZ6Qgr5TX0FT1SwWpCTnXJe5VWD kHiWWFZSXYtj+hnXLdYV+o2jifrlDRuOzfuNYxjwmvj3VYbzjBNq2l99DcPrq5xF8uBRNtZFcJKh w6zpMQ4I4ZlO9FuWEjN5ecXmdOoBd2+aNiYI45sto6TFC1SUz7x8+tZOqdDsC+K4HMe0ydcH3yO8 hFdYxVqyDHXlsnxT4odJPluyyejUyOewz3y+UUW52211yKzJ2MiN4oKgLy+2pI8e+L/Xij8IHnp6 ZL4WeC6UjB9KiqqPFvNVR4UTXnuI21+8Qr0iUdZXxQb6Vr8L4mgkGvfyermg0yWpUmEb6oKU6ytX P9AbqOwO7RpkC3/5PmYZcrmwn8DLLNGMXS7fKN/oA0ZB6rO0nFKAl3MqlnlB0ST8Z/MvNF7TBbuf deQ/ISylO3i9L+Roa/qy+JX6zNyncPr/ATFAzr+qA+BBdR/4uojdRIj4fsT3iSJiT8RPwA9rniZU M1ezgyg039PcwtvHHzV3wD+OhOTIlyK7iSLSpcXbqjZKG00U2hhtFni2dgZ4kfYH4Hu1B8F/pP1H 8De1x8FPaN8CP609Q6j2rPZ98D9o8aao/VB7G/zP2o/B72rvgv9F+xfwe9pPwO9rEVkd0eGdXvdz 3Unw/6H7E/ht3Z8J1d2JjiVCtD46iSiix0e/wD4XQo4nJZO4hyXfSl6V/Qm7FsGiWg18panTwCJN vWYpeJNmOe5mDd4vNV0aN+4ezSvoXa3x4e7X+NHSq+kFX6PBu50moOkDX6dZD74JvmJeui37hMIb ueB52gLYUqgt5PZ+AP6v2n/lthzH/YTuBCw6CbuYFeNwT4hOgC2J0YngScwu2Z4oslU4RlRNjqZm YljudljJ7BUOUxupsZiaHWSptckp4n0/iggvLKowsH/cAnlO4Q2tzFREx31D+E5h3yeJDqsLJILE DNfZX6hCUnVtlYEkyCMoiSSxMlegV0/GtJkcIrHwu8jvTn73sC+ZiJffg/y+id+38vt+fj/H79fa 29rbyD12Fwi/a/hdz+9J/G4gZPi7Qg/fqfzZH0OlwD4wjrDviahhjwYsCvbrYBn75+nHkDgyFp4Z B5sSCfu78glkIkkm7C8H0oiBf49Imhk+71FtOGC4r0bKWMj/spK93TXgTLPibH+FrCEbyBayg+wm +8khcpQcJ6fJBXKFXCM3yR3yQFAKOmGCkCWUCBVCtVArNAgOYauwU9gjHBAOC8eEk8JZ4SJ7yyeC sA6rC0QYY4WOKCcuhqYoU/ZIZdo6aTcYcqSyaLdUFndJZckFqXyyXyrn7ZDKyjVS+XWLVNacJEr2 OSvPLSRqOF5Ykk7USCFhmbx+UwXThgjNSVK9uUIul8rlBak0HuXjlOYL5vfND1bopZql0lJvES1+ qdZS1FLV0tBil2qte1uPtp5rvSbNtyZLZbtGLt/jozTiUfGceEN8YIuzZdlm22p5a2zH/I6lHY6O tR3bOw50vNlxseODjkFnnDPTWeascTZLGnfmszvKWkliZ4NUdpVIZbdVKl1XpXGeWrls4DkneHBG xwxwLxnJecQuSigU5gqNiFlQOE/1dD4N0o38L5UP0WP0OD2P631FlMKgyMdVpFiqsCgOKK4o7iqL FFHK+UqjslX5kWqpyqLarNqhuq0uVZvVLkW+ehcfn68+p76B62ZESYQrol+ToZmtqcJJtU1zXvN+ JI0sitwceTpqbtQVLdUatJk4e0q0du127Sntuzqdbq7OqBN1Qd0e3Wnd/WhNdEl0bbQn+mD07RhN TFlMecz8GEvMxpgdyPGM0LfIk6HLZCZQBswKHRL+FPqW8AnwaehbVAAiQ5dpVOgQjQ2xj9SNx4xI ouDzLGTm4D3MS8G8CvIS6vVAA3A4xDJKgRmx6BkDZKAlQp5XgfUqMK+Cz2tA2+FQBR//rc+NV2Hs EYw9grFHMPYIxh7B3lZA01j06/lYC0kBUgE2Zzr6KtBeCVQB1agvQvkC+hajrAOGtIyVJMEGPWpj UKagN5WtDj499DaXJEk5NCyljutcgfNB0qMCsw9xnVOgfyqQAY9UoKwCpPW/hZmXMfMyZh7i6x6S Z1bIM+V1gQrMrgKkNVPI82irRVnHfZyCGBwmK3kMPr96JepVfLXLGH+ZsL8Ax7mEtccAAvkJ/wQK BffDIR4hFZ0WmkFLgGrgG4OraW1oBvaLpJ0G8zTCPbJe+GTwNrJBR4XB23RCaICokB+taBlAfrQi N95CbrxFFGitQe06atfxFVNG6F9wkiKmQl6oT5iGkapQH7JpJo0avE9jgYTQaoq4YeRBQofljBHy Q2lCAfAEMAO4R9qhwy2sGAcdblF9KI3GhfbSscjKJJQTgIlACmQb0JcdSsMJruB5ZflKq6tlPd/C qF9h1Epo8yS0eZLEonUv5jdAq3eg1TvQ6h1o9Q5G7oUm79BEYDyQBhiATCAbyA29A09h9YdXllaD hyvh4UpY9mtYVgDLfo2TfnpoJ5kUluGV4RkOaZehy2XoUgldGoRClE8AM4B7pBsRmAlZ7YjLTKx6 mUYDkEGxDuy1wFtb4a3L8NRWbrsB7ZND34EPLHQK2rKAbLTlhLbiick0lDSohAaV0KASGhyGBnsf GyNV6DBWf+tzsUpAFKR4HfpCvCj3G/NZFGT3QXYfZPdBdh9k9HEPG1BmAtlAbqiP54yUbeP+t/T6 shximTgAaQOQNoDIdELiAGYOYOYJWNOHmSeg2QBm/wqzfwWf9mH2ALQcgIQBaDlAtJByAlJOQMoJ SDgBCWzW7zHyBE0HMoFsIDd0As/fePRMBrKAnNDvuT/2Yv5ezN+L+Szr9kKDX/PMS0JpQD07tPdL VkoL/fyRK6lw8l3HqXed/DC0muwLnSH9AE6X0HacsYdD1fTp0BlaFdpO/wrlsyir0bYAqMHO+cbg L+iLaK9HBF4ObaPLwC0o21BaMbYdEEP9RE/LMGJ2qJ+Wo2cel3gb0m5D2nVIOwJp/0yfQ/s3MKMW 414KHaVLUTehvx0axUDC6jAJ/fLM+rBZ38Gs7XxWO/pswErMTEYGj0f2jg+3ENImQRqsIzPovMG3 aCVGV3ELr0OKGRZV0wasshR8WchIm8FNofHUjHIFYEF/KzRqB+9E2QW4sLo7ZCZqLnUBGQ+rrtMX wZeBN5EZyNWnweYhV7WyX9mKZ2DL72DL72HDTax8Br7cjlW3YRUzVjASDXTtheXXMXcPRjKLmY/6 h3wE/wzJWhB6G+taMIKtPZ7HZhlGNqG0QK4UG+ajM7QbM1Vcy5f5qNsYwXtgQw1vYXOuc3+uhIxu fBWtg++2Q5/tciS202exyoLQN2kNyudCjVj5jByJ67QRMxIRAYIIEHztzf4mvJrsg0/KcA7ODk2B lCOSVwbPIArvwI47XGI1l3oGevwOUodi2y/rBN0hw40nRcywPvO49dcx+i2uQy2zC1KY99sAq5RL sOQ6tyQFes2AXjOQGduRGW/JklZzq6SMuI71f809zeLSwOPSj2w4Q43c89uRESznd9MWtLcCbQDL exvQwbNje1h29JNM7Lh+7Lh+nKb9OE37sTo8gtzkeTnohgZPIDsQazxp2c5j0XyR52U14tQPLero EmBp6CloM5k2QnoT6s3AcvQbUUq5WodcrYN2k6FdHbSrg3aToVkdtQMOoANwAe7QUyRS3mPVsN9M q1gMuEeN8OZq7n/YSyLkzN2GbOuHbiu5bpbQP7K9gCd+FX/ut7PP8cL5wea9hq+SGCvDCTUbp385 +NOYOy90AF4+ELYLzIhdO1abKNv7HRKFGbU806Sds5rrVYP256DBS5A2tAO0kN+P0WaMXskjOGTB c3iWfUPeK8hHPlpFTSQOXrmOrHgLmm9DVhyADDaGZVgjl3oGPnxb3gH98Fs/3wVOtLuxR6L5ruFS cZqyk8qMXLVgF0nZxnbSAM6/O2GzruMrK/k8wsztfC0TVjfLWc3kUpwV41l+YxeyPcSksbwVUdqg DzvVIuQde52PZTPb8ERHD9a5jkguRa0RYL1mnCwWaNEe+g20uY1Rb2PU7/DV0Q9hez1O3pe51Wfk M+I6PyPaMUvku+UgPycUGHmb97K9o0UWnsEqJ2RPMdvfkXcY8xSb9xYbCYvegbZLZU0ln/6zPFI6 oSNpPXqGdirOSd4jDp/hb/MVo+E3M/xm5qPls2VYJtOrVd7n7VzHGdzb+uE9noJaKsDOnnr5xFuK fFqGzG3kUTgzHIU2tIlyNFRyhp2Rz45fcLk6WUZ/mN/Y3j8hx72fPfcwejs83c/9JzBdEVsrbzdy n2zFyt+E7MtY+RbPFBu87ZYjuD4sCyFfPsGGRiGn2AdGy9btg+wI1IpRK4atZ2DrGflk6efPdEqm 8+/lsH8KNR5P+AzCfpshG5eCFOBS8k+lU5FiXGryJK4IMpOUIV9n4Yoif4VLS17ApSMvkXrEowFX LPkJ3jH05OfkOIkTcoVpJF4oEApIojBDmEGShD8JfyLjhY+Fu2SC8InwCUkWPhU+JSmUUIGkUhVV EQONoNFkEo2lsSSLJtJEkk0n0mSSQ9OogeTRDJpB8mkmzSQFNJtmk0KaS3PJEzSf5pPptIgWs2cJ TodiWkEryddoFfZ9Ofv8MPI0fZ7Wkiq6mNaR+bQe/l9AjdRIXqBmaiaLqQU+fZG2Ujupo13URZbR tXQtacY7fJAsJ0LkrEg/+30P8i4pIsQ+H1hIBPtVlIuBBvAbhDis4M0oHSgtgAg4AY9c98pYi/E3 UW4ANsvYJpc7ZewG9slg/CDm3EZ5WK7vJkJbmVTa76E8KuNN4BRwFu2DKC/I9UuEdPtlBInQvRHl Flanida7olGsE+3thlYDR6no52gQX5exh2OneI5jt7ifoXV+q4Gh/ayM3Ta1uMimsz4QW9sp5GlQ xoh2sVI8x9AeL3a1TxBfYeOAuPbZ1msc8Rg34XPrBzkWgjP5mTIqMJYhD5xhPjjDsJ6tVMKw3vs5 msEl7OfYIB7n2CxjN7fpXPs+GQbxIsdhjGUYqh8FPxpWl/3whfqbj8EG6HIYuNTyQftV4BT4WeAG +E3gXstHHMy2QeCSeIVBVIIvtF4Tk8X9DEP+F7NaKUMrfMkgFol3JLQ84CizEQY2l6OU+RjzylFe bc0TqxGfauYDKX4odbwcioMUk41iFGTrZX3k2A6XQ7GVYzksc8iniDeXOR2ypofF7uFYjuTAFo4v i/1i8MX/5vztHBb4lcELvzOI4Axrwdfy/BjKlX4ZQ/UjHE5wzyPHH+PYhvzZJueThF9ybJMxlGNy u3WNePxRaD8IHx0M99djMDRuaE8O5yhsZxjOYfDDYfWH+x+Xwxdg6zbgNvLyNuYN5SYgRrXGi/rW +JF8BR8cqbciXmICYjI8XvSLepwrYfnN++X8HsZRvkf2P3zOiOnIe6D9FPQ4FVaXzx/sifcYWufb HAzDtgyfT3Jdnt++m7e1oi+Pg/ezsZh7Nmz+0HryPmM6c+SD54fVH+7PEt8HbrXOFv0MYpl4jMGW JAYZ2g3Yk4BtloSRfus1jrloB8LOrz0MtlTog7PRViXtY76X5f02jMrPw1Yvo1HCcLtZQtjeZ2ez zpYKHYGw/asLPxvERbBzUWuMzSqVj8svW450xtkKxVZbCeJUJN7H/rxiqxrxs/UjcaktQzzOMLSu raY1z1Yr72m+r63vcozs+3c5Ht738rnRdUrczjBSt77L8IVnzUj/NQ7oKmM/w9C+77rQGsNxqesq Q/sG+0KOoX0p2911A/NusNyBzRmYh3O967Z01nfdAwZbPuhWAlHozxmpj+wV67s4a999eO8gdvsZ uu5BV+DRdbZfpD3QrRfvSGh5wCAWdSdIaG3mKGuNYRjyS3eyjXCkW69xZIFnjdQfftZ054vnGB5+ dg7Zj6+atPxn5YT/lFzDfz4eqSpSFZEYVanqKRLLf4o9Vl2jfp5MUC9Wv0gM/OfX6fznyFP4T4Hz 2e8Q0z/SjyAlTZFOqGKqopCoFTMUJUSv8CnukHhVliqPBFWzVL8m31T9RvUbYYrqbfVTQqZ6tvoZ Yb26Qb1C+La6Rd0ifE/dprYKO9UOdYfwujZSGyns0v5Ie0j4O+1h7U+FH+gEnSj8kAjCR7Rk5Cs+ cx2wlAjmWyiNQCv4HUIs+MrObEeJr+rMXcArAL7CMgfl+kYZWzD+PsrtwOsy9sjlfhn9wBEZjB8j wgp8iW4+LtfxRt1UJZUr1Ch/KeMccBG4gnYdyvfk+vuEtG+SsZUI7TtQ7uL1cSQPX81XkBpSR5r5 77d4yTqyhewke0k/OUpOknPkErlJBgUNUZgbzAvNzebFZkvzSULNarOuMc7oBdOYaWOMcSOhpkHT PbPSaAW7Y7plum/0gH1gumY8vgwzTFdNl4wDpttgF03njAeNFWCnTSeNe4yLwM6ajhp3GAvBjpv6 jZuNs8EGTHuNQWMy2EHTTuMqYw7YHtMWo9OoAdthWmdsNSaArUVvo1EH9gp6FxspUZrOm94wHTCd NB3CGgPs55Lgq8DXoGdd88lliKqpxlRlzFp+FKzCNNta1vTB/7EsVfHf+SD8tz0E9Sr1aySS/97D GP5bC2ORV0kC+5fDdOQYYkCM7MeHiCVsIMY4xCwdZRLKLJSpQAaQAxTK9RIZs4C5QJWMGrmslVEP NMpg3AxYZT4EhwwXsApYA6yTOXKmrVTGbGA+53mN9Y2NjebGRtMrjVaTv9GBy8WxCj2rGtc0rsO1 CeVW3HcA7FrXuAt8L2fsOsDHAW36pZltCW3JSzPhuTHwP95v6B36Md6M/4JYKHks1DwWETwWOsRi JolWPTUcET0i8g2SqH4ecZnI45KsrlfXk1TEZT9J0x5AdDIQnQdkqnYQMcr5v7iSQMqJk8c6H2/O pBlvcs0HAbzBNeNNbYkSJd7WmvF21lJHNMvqli1t2Ii7cZmx4VzLSfaTfvpn+mdoepfeJYKqTFVG qHqRehFRIPdeIkr1y8hAlfbvtX9P1NrPtJ+RiH/XHCHu1lj0E51wDGcBcSMn3MgJN/LAvYZQ+zWU yIumB3iLPAkQCazuRp64twI4W5pOy204Y9x7pbr7wDAEH06KhgYJduw4O05z9yGUd0fawxHebn8g lSvpo8e//FupPXjtc/1cD45Dsm5MlwHIiSHk5fMjY1Fym9xv8HF8HT4f9rqZHeeB3wLvyvVrMv8A YHZgvvuBNGbIN5DPYcMzwUN5O10ZL9nCgTkezcj6nhhpLMDXZjJsex4J3s/kNTTQ37maV78XKHVZ Vr8fmO0SV98KVLicq+8E5rs8q+8HFrq84ItdopegXfSqAw2utV5doNll8cYFLK4NaBFdm71JAadr mzc14MGYDIzZ6c0JeF1ebyHmgrfaMb4ksNa12zsrsMG1zzs3sBlzqzDmIFbc5jrsrbHUuw56a8EP on2t66i3PrDT9aa3MbDbdcprDuxznfVaAwddF7yOwGFwF/gl76rAUddV75rAm64b3nWBU66bSyyB s67b3k2BC5i1NXDJddO7Ay33vLsCV12D3r0Yc9V7ILDbrfQeCtxwR3kHAjfdeu8bgdvuBO/JwL36 +d7TgUG0nw8qMea3wSh3svfdoL6+1HstmID2DzA+3ftRMNmd5b0bKHXnszvzW+sRd5H3QWChO99H 0V7m0wS87nJfDO5BXylWDL9v9M0evgfZnVkXzHdv8VUEDn7uvt1XESxyv+6bHzjr3uNbGCyT+X5+ 7/ctDpxyH/E1QE74/VjY/bivGbb8kt8lfs5nCZa7L/rEYKW70hcfTHft5Npe8TmD1a6rbFbPfP8r fanuat+EIRtli+74Ngdb3ckYaXe/5/MEF7nv+2KCXe5FfIzkAYnXcb7U+yCY5Tb6DIFm+d4q80zc 7b48yAy/d/mm4/7KyN1DfNsQQSnHeDQ9at/OwAaPzrc7cM8T59sXmO1J8h0MviLlrft9nzdY5/Zj 7lrY60G8bvnWBpfC3g1BoyfVdzjo92T4jgbe9OT43gwGWU4GN7Lo1zux+qngFk8hYlE0xH1ng0VS 1sl28QiyXdOez/IzuN1T4ruA/XIBqx8e2TvB11mWBvdAw0vQsJDF0TOLWeGZ67vKLPLdYBb5bo5Y 57sN66qQPw2eGh7ZRSyXZG7n/ufx9dT67gXWeup9g4HbnkbOzZxLnrEyz7BdFtzP8jnY73H4lYHN Hpc/KjDoWcV9exw5oISNMUPcswae3OlZB08mezaBb/Zs5XyHXx884tnlTwge8+z1JwePew5wP2xk fvAcgpfsyNWzgYOeAd+pQIXnDc5P+tODv/S84c9CDhf505EJUj7XsVMFY8ClWMAiFovT4HZkLOPn vSR4zvNbfz54lb8I3njXXxY45bnmL2/Sez7wVzZleT5iWeS565sfvOh5wHgPZVzKqx4NdsoVdlIF 3+uJWWIJvu+J81cHLD3x/kU4GXBqtV5k50Pr0p4J/rqmLOb/tk0su+ot7ARrPcLOiuAtfppVcH6n x8D9L+0pKRZBxtnJ1raOnSHB++GZ2ZPpX9pHevL8xj41zgT4uWc69/OBEY74DvufnYd9On7ybOwp 9bf2xfXM9tsD26RMRqyx13oq/F19Sa86/K3r7r3qYr2vrvK3WupfXeO3B/WvrkP74KubePtW3/T1 Ss+616rXR7l2+v04aa/6g9B2Q28tVozqrceKyOH1emRpY3APNJkwlNuv7lh9f32ClL3uImTvQrRX wOo6Fkc5ptzPyNiFyF7uZ3b2rpvNTvs+HTtj1ycjk/MCFVLGMuvWp+MUPb8+C9k7nIHstF+fL52r TGdm6WvV4LvgmbWv7uX7l+u2qtlXukG9ysJjHYNYX5FPDB4F7iVZZs9C/8a+jFeSe3f1nexZ7N8S rOxp8G/vy+lp9r/eV4iWPWhp9u/nnPVa/P19JT2i/0jfrB6n/1jf3B6P/3hgfo/X/8uWGxh5jo+8 iJFr/Vf6qno28Mhu9r/XV+O+5X/fcrdnm/9WX23PTv+dvvqe3f77OEVv9pLA2Z59veq+xp6Dvbom vftib1xTVs/h3qQ+c8/R3tRgQs+bvRl91h5Pb06fo+dUb2HQiJElfa6es72z+lb1XOid27em51Jv Vd86zK0JGtk51rdJeoZKT6ueq72NfVt7bvSa+3b03ESm7erZ0GuFbrd7HX1qzvf23Ot1Id8G/yd5 3x8WVXYleN+rXxQgVhOCSAihEQkxNCP1AaEJAfLqB6xRCiq2IQSqCpoQ4xhCM8amTVHQWhRQlA7t GmIc47qGGGMcw+cSP+MShybGJS7LGJu4jGP8CG2Ia1jWMQzrMn6455z3XvEosTWZTPqP+e53zr3v 3HPPPffcc8+979WPt8/Tddat3uftGnCH7/N3XWwe3NfTcUzcy9yGfb1dQ+7YfUe7hjwN7bcCkZ5d 7VOBaM+e9ruBOE9b+2wg0eNrnwukeALtC4ENnoM+FtjoOezTBnI8x3yRgXxPny86IHhO++ICJZ5+ X2KgVNyjPed9KYGtnkHfhq4c6RRB+7UUhzfievcM780KVHpG2ncEXEr/wRUHKwJWXHeCZwzOA9MQ me/7A80PcBV7xn0bA/Wem76cwE7PpC8/sEEZTzzTPiHQ5JnxlQSaIUJCRAU6RFHPA4xdEOVwF1bE 8zcc6NuehxSjlPEK/DzgQT8PeJU+Dz4MEQDkLEUDMTJHYzT2LL65GPC3qpciM+xlsNJhvOCfnmFa 9VdxF1ZG6dZwX2mgp9Xg2xrofaNxb1Z3Z8sdiHs3W2N9lYGjrQk+V+BEa7Kvvus6zl3gFM5d4CzE lng5Giv2nQzYr9PleOUxQ4+7IObAanIn7zvVWeFO23e2axTwQNcoeZdVXC+AL+Kq2TfUWefO2Hcl SM/aN9p13Z2373rXBOAJwEX7bnfddlv33em64968717XCbd93304idH8uiv2zXfdczv2Peq6767z 8l3zX4/3hoEP38BzGmKQv8Mb1VXvbnzzcNcj925vTOctt9sb7+e/ft4bD2sEsD/Mvdeb5I9yd3pT /TGE4/EsB5hisojdB7zp/iRpXIe8Rn+q+4g315/+9T3eAr/RfdxrBv1PejcBPu4t8+e6E7zb/AWE ze4z3qrOPPc5b61/k/uCd7u/DHCDvwzX1/Z59yXvLv8292XvHn+V+6q3zV/rvub1+be7b3gD/gZx 1mBcB8FKt7yH/bvcU95j/j3uZG+fv81913u6Rv3GXW8/lGe95/0+nC9/gPBBRTngnvMO1uQBHga8 4B3putLCvGP+w+IpukXrHfcfE+3cEum96e9rifZOdoa3xHmnHVPQ+0xnXUui94H/dEuK9yFYdc67 KEtr2dCu9ve3bGwP959vyWk3+Adb8ttj/cMtQnuCf6SlpD3ZP9ZS2p7mH2/Z2p7hv9lS2Z7ln2xx tef5p1vq24v8M7RHxOI5pzur5Wy7vTuveaS9Ak7jcL8AeweczLuLYL+4221tGYDy5paLb45328Xz UstQ61x3RcuVtqbuBOCZ67YivduBZ6TuOix3zok8RN8B9AWg076DntzdKJZbRkHm7pbr7Y6OwZaJ 9jpY40feHOx277mIZ4MWOhvgvUn3XrwL6Jx7Iw/XTvWuIP0A0rsPYRl2duSZVe5Zb+wGOQ0td9p3 dNxsuQf8ycDTC7rdB/7jeE7oPtIy1BYHesIJwV+w50p7Y3eFo+7NSX8B0Y8jvfskniK6z4g8LfPt uzv2tDxqd3dMengse8KwjHdJsg+/kfYm37kbVuW27nPNtW0p3Rckr8byJSyDrRT0Nxztezu2eaLa OzumYS72dud5Yto7dw564jHOgE0gzuBppDsZTyPdl6l8lcrXPEntB/Bk0n4IToawg3QXoYd339ij bT/SEageaT8OZ2lFGfm7i5C/+wac5AWIjantJzsWlfEKy923sFzZt4yOe/0U7fV3qYz7+/WOGWW5 5UT7mY7DnvT2c53heA8IdLjb6k4TzzAe497G7llPbltp9xzef8GI0tovdO72FLRfqrF7zO0XIMZu ar/cvQCRDc/5l+DMMAxxPniCxfvHbgPtbuewHGBYrqwiT3B4ytqvdix6trVf656FuL2nY1jcBTxV 7Te66veb92/aX9Z6xDffVd96yHe/Y/zr23w7YXc+72vyh319xNfcWdea5vMEBlp2tlv9D0TcmuHz Bi62Zvn8gaHmWl9P4Eprnq83MNpa5DsauC6d8E/7TgQmxNgirv1Wq+9UjV26wxXvbcW7WsUdq3Sv SneprZt9Z0PuVWkHb7X7BgK3Wyt8F/0NrQ7fUFdJa53vSuBO6w7fqJ9vbfRdh7tFktO62zcRuNfq 9t327xLXr7gSsd/AfeluGn2+SPRkZbxd0iQwr4yQOHcd03iP3J0mjosiRoJ4fy3GJXEt4w4SeIQ7 SOCRtNJpDbbubdu5n2/t9N3ZHyZ6SOsB3739Ua3HfY/2x0hPJ+iJQevJ1qn98eLTidYzHTzYVnwW QXf9rec6wvYntV7oiIIe6ZmDaDfxqYJ4zmy90ZG+v0B5RymVxecVtIJaL3XE7E9tvdwRvz+99WpH 0n5j67WO1P25+C8l9Oswpvh1GE+/DlOHCWEVTEO/CEugX4S9SL8ISwnbHeZmfxHWGtbNcujXXib6 tVdZxMciNrKtEf8r4nesin6h5qTfo71K369JYZ9ijJlZNYtntexNlsW6IG1lPewt9go7zv4z+xy9 mezz7AzrZ5Xsx+wic7Ir7Jeshk2y37DX2G/ZDHudzbPHrIXjuQ2sg/NzAdbP9XK/ZP+F+xV3h/1e vUP9FfYv6j7199hj9aD6bU6lHlW/w+nVd9W/415Qz2tU3Ac1KZr13DqtXzvIrdcOad/mKrQ/1f6U q9SOaH/BfUH7P3Va7os6vW4N9w3dh3WJXJ/uRV0rd1LfqvfxGn2X/iC/Sv9N/RF+jf7b+jP8h/Q/ 1F/lP65/R3+TL9b/Sj/P2/T/Eh7Dfxk/SeH3RURFrOa9EdERa3hfxO2I3/KByK9GfpvvjZxbxfE/ WxW/Kp5/Z1XCqmR+fNXHVn2M/8dV6avS+VuMA7vsoCelifiLGlsKwAaAjQA5LN62wbbRlmPLtwm2 Elupbaut0uay1dt22ppszTaPzWvzQ6nH1ms7ajthO2U7axuwNeMvtGhuWZgpzMT4sE1hm+i3bNF8 Op/OGJ/L5zKOz+PzGM8X8oVMxQu8ianpO0Nafgu/hen4V/hXWBj/Ob6S6Xkn72Sr+Fr+VRZF3xYy 8F/hv8Je4L/Gfw1kvs7vYR+g7wytAXunsDjtL7S/YGthTBPsNo0sGn+5Vn6Q1ZYfLD9cfqy8r/x0 eX/5eVuCLbl8sHy4fKR8rHy8/Gb5ZPm0TV0+U/4ArsbLH5Yvli/a9trV9nC7wR5rT7An29PsGfYs e569yG61b7bb7RV2h73OvsPeaN9td9v32jvtB+yH7EegzVJKkFKWlCqCyS2l4/aTAIfsZwDO2S/Y L9kv269Cuma/Yb9ln7Lftc8Cx5x94bPss/QbM913wZqxy/wc/5chizWC1+axN8DnBfLzz4B/97Mt 4OE/ZqXg379kNnYPUhnZqFy3Tree2XUf1X2UvaL7uO7jbJvuJV0G+5xuo24j+7wuR5fDKnV5ujz2 BV2+Lp9V6Yp1Jaxa9wVdFXPqHDoHrBeOHYWVhFZOZhrGSi8DXJXgGuX5pUOlV0pHS68Dnii9XXqn 9F7p/dL50kc23hZmi7LF2OJtSbbU0iu2dJvRlmsrsJltm2xltm22KlutbbutwbbLtsfWZvPZAraD tsO2Y7Y+22lbv+28bdA2DFcjtjHbuO2mbdI2bZuxPbA9tC2WqcvCy/Dfj7iw18K+Rr8JDF9mrTcg ZdE7NLPZu5ByYNX/hn2C3YWUqyvTlbGXda/oXmF5ujpdHfsk42AVhdNnkhuYjrGqfACBcU7MSwBK GWe+xzjLLpWxKseZUpXv3EC5XBacG6tKnDkEpc78qq1OgcpYV+ksIT68lvnw2uUsXSan3rl1mUyU gTw7nZXBvMnpCtKbnfV0LZc9zp1UluvlNqiPzId1KB9zBKz3wrVX0S+W/aCjV8EXCtguFFAHJcj9 hYKsmxJw7LJdZD5ZL9RFto2sP9J7JF0xR+iFcSoB28kgy0JA3XCcmB+FvtE+2B7HIPchjx3nC/VD GXiNvC6pDfLK9pPnSKmjLOeEsyloW+TrUeSyLqeczZSfdXqoDcqSc7lvb0h/su7YDucX5Q04vU+0 7wnp96LTXzXk7Km64uxdpqdS9kq6Yi7rIuclimvUB69l++DY5Lw35BrboM4yv7wWsE5eG6POo5SX hPSV85Txy+PNCRm/fC37kDy30JcjT6SF5kEe7PO680R1qnO+Ot356An/eI/cUfR89cv4Qu39HLnD qrgOtXNJyHy9R056KOkw7qfmkl1Cbe3YLNrpWfkz7SiPQ+n72M+E81Rwrd12nq264xygspzL8VNe y/ecF4N1951D5CvzzivL4vAj52g177xONpP9EfquDnNOVEc5bwfHCHXVMc471fHOe9VJzvtEk+MD tK02uvjqXFcY+aLsk5BXF7iiqs2umOpNrngai7S2qstcSQiOHTVqR2NNOPI7dtcYHO6aWMfemgT0 V0dnTTL5LfTjOFCT5jhUk+E4UpOF7YO+utIcH1WsG4nuOA79jbv6qJ+TS30E68/U5DnO1RQtix9b 38M3e0PWdqhPhcaU0Lgk2wj8yHGhxirr7bhUs9lxucbuuFpTEYxDsg75IXFIsUdVb3OlIgT3PdlP pOvqKld6da3LSLDdlVvd4CrA/qt3ucwEe1ybSE6bq2zZ3oS+4HNtqw64qpT7W/VBVy3tuTJI/NWH XdtJzjFXQ3Wfa1fQH0Og+rRrD4GsN/pQv6uNdDrv8lUPugJkH2nvrh52HZRly+unesR1mGSNuY7h 3NL8Kvu46TpNfjvp6sfx4hirp13ngzJnXINKe1U/cA1XP3SNVC+6xhxq17gj3HXTYXBNOmJd044E 14wj+XNtjjTXA0eG62FwDaM/yPOpzEPnPecZeah/5YfkEt1hh7VQAfor/U3eJ+T9UrkXhe5J4K8O h+SvK/HJ+xDGVofirCDljjo4z8F8yzmd7zB/1jjfK9bi+rOLsUTOg/YLPWeE7n/y2PC6NySXzzYh MWlZ/jR9lev1qCIeSPMejD+h++rT4kbofKJsuX9pDaO9XxdeL3nibIt2uVbjcGS5FhHoDIMgx3s5 NiDgmNFPbtTUBdcwylKsUXn9Bc/GqI98JoF9wnGrZgeud1z31PdUTSOuP6U8x92a3U+cvRVnbsds jXvZeVmKUcH+pVgUPDujznM1e2ldwjp2LNR0yvcHTlZzIGg3SU+ntuZQcL4UZ1dnXM3JZT6Le5Rs I2wXWXPEGV1zHO/iw/aH/TVjEZn0D0MzETMM/3039c/7fEWjYo/pOYqTnqPUaIe0P+UO0ROUw/QE 5QQ9QblOT1B+TU9Q3tW3hsfwAj0XmaDnIv9Az0X+kZ6L/Jqei/wOn4uo4vG5iCoNn4uoPobPRVQb 8bmIKhPuaPvY6aWnBwUDrKRgoOBiwVDBlYLRgusFEwW3C+4U3Cu4XzBf8KiQLwwrjCqMKYwvTCpM LUwvNBbmFhZAMhduKiwr3FZYVVhbuL2woXBX4Z7CtkJfYaDwYOHhwmOFfYWnC/sLzxcOFg4XjhSO FY4X3iycBDqmYUhhlNIp4dUxAiwD4JOAsM/j9ydD7m33wIy0sFa4qz0L6WW6z81jv2DX4U52HNKn uJ9zV1mB+pr6HVaEz6ugJccqmGNpvNnXWXJ+Un5qfnq+MT83vwByM5TM+Zvyy4C6DY7VVfm1+dvz Gwh2Zd/P35Pflu+Dq+2AffkB4ErN30461oGOa+iXbgy8JxVoaZB4uJfewFQsHZKaZbC/YBqWyYxw f53NcpkedDKzVcwKKYqVQFrNNkEysM2QXmClzAaaljM7iwGfq2Cx9F918Ww3pA8xD6QE1gbpw2wU UiKM/R32ES6Ki2Iv0r9xeZbGmhOtMgolQqmwVagUXNlHhHphp9CU7RCaBY/gFfxCT3aj0CscFU4I p4SzQqIwIFwUhoQr2XM5gjBKkCNcFyaybwm3hTuA7wkTwHVfmM+ezT4uPIKaxk9ey2EmPnsB+ikB XhdKFc5mzy0lU5QwKqbsW9m3TDGmeJIipwkxmZJMYUKPKVVINJ0mWT0moynXxIM+JSAVwSU0SamH 0llMoJUH4ATocwW0qMw+KQxBqzhTOoz2utBkKjCZYfyjCDCiEtBnk6lMqIRypWmbqQqkjpIEGfyg DUIP6HY0e5YApJtqTdvBSo+gzwkC7A2hJG/M1IBy5V5IogyoA4BpF+Q7oRVCE/QigWmPqQ3m47bQ /Mlw4Y4p1eQT/KaA6aDpMPVPOmT10+iUfQOYjpn6hIFPXsPRgkWxJAOOH1siZ4k5j3R7Alaim/NM B83hy/RXANWBzuYi02mz1bw5qKECVqIjzWyn+ZoIBaSbK3CWJUA90DaS/qb+7OM5gum8aRAwwjDY aRRmbiRnK1yNmcZhPm8K9aZJ07QQB57RTH46YZqBOZwHH3pgeph9RrhvWiQbusxqGANY0mwwx5oT zMnQI8yhOc2cYT1m7TNnWU9b+63nrYPWYeuIdcw6br1prbVOoifKM4k9WKetMwjmNOsD4bbYAuus D62L5DuyRWXrNZligqNS+pVkhWJ1cXixoTgWvaM4Iac0e+GTc8XJ5KsHi9OoBdgmJz+nVBjKEbKP W05YTuUIlrOWs9lnKC1YBmAMaZaLlqHsM+YMYSJvDNZaI6637FuWK5ZRy3XLhOW2MGG5A9EgEWzl Nx3OPpl9EmruWbbCaj5kuQ9S5i2PLAPZZ6x8ttoaBrpVWqOsMdZ4gCRravYcSLoCUo9b061Gocea ay0QTlnN1k3WspyN1m1UUwX22m5tsO4SSqx7rG1WnzUAsQe9rTRHMDvMdeYd5kZYD1G4AuF6t9lt 3mvuhPyA+VDQ08bMR8zHzSfB445kH4EYVC+vHvMZeRWZz5kvmC+ZL4Nt43FOhGbzVfM18w3zLfBO hCnzXfOseQ7i3L0g0No2L1iYRWuJtESHeipEw/sIODeWOEsiQYplA/qOZaMlh3xILoMXWfItgqXE UmrZaqk01VpclnrLTtD9UNDDQaKlydKMq9LisTQJF3MYwZDodxavxW/psfRajgqPPnkNouhctv1L xzDaFmcUZwHkWQ9aD1viwJNLhK3FRRC1T1m25o1ZJ3MESDnFVujjfvasKR6jcfZC8eZie3FFsQNm /YhwHzxlrriueEcx2Lt4t8lc7DZNCvfNR4r3Wh4BpbP4QPGh4iOWO8XHi08Wn8k+AHHMnHW6+Fzx heJL4CVnKeaOYnQqvlx8lfx1iCK9GCkbgTInPCq+VnyD9sIv/js6QW1njfTMHP9Pn2VZGQcQkyVA KoFUmlX60rWXrmVthVQJyQWpPqv+pbsv3c3aCQlpTVlHs5qzTmQ0ZTRleSB5Ifkh9UDqzerNEDIE /BfCMGeYi/5t0cKKwa7/gX0GzhVb4HSgZZ8F60WAnavxFyCRdyMfkEb0WdenrzLOXAf5Nch3qIyf vmx2fPoqwGUJsHwN4IYEtwCmpDLW3ZX4bij48Ho2RM5ciMwpiWdhKRfYEl3QStdyOVLik9vJbW8t 8VHdZSmfkuovh/Qr66rkC4WFJ4F0UECwv1CYXQHmVujzskKXOUVdqK5XJbgVAjcUoBgj6XZVoeMt qf1CSB9T0nzNSjKmJF65zWVFG3mOQttjf9EKPReW50Fd4qQ8UeEbl0P6Xqk/SXeaX8xTVmgf0q+w AWAjQE6IvkrZK+hKuazLSvmsIr8lje1p+ZSks8w/q7CHpLeQHzL+UDuEjj903KG5cn1NSX3JtND8 8lKfAuysQi/A0ZXn90+aP83uz5uH2vm95usZOY77mXmIjWU7PSt/ph1C9ZfllyzNvVAKsFUqb1Xo ofBloVLB45J8pd68LA7DOcghNJmXYoYcT5sBPIox4pi9AH6AHokmxwfU9wTAKcValPOzAAMAF5fP sTAkApyuHKZ+kd90HmAQYFj0RdOI5JPQD5yFHKZxgJvS+GRffa+1qKBTX2apH0Ufcr1pEmA6ZE7f yzef5WuhMWWFuIS6oB+ZZpb0Nj0AeAiwaH4yLofGIcV+IVwRIbjvyTFC3jtHAa5LMAFwW+r/jgT3 JDn3Fe1kX5gHeLR8fzPx4p4rg8xvCpPsGQUQoxh/CJjiRQjqDXY0JUnzkwqQLukn7d0m45Jsedym XElWgTi3CMv62CTaylQmjRfGaNqmkFm13F6mWoDtAA0AuwD2ALQB+AACAAcBDgMcC5mT2RXyp837 0/LnjXHXFHvHSnvP0/KV/HUlPuW+vFJ+V5rv0PxZ43tWzJVjyTXzk/ZbKZf3v2flyli0Uv688xMa D562Zz7vnjar6F9ew2Bf56Enz7aYm9Xgd30i0BlmQ0i/ynMgyDeHm5fWMFu+RuX1FzwbL5iDZxLc J8wGab3PS33HiutPKc+csKRfqGyUa05eGldQviI+ybFIPjuTzmliPa5jc4Y5eMY1ZynsJulpzlvB T6DOvHm5z5I/XVa0KwKwmh34vSf6N3z27+dek+vB/0pnkVwUK2LMaACIBUgASAZIYyx1B+QZAFki pHggzwNAfqt4TbTNkPdI/PYlSPRDXiECluV65DU6pLxOoiM0AuwGcAPsla47pfIBgEMARwCOSzyy Tg4JsK+TktwzAOdCdHc8BS6woszBzOHMkcyxzPHMm5mTmdOZM5AeZD7MXDSqjerMh0mNQKNkDDca jLHGBGMyXD00phkzkiqMWcY8Y5HRatxstENeYXQY64w7jI3G3cbN6w4Z3YnaRK1xb+YDY2fmg6RG 4wHjAaAqE/5fW/ST3/SlN0Co6d0PH6R3PMTSOx7W0tsdEui9Dh+m7/gm0Xd8X6J3OWTSWxyy6P0N 2fT+hhx6c0MuvbnhZXpnQ+GfvT+Oi+bEb81eZB9nLDOdsYQ+ETKNALkABUs0JSjpmWYp3/QU/iSR nlkW0m7b0jXVb5LKVaJMgoIn+wP4+MaBjRdD0pCifEVRHn0KfYWEb0akb3IzesOH+G4PDX2TO5y+ yb2K3u0RR+/zSKA3eXyY3uGRRO/qSKa3dKTSmznS6G0cH6P3cGz4N5PLsbNsYOkzoBd72Zb4W3JK y10qw5VRebVyElukGZE3rUCEJ+vfS94Sx4dYKCc+OeR78S2Z/HH+JxDW3+Z/xhL5/8ZPs3Xa17Wv MxNGT2aO+HHEELPQm0XiAKKld3a8GGyvhvbgB/xJ/iLT8IMgK57aJABHLGHJHmuvM27tKLX7NmJ8 6wzLZQUKjn4WvXYkPnz94Ecerp9Ze37tIKRJSP1rh9eOrB1bO07pJsk4jN/A5b/Hfw/6/lv+b4Hy Q/6HjOfP8eeYiv8R/yPQ7L+CNhoY0wgLo9GEg2Y/YRERfwf6GWDFdXIj9OzOzl6A3mGVpSY8A5Kf WsetTWJb1tohza6dja+HtDN+J5Wb4pviZuJmsLy2cW0jXmMd1YdD2iym9VPrp4J84e+R5iDthbR5 KWHbZTJlPmWyA02GWeCsF9sg7/q59XNxM+sXQL9w1I/aF6UySb9wqJuStVL0EE7tSZ/4Zmo3K2sB dNTrLqTZ9TTutQZIjVKSx7CwdoHmEd/LxOjtRpy+Ul/NeL1T72JafZ2+joXp6/VfYnr9l/VfZhH6 r+q/yiL1Tfq/Yqv0u/Wvs9XP7cMcd4Z7SPO9G84tbI3w/LCuCXbIWoDtTwLWIcTBXpFSJeZwzaUE KN+ypiB2fs3NuIo4+7qxNVVxFbHzsfNw5YidWDe95uaa3DVVUOuIc6So4yrWpK+biVPHqYEasyY3 dj4lfN1Y7ETsBPBBwnbYGuRNSjnQ1pRB6dGayTUNcXWQ58oQV7FuLCUBWkxAb2poqxb5lEC6yfCE jusmSccqKIN+cXbgIf0gB92gbkyp05I+QJH0wXGi3DXpIqBeaxrWja+7uWYyxQCSHwGlChL0Ai0m U2LXNKyZTsFP8iP5/TzEaP6b/DeZnv8W/y0Wrv+8/vPgAQ69AzzgVf2r4AE79A0sSv+a/jX2AXo7 VUzE7yN+z9ZE/HPEP7M4ev/U2j8oxlUAlAE0UJRLpt+Y9LEDcJUvRT56fzG7TN844NjNJT7OwBbw DSpBPg6i0d+AR/MQj6h/6i2ResP3EIeRpzPydDV5upY8XUeeridPDydPjwBP381W/YkloTUYWUND 1lj/PktCWx9hXpoB0YbryNai9fHbMzKNh532MM2Aku8EWZ9jFyTan87C7z2TytonLfF8tah/r+R7 Z0j/FKINSWO/oaDdkXxvYYnGhYlj5xIlGv4D2r9m/eDKiXuqv2lJEiNJHEniSZKKJIWRDP1TW2ue 1Iz6jqBeo57qUX9su+fTFr3qjDQHoletJ9o1OI8vrX6RtiDNgYLGJUpzINP+bWfgeWzxr5u5P/8M 4JuPRuk0GI//Zv4CnKtWnyDYYohbPbf60gsxBOdWX8L8hRhD7wvxqy8Z4qAk1ie9kGQYMvQCbcgw BFcxlFIJp7+QDrQogjhMyyXK8sQakqSQs3oOruaQG3sDLPY8ZKAZ0tfoa2B0jfpGGN3X9LjWn/tM ws6Rf0mfaEedJdhiEAwlhlLDVsCVBpehHtJOgCagCYZmgweozVDrNfgNPQC9hqNAFwwnKFUSfynx KtNyibK8ZrgWSBLKqYdyPVBKoM4Pso4aTgHllOEs4QED6srra/W7/tgRrhol2LI6cnV0VOPq6NWR UddWx0EeDTiRUmTUjaiEqCLAN5Au5SmrN0CbjZigRaKUNkgpklJ01G5qIUqU5EH7IlkSYGwTGbWZ StEgLRqucwhEvIFG+EX99j/g3MBzKXTnd0Za/an4f/zcKe4EZ4Trw0oqH8WHcbh37V1G3cU3cItw vXMZ9SY/ztfB9TYlVVWkyuOv0v8RKqknVcdVG+F6g4LKq7WqXkVUSlXMXjR/gv8OjO27/EnYg77P fx/ul87wZ2CN9/P9MPIL/AWmg5G/zcL4yzB+Pf/3/DWIadf5d9gq/pf8L9lqfoKfYAbQ8iZ7gZ/k J0Hmu/y7EMcuRlyEOPYTuNf6INxr/R3N/LNjx59XI7yH3E/4rfex72+9L32/9T72ffB97PvQ+9j3 N97Hvr9FMaqS2wonxHQpFnyUaHZuM/6L7TLaJs4MNPUymsDhKfT+MloelwVXt5bRjCCfYyPLaBsg OnIQH5W0ZA6fDB1fRovn8PQeWEaL5iLhqnkZLZzDd3nWLaPx7JHi5PZR6ZQ2pzi5ibQHbEZxchNp 9+g0FxOkYdzH+MTo1MLRqYWnU4sKTi074U6iAc4uumUrKejZ+h3LvBzxf1TQxXLtkjfiiSjomW8p yvsVXqMsv7VUltp+QyHzG4q+xPJfLvM+HG8a3Jvy9GxOHHHaEh+MDvnOMfHpHsfC8T1y+A5h6XrZ Xq7dypjOyLZoa7Vl2u0ADYCTIN+l3QPlNm2q1gflgPagLkN7GOjHtH1AqYW609p+7XlK2+GqAThT gSamWkpKiUvydmkPggSUtCQH+dqAch5qBwEwDUM6rB1U3H0972llioulEeJvBJhGAKgEcAHUS2XY ozVNUt4slT0SeCnfoinTFGi2AVQBjoK8VrMdyg2aGM0uKO/RtEHuA3pAcxBKZVB3WHNM00dpG1xV AWcM0MRURkkpcUleLclCSUtykK8BKH1QexoAUz8kn+b0H3lX/LxP2KIwxoD1mthasEQkY6rJJcBr TeJykOmrHwIsimCA2GMIF2kGA0AsAHirJmUJJJlbVNOqafVuwOOq02oD4IeAZyCdVodDjVu9Vx0O qRPSAdW4ukh9SJ2hzlLnYVKdFjmBN0NMKC1U4pI8kgWSluRA22nVDNDyoN8i9RHVQ8itkI6ri/5k d4B/lO35I2CfjUuA1/zUciA6xG9VDgDESRV4u6pEAiyXAsAaV4HX87NLgNdQv4XfAWkBoILP4A8B dgNuhJTBH+B3wKFUC/kBVSSkaKi9rIrjz8HudolShsSZgU/sKe2QklJiUB7KQkkKORn4hiegXIJ+ L6sSAbv5q/xVVQp/+c9te3oL9YLidI2flYQtNi5GLhYQNAIU/AE7C+6EHM0mxuSRx7nBGM3URxE/ hhjPXXgMZW4aMZ+q9uBn1kQZRn6uB6ITlBfxE5ZpogwvjuMzIuJJX2ykshY5qTyHmE1rewjD3sk5 tFHYlxb9ipEcpm0i/nEmvb+di8JnViCdEYa7FS55EZ9a9VItnTbEswTnRsyH0a4jngaOEL5OtR+g Mu3q3ByVxVPENLXaSPQewqNEqaBaOpFww0Sh/Uw8y3B0b8SbqTxJ5TbCfsKphOlei79DeFDqMY1O JWmkcxrJT6R+00iTNBoR4j7ip/MLrDrEFxCrvCTtIZVLCN8lTjrVgF1EPVcDxUqURuK5Srie5Nyg Mk84C7G6n3AG4c0kTTy/0Kno8QSV6RT2uJNkPqK2SY/HcXSIuTkqV1C5j3A6YhVP5SaqPUZ4kHAC 1Z6hchvhU4QPEb2UcCPhu4S9hKkvtQExW9AlEMbn6QvkUSMiJSyJ6IOE28ij8JTGiJNp7lNZpPcQ JY0oCYSx1TT5Hvk8+GQjjov8vEdDdtDhShwgfItkDhC+pcVz6QBiPlVDPoCt+FStAzHxT5OEaaQD xk9Ip0U6+f+09gZaUkP+iRTA6Yh1GwnjmXmY8ByOguvBtpxDgyvCQTwOkUd7ATHJGSbOYYmTEW4m i4mrT8Q9ZCts6yZpccTppto4rRsx1vJmrAU9LxCepFGMECa62LsmgLOv7UPJaowqC4g5N2KwiSi/ jjhHEKspnhDnAPgyx3+JvPT7ZP9bhAekcgaVM2iOxJijJdxPFIoti1XQli2WYC+LJyhSifHKQNGp kTDyOIjueJxCvooxKo5wIrVKpGiWKEawxRpc40SZFCUQ57SIURNO8hnygWmyuYNmwUGWd1M5Du0M /jBHmGacLBNH/HFk1QWy3jDZc0GcO/RP0AHH+xhOVxAPkQdqxTKemX9Kc/rPRL9P9A9QeZrwdYqx vyacqP4i4HyydhrhGMJMwvGEv0hYS6tjgPBnCFsJv0W4jnhSKIKVEXaiJswIUWKKET89sWL4xFvV iHMNK/ooYtFKuGpUjYg5xyKtd7RtWBLaX9uDWGNFC6uPUqtIxOpctIkqUtxB0HM0AZFOce8UljUj aNuwu1irpTWrniJrj6AmEG3GAL/7+J8A/4DiWAKWOYqN/JxUi/hl4tlP3kjyuStEYeQ/tBcAzxhF P5TQSPgV4uyj8gEpMjdQ/Icdl3ejZVS/wgjPjy56qYz8r9BIDVjWUKRVvc6+C/i8uG/SjjCMWHWe +qV7KnUEcW5HO6t+Rf7/mGb8MfnDfYp7jzEeLo6j/Rcf0GplEOm5x/+E88v/QKS3dVRcwbI3GkLw EByCuzuDu7u7u7u7BE1wC+4Q3IMFD+4wuFuwwW2wgYGXe757zrnnvvW+f95evVZ3V3VV//pXtWv3 fg6BeSM1oknQj30wFQEqFilJ1sRK1yiJk9RoQV1+3B4lFwengi4xIyvdSOordkmSWbVcRGtWxTx1 BaoSySI7ZQ/oBl/gk000IgRdt2HTZeyYMC5Cvpg0Ee+jVc6EcxkvPha9iDTUXCw7wm9E687H5mZf mmZditbc2O6Ai/1y6ArEa2LJlAlnsyBHwHtWucP1ExXRpxFdbaj8PCo2rBt30uRysgmPdK3jwh7v 2FvcOMKjRhXL77Gq5QpmUOVcxdYHwx9PnDvEDINQBmCWQBnk085Xhl8aOlBtL6Txo4oMv0UF0Se+ XarFZdWEqi90v5CNtc7hoG/Sd9uhIapQg8IXRS/4q0RNkbBWGU30U81tTWLYF7Qq0vcsOrvEInuJ GMPP9sN5cEgtRPmrwb8LPuSz/l5N0XDTPTShlEcKgbPBndiAKSY9FBN+oLnvv0OfYS9+E5oLxaK6 CqnFnMhISrB6tSrunSig/YjtRWFOZ7Huw2fo5qKatQsgeLW6ENnt8ugtuiGmm7nx/h0yVPJ18vbX TLD43du73lHit7ezPL9A3KGfD89Z+flHchxnsUww/T0S/T31Yhgw1DUUP11CET/zFv6CYaBAdrdU 40P8hmKGoQqDlySlDYezqomuKjr07UvYF+R97yCbyeueh+6HroeCgDe/gz0XhsX/eoy4FgEq+bqK iRsWjSzaWv1VF8kuoGdU/hmJ9YB4DdYU5rSUK0pAJKnd+a900sR9nAbX/S+FtdODUbC2vnn4eWXL +o+MuzZ6HSRrJwIyzCQ/7ywkcUZcpCxdfjmMioQrKcR6Gcpw4HRawVcHFlzdyRd10wXc8N3vo+sf hU2A7hADbmBXU71lkHrfpxSIsppfoi4uidS5bbV6xlwwCMi7/7ygTD/tGdYVrHQKqjOZ81GoA/6E yN/nOzRPrWD86Q/sq1v/OO3Joi/4e0tgmCSHPPDICJoyVL56bgBWrC76ZQuI/XAujC0IlxAlgkeY j+eUXEvhMiNjfvSeefY6NHjbfrSEcYIB8WQYQqNgEnGBZDyfcmC8pMDcEz/9FXwb5zy7+cMpgp/r zjqnBVc18jDjLEPjvSPVXVMtEtOWLlI5Lihy8U6QY4t2h/1CZv1XSPxB8GYGg4KrtiqKnJXtpYwm 4kYI6Y+Wzys6VYOj4bM0mpLRrtmqXEaF3LyypcsRnetUIMkqVqr20wNAdaXguprTEt6kXcKBuo7G zFEuqopQWJZrxcx5nvQFjWBol5iQy0i1OBcL4ID+h1DT2GboDHCMT5+DIYUxbUE/KNku/BAb9PBr z3V6LhfbkNP2wvC+ayRa9MIqaj5Cg9RvGo7FYdet370XURmdonL5aFS5Ojxf2BTlihbsau/BOpCF 2P1pygDWrz3WTpk9+QmIgM/OG8mc0qHsguGZ/eFBLzkavrz2ZINRBy5oNj3qNbXoxzkOMyytAG89 eYgu8HsP++w4K44nHiK/yBedVSTCD06CsdQaP/rd+BUcLFlXRDl/UVt6X9zv5FLfQGg9SWQOcSpt OE8rQuBywjTJnKVsC5qkMWqMIqMcVpYIRWYw46xHmSZNxR5iczUZPjAex+FBnWWKNrlr+uXZeCsX B1JJyVffTYsF8Dc/Y1UvofDPF73BK39YHxBBzRve6mEBYTp0wHHlwNoA0hYrd2o+DF9F2zxUjgYO sqTE/OFfq7jOzev3WZvPHt/ixcplnN0gGEsTVPGFU1ZbqiaE+Mx1EAcjsSEFiwh6y6DDLSRNeLCs G1+avmEMK/1wQQH171hJP7F/xw9/+ayt95KVqPcR5itFL7oL67tENm0Yz1ZpCdKrZVHC02ek/KMg R0sGLZNrMnF8K8pqD/gJP1wz3qHMoccrS9tE3eJjLvRpy1ks+q+HQaDVrw++FGbfnA2wRkH1swSS xeEv1vrhsm/8FSJ/PyzLxFhg37o/Bzg9bQRCXZStneJnLwy6Jo/Us/caV1QwExmAceXHPGDI8bAB A+a2Cmgl25Q2XBDnmiWyxCAuOa94r9EvMEnr22D8jujq09YuGyGT+eYz+pBvZtO6TM2E1/SX7SgB MfDMDy6A6IkrqQl0uquK3fynBgHrWE20ZA6MZdlTuDZIuvnGcyIr/DDNlCLfDv5C2h31kem05dMr tu3jJ/z1gMi0zWmmOlMkveWlk1hmiHWqpUtfLmbYPQvu7muLruqrveW0FV/kQRcCtEkIa/QpoSln E4OigNTQgt34Mfnkhu+LLFEBvC6CEcbZB2/4emAH4QumMjEosHgqARN0lohqs0+CTUy/JF1tYGi+ zJ3iEVvYcsub2W/kQgP2v7K6+vgL9uX9C9EYrKmfKxNv3JJOUUHUofNFNyvAvTQhHkvzdBCQHOPK H5rHh+Hzvp6sifAlpRzdqxDnyNaqrvAW1bbrHEcr2UEwdmL3R/ozLusjUW6ud0jZHZXX6H3DnfUx tYBqJbpfPn3AzB9/ZTl35/HCqA2cFkYrf8SO8g/dw2Ed2ETUn/NghLTZ4GUG3NLDRwOAh7y1Br/t wVXKp4ag5FGiMA38aTpekd/RXy/eCcUvidIAt7Mbh4ueiLSVhkhqbj5PTEZcKNQn7nJGssCE8OZG AY12WeFMvlwW46NsKgH1gMc78A3vuQXfeYd5YCtK25CDA+W2IaOFU0/Yg9wP7zOR0yXd4R4Rcjld YTLx8vpiXqYDL6VCnPRdwo2lT0l4e0PX+/6ABjHniZWJcvuBAh+wdLd/OZNVk44of2OX/74E4ubc MTiCByOxXUVHJUY6EzKJbZ0jUFQ2Ap8+QYQgzpKYBae3ssV6TYzuyuPTk6skXXCFl6LRnp06Ml+e qAHr8iMXBn7jNv8XOriROVae8AfF4Z9FwoVYc/fAm++1JWy8INORJNFREq4MA/hwRwi810DiwvJZ gtEPJW3DKW62wl+nNBpxc4SGOQBFz3OnFrxKRQq/ST+Vk3vqPCr04e102g6L+2B54nry/4Kp+YKK 9iVvhwgudVYPUchkrk2Yw9ZDGK5xqvtdWRh1siHMKwwtquG7QymbBuNewHbArEnO0nphxmwHwrTL jncDL3/joCfa0neu907S42T3gFELfMvyjz814PEVH91s6eJaicOQatwNeYr2VhTczqo/a0uFdzdr WmIWlqx/zvNycxYteAcbYv84Oe00wJTk8xwqa299FIgAJQnioRjzP/4HdyUUbRq0Z8Wtx31QCDaX usVJqbqrL8O/eQqLQfRDWyMq90LRjTdetMtDEcLM+n8zAzEALPFyFgxUVa6Ea5FYZGUBcz02/y95 Q2ZD3fb/J3GGZqNQywRyeXkji3wQaRp+um2KLgklCKFLhPyftNH6P2kTFRXCwJthBnvjLIIuF+/0 ias3OLGHMHlwHSKYYrt0hmCAv6Z/IK3mx+HCONCiGeVQOVinippeSCBImRbtqgmo/Oh0yroQQVi5 UTbmAc97HdZKM1n2/9mw+U1U/eBLfhGXWqf7GEyLixlh+5M+0vAasXGkLeG6JojOfKjus3tv3XcN t6nv6j33ENUV7e2/Oi6EORaVgOQUgIQbkSrvgNpQX+hMetU3bYrFxudbz1xxKhaC+tbcpeFRF+Yi jaCmRB0rFOaMdsbHHMgIQMRPzmXxtGTgRXmyBzvB8BeqnKI2kQbKWsMEIXVEabYnu5uiBqSntQtS 3WLix6KxaxQxRj6i+8xRuBP030jyyvNOdw/nh2wm+M7tMpuhtsXaIjJJDoiDusVPOUEujTbpPtjV ktakHoLiDvG2Nnp6vJXN+eHKEVvRk2acXe9pGYkmtHempah8zMeWzRxEDXKULBq129Kq1g/oqz20 HIF3VwZqVE1Zm8NJrCTKFszI/upZP8wNikFuBDkZuijHB/ILkmUclDpdBPTDxgzDn45/T9sx5Tcu Rqa5aQPbOuUG1tHG7Hh0BQ7vaG4C+hQe+Ro22C6qd+i1LcNsVCqV9R6iXJP05BzIH0ikMfgxxlAp KnMoU6k+ZyHlgYb0+DPVqKna4JqwUJ0bLqSArSivseDznc0w6I1iiwDHom0Qnn8xyDPqz67B9Ras rwWtP/YKhmOcoiRolJ8NRRDR24Z1UeLQed+hn17WoXjVvvG7K8XQb/nJCo6Z5vCeqzsyna2UAikJ hhdNa3ZSIbSo+29RjeYh+3ANH3lRz5zz2zgeIvmlXrF1E4wFrneVPY2/muCMDdQo2FjSNCSoPTL6 Pmvo3X+xQ1zCW4i1EgF9WzW//gm80AYh2J6Tgx7j3HFdWDMawQlk3pZHv1pWpO4KbxGeIqCB77Pk aoaQOORIHlMLU1ftEiVcPrqT5X7kVdpnblK22E7AWzumVtvJpTxJDTsb/9UUfZ0VJ/AddPrxk2VN ZBF3dAY8iJ4x8PzDc4Eba5bUYAAH9+h67m7cRSFtspuF2L2pNMtWZoIOQgyPuS6mER0HCfcgUfI1 dwPABC8uHke5uRJ4GNCA3CQQKSRnSzKqm1fKEaf0UDauQemn4+w1HjCH6evO8hxI+XQEW6Mflbc3 C0zKu0V83hVMcehDfAmg9ubMEvPZuVBdqFZ8bUebGb2NaNo3ONiSY5qkrcvRWJw4OmBAcrqtlSrn 9iXNzduwErb5LuEK+QmL1WdRPOWH4GKTY3P2i9gPsJ5pzBNh4XEMEJxKmiU1AzvOpt7me0RoteJ2 7H2Ywgap/H7YYUJgZYuND4N8rEVDkUaY60Bi+thL+evdJNqb9ZXdflOhzKw/ptN56ftZWEWz9lOk c+0vBR/efNkowBYUe2zFPfCbmE4msx0wirBtX3q/AODyKHdq5ybuPpemFx5ReKAqU4LSgDP+B4Ow YdZYvAZABfS4nijoVGSrn64rHcfxDo+r8XdAfYvYlUvYtPBD8FhumHPwowJcrVCYT6jFGFVngxk8 0dD6gEadYCnR6dpH/CCWxx9JmqoX6MNVU08d5NwyhR6FOQD5sgxzvgJKvpylm5UsFWAW7CZsvbPY 7cTkhc2+CnkIwFPFb/hgqlT8M337GhGmgJKFPp6Zk4/Gxnhz+G3paM7ff4aaA/M3NulAg616vYTN 7qjnsqmA5fOuuj0zvJxT+XzPA8AUxiX74c+cxsPP7csZuE6HP6JH26PaKq536q8AUsOdDA8yDz7z Wrx1tY7dHWHWaqZo+L69JNQPg78H+qMPM4yNKfheamw9xsn05IGMZGlNhBsamRnKVlI0lCHCwJo2 9lPfiTdVa7NuzTj9Usp0lzTalccumOoXYv8UxQBtMZBAaQYPUd5BUZOlYRPjo+X76gH/9pmf9vGW uP5wHnJpjRuajWJooRrZbiMEE26oKXamaq6AFS2g3nSCvIx7ha2rn/mZtuiRhLgMC4Ef4bqcbY5Z 3ahcPC8yhAYle8YoB2fKonje33jLcxK9J7/vjACuGbQw3weJS6s6eH18ny0Tgzrt3tBdUwYA7Pxi HY37XErsn1BchEDCEpkXQ5xCkGCrI5YIS2g2RjpqktE4id6e04nyuVGge5gjtktXvT+QoftHvU8M 3+snzJwybgcfwtP1qZaASUJWxtNX+BABXuSZ5T9KEOKVpW+f8fH2UTm23O4Dtbx98aLxHt7hW5MJ 7DPumxS3IHoGU4AQwegu9YM9yS0Gso7SSYHfMzeH6ZaTzsRfV+Mn84DlXSErSy2axDnUmJvEP5Gv HUp1DHmSoxex4yzKpZYbt5dQhs8x40qR/beBHe8dAFLCwcwcm4Ow2uFDdKtbmgDoVfRd0/TAViYL UcByQ4UORvjGyHnWAYef4kWTj+yi5XRMvaNg+o4z9fVdYaGxjXp7r2OJMq7Q3XXXXJ9zu1G+12j0 ImM/tDgV+OlBr60BeAHHW1BsBsfpZb3P6XVo+8c2KrB/6pTJhWKDwdl4wk+aV1lEWnDm20BjfKfH tJxwvVeaSgjzfrf9bO4l9duAH1Yuyc2Bh4lG3/ZOc+EdIlixgSBopo8UMQ9u++uAzSQFz84DZpyl RLk4mkwZmctvPxuCSvKK+4HjyPz7Uc9PWym3uDU4KfWFZrhr2V/ykuu/BlJbCu8we6PxeuxYIhSI lri0q6pDuHEX5IDRcaWFl1Jl7C4VAhQaaK92zedWg83AlIJG14/GmNOoW7HdY99WQZP9r3q2OeH5 QoHwOxgQ54/N5HvFvbo7b1e3Bb5IeZWhpIU6HwrmB1rtbe93sN+fzsU+2Q/Q1XNc0PNiFU6ERSYp RvTCOE7T1bhHqOCcOJmxFiV7XsexiG8bgXp5RvIXcvGKRkqKBGoZf/vMsiUvFbl6UzRhEV41YPUF nP5muiJ76ezLBjMg9mK3wjlMVR2Pm+7E38v+kRD61mMT3g74w9IAz4s59ln7+gndCy44+Ip+mKPP MKkdTWhIFK7csGEbmCojiL4bX6uRtjQgK70a/9yXGnhT1CN7MqT7ue9mwteLEQw7SbHSLamxzwR2 158ppBXJxWoOnvqG0ienGwALIdJFEkR9cyWT2DYuehGjdomAI0Xztvi1HdGExo8fiDVpOqigq45d g2v5UVgtCfm++FJaOF6V8oXzvVrcazVQxy6IrRlQCHf09dodPWfEtFcyfaCm29RbDF6CJuqrkbY9 P+cpjsWD9Jj7lirI0u7uG4cS0ar2bpLH5IAkEP0wBfuwueBAUnr7+urJMU4DhvBw7+snU55H1F2R MOhRX8tKUxjPXeAcpTsr4zr5799ofPXJLnhJjOlJUk+55PeOoh7nZDZRjay/WL4RX7Fcoft+fPJp aLX4hZWe5PehHgiRzYyPvLjMby2J8zn4sCayEtrFtTI+v1bbZ7B8ZeTapf9Zr27yyyQMrNZc4TMA oNlmliUhXdUz8PXjpCYlB3wcYelF6vaXs/z0bKqC5fGx5N7l6j+aYQyFyJWCN6kHQ/t2tTdawlqq ONp+5zM3Bqxzxe6V3wJN9GUFxjX0wd5nS8JyPTrx3jyOAIZeBg5boJDFApUrwyMnL5ohojXqtCxp 2RZRtrD9F3+Eje/CDEG5a5+Cvwt7e0atIZC0hsEu6OyMxc2GcyzgX20IScCXVyvsXGa18hWLCgsV v0YHdkgFn6byZYaMPNHiqPn9/tVr2m/Cdo83+YwXFxaa/9hbSGoOoyW2qHqnCUir4q9yrkokqOFY 4L0r9FcUqj2sgDvBORj76rDIifPSqta3M25i9XM58yUIPiA4Wkv1pfv0V2JYwV4q3LkX+730n22U +s5wh9f+vhYgE6NLPY8WIgTnFP3FsKaNeOKE9d56dBt/urgQ2ktkcbT3LMpfpSx/nVGf9/Z0mc5J aSkjNc53B55yZk2ryK7grgqX1+heFOUSt6qKto+522C669Kv+blA0GLspC6wSHvSwF+nXN10ktJh rSAp0mF8DBoHnc62tdfF9Ax4eYGN6hyKL1dPT9PXft/dgaTrqosvPYyINwe9lDyb3M+8YqF2aWlb 439VCIY6Um1uf1XTf1Vf04xxWvJbutJmjQxNEi8OOxgg5MuLs4m/6qIvGueqSwLOVRxqwCN/dcH9 Xlpgjbpqp09Jp9kgG23/qbddjCdGyodKuTcVktWZSR1ptIh8vs/+h6qgrIEiG+G2vZq4YAzI0QSQ VUa8lwgVeqMFSrYokkn4SsKH4b9/CqTc3klOLZJRjiThI/bfX/87jyR5IknMRRK6kQAlnwEpRaJI +Aj998tDdpP97Iv8lWohKkLuLODRJyAlnnjiC5H/fsbf0fVoKZCyN0rg0B2UxVhkUxeV/xRPfBsA KhARfzNEgboLgSfigZR8oTKOxX2UjbI7yZlYvlRlQ5TsPFeykx9Iov1CZcxnf1M26u4k626EDFCu Lxp7qQZZCaXUBqv1rt+wCuOS+lKlo/tSHSKQRB8gCWJOEP6dq/zt/8q1ya5ka0z/Whb99dD/15PU IGVj8d+eB44kGgfFW7HGdydLN/o3oDHlp4V5dGiIean42/dPUA0asIJUlh0TPVhhFch6IN77HQ2q Tn41EbJOaeMhpE4Plj0AUmqJJ2qiCqkzg2W9BNUpwbJTQMoW8cSFT0IpRP5UcIkLSELqPGDZbiDl nUQiJ6LQHHoiJ7LQHC9YNhVIqTRAPM8EVvTwVowFApglZpqRheb5r+ICVVpXpohBegG0V4t0ASjf VjvFiqt+pNT2qmvZLE5suwCC1nXxHvTeRGWn7tHES/W2ipKyz0lbNQX2hdEqV1/xVCkerGSnDgWa GCr0q5KNEhOqvp64NEF47xqyD0nHiI9tL2RNDhI8mXx+7LVT5o0SH59uJPc8eVCJrKu3Da7pbyWS c62LoCxO3wQjV76NF6e24+aNt4A866S2D/X/prDU9pG+J81yMak7M3+Gw+yTYSzLvj7Yo06K+56y haLFEUajP7l8/iDvZiPW6SC9nEXrN2+nfarm9ZttU7bLaazWCXHL9sVetTfCc3Jx8g/ZFtlu2VjZ 51Hfyg1MYdVP24+7NI4Tpa1vcnykBid+FSrulSoelUHtCzaq6sSQ6eCiPA3co1lvMp0TUxYvRPl1 vX2tyLwBMLqCNa/5kKGl8FusotrTua9NfpOEHSPfzBOFznxG+0Ky4Ykty50WixdTBn++Qt5oaU8U hzcUZV3IRFnL7Qy66jebYHU5My0esGlFbezpbWAICkxdv7TkvawAzGdZLds23manzbhrV/napDXJ H3gs8bpUvEwbTOv/vclddtncOVTN9svb/9Je0H8acKEKHuOucdXWzXOo7fLe8tlqu8sycrL5tI1M ts3D6OACEGpx7Ar8+gOwnVUvz4eSC1fVvNiol7bb9mJwY/BaHPLdKK1X+meLwba5l3GofYHCZraC 12ipczhH4LIbe0BCheiMCcgrmSQj6RVnbCJFLtckl3ESuMXaRdtVmZD7sdl6jd94QkPb5HlyQB5E 2qWu7+03yLiXlhacvGXfPr0k1xFTV+RwzN8Rml9MOq9xxylkNLPQBCYSUplZRrnDhGYb1+mcaPnH B2vUL18eK0FguzVCfojMPt+ZBUmSLtPe+Wgv6wUpmwB7MxnKouyc9bOXymrtbJzZ27LXJ8/Lqo/t Ljigk2SAyTjOkildQJ+gKQl76lTJodtthN+coJV1ps3k9pQjYFnQxpjtjY11nPD9bZWetTGPS6bX odNt/qpta+a5dduqw30W9LDwaSPQqoe7fArfY8mQLWNSy2NKI/90SHB74hIHjBww1IVpbFffpTNb faZ1VxXA1b1mHKOzXH3JdZ/tz9y9ZGxw6ezyhWeQMOfKun8t4q5nLyC4q2CZFYR3p/BYCnUPpu6N MZmq36V9vnuRDgb0phWctD0IQHweN1+Mg0l7e0VWSC8SrwA1iRnHmel/iuNYKFXsPK0OQCcdHUaR 2R1lRufYecVxdfWnjCoqS6lamiJVpFrs0F/BhkPHtGAsBmORygJNJP+o/KJAaFyw9MFs0znkYNHj zjBNpbfQRPXpLhYipSXa+8NEHe6uGqKlJcs6P6Fp1i1eryoFPoV4aWnWL1UvKkFQoVEMw5fkuMuX Jz5aSNCeYJO0BYM77bQKHxBx1fdX1ZAK+dPEu5GquFfFkLIUMHmQbNqiyQmrFl+QIqnGwR0PhLCT p3dxuyoGggANr/oRsiBSNQ6hhaZWFc+c3lZVveq91VStCqlKabU9F0ZVmWVnWVeV2ZnpV+iXpdmV 2udwl8XLc1fSaJVm5kxNVSXYuaxVd5SFHxeeZE2XNVW5zClm25v6Z5JUFR07+VdLl9UfVxNMPCxW 0FhX4FdlZ2Pcn81NxnGUaHqk2nFooQC24nSYpyQBai0caDlftRwAY4rqTpPYAKkWrsSsEc2qLPuy Km/r7KwyZ+75KU+vWL81wdq1nCzrso7FSY4mTYTbGj/tTevDTL6qkiybw0rlGyOBqqYsl8Pq9an3 TaKbZrjZkVWxeo641ZxPziSLi5ZZTItTNZyMWj5PysSLAzVcDloqTVs1Ot1nW5uFF5w5U9ZeGavW rZXC1hmrpRfcAZMki8uB9sJa0EmbQ8DiNhEbwsK7ziYRHdgpNQ9NVA7aSSSulVyO8gX02+4nY1Qu kWzSRTaPrVydgSkpD7XSHMbDGAKzV7aQimSakf2KjyoB+pt7Ut0VBAfUvkj2zRkzE+XDvnBd70+M 65N0ZK38efx4KhuN3ep/ERyl3chX9voddLnbd+n0VRfSjPqwVj53MRjjePXqTFWX0fhzdRGcwNSn 6ygIgagDxk7I6xN0ZITOFm9PKmW6pI0pucYc/nCppXbjGqNwDTkctKgn+jt1cZ+w1ycuywhd3D1A qiu3TF0a/PsnwByLzRE8mFuqKjRdaVfp2flX3v3rJ/TbW5KL8z3X8dm7I09u9mUFIzMl+dcoj3AL TL3fTCShm6wXeDozkNIXdftWkyXW6sNHHGiMfZ3Jan3N4ZMWtOqEr7fDxEjocvneoRrvpSPYiGvb BcSj+XaVA1FafN9buq3eDWq7W6+KfGV+ZbZPDskJydE/277YrjO+6YQYLWL2lm9rdJ9tH2yXGl8/ P0EXql/JQpL8p0gP0TQUoJ4iRlZPlNBk+6z4l8uFz0bKOvNjHfk9PwqWZk6O7t536/YWN4H1oQlb FW2gc/+2reqH43AICjTtVb9gyWZfIEJRK2hMk2vxTqMs9di8I0dgatP6C7753JTQofEtj0ev32iX Y3o2jnWL30SXQ1WO0iFs03ygpfAswvldA595Qk7qoUCq03SWyaTVbWf7Ll/+0VCA3x3+/Bhj1YRf tHHUsmjGHcQvvMsM6fKxjvQ2SKTXZIX1kBYiFwzXm24y4rLDc23w6PSSA/0UbCMydbn7cP8MgYUW vdIJTMxacktZxybNE7ln05S377NILN2M6qjdaMUF4sj0xNCaUCdlBN6ok9yoG9+oC9+oB9+ow9yo i92ok9+om92oY9yoq93MKe2Xmu+X/tkvxdwvTbH8IcmhTs+hbsehjv9TCXO1jGm1jGi1THC17P1q GcVq2V8Jx2oZ8moZw2oZwWoZ/2oZ/GoZjV8hrl8htx9ZlmCSOEmFBHyFAnyFDLytKLytLLytJLyt IrytOLytPLytNLytMrytGLytHLytFLytErytBLytArwsNWwzJeyGIvyvyI/A/I+ujPiFsPg73Byi MhyitByiNhy/z1v56UouyNI70XvtBh11zFsJ2dfzEM/FIu6pxAMwinwwi7qjgZ3fgMKSoE1JWxOK ZtLrlQJfIlHBT1QkCBiJ4dEj5IN7qn/cPl/z5voq0pLIoCdSRo98/HNN8scNm5137WK6yb6Gpbr6 ZK2jrqeiYC5keeY4BCQFserW/Jt7S4Rg685eb5AQRCNINKQu8QQL8v3V2Dsuvi+WG7569fOZ7QXb piLr/AiYJ3zKNdVsONPtUPi2UM/cGDAxxXBbNnV+mWl/GNS0eMZGmp14BxMgZNnDOTLJc2hwG/40 9uIYzNWbdWo8CDDOzZAJceH3l3IEp4Gl/VEVeRTu7uD9JaZ4kE4dG3HvsF4Cg8nfaP4W/GHWy2Ww xgsk2KK3fXvN5Wj7xOem83ETKgDthMK8or+RCCxPvpFGv53LfhdwN/rTSHKtW+DrKCvITUFCiJWo 9G2kbNAC8KeR73olzNdRTrCVgsQAK9Hp20jroAXD9UqCb1eWb1ekr6OK4Ja8oDcZiQsliQBmYt63 kenBvfPBPeJBC7w/7PGd9jrFPwnVVvMqzsQ07/eV12JXulJXzpQct6Qc78m5L2m4nzFzoN+mXgcP 35l7kDXyfVshUnT8RM79FTNn4NvU7qA1fyNf2AqRnKM1es4Dek7Jt6nZwcPP5rfG5oD5/AKhV1z3 kBbJWs3TRdy7ZP6KhGrACZ5X/BFZbpAmV0CYfWH2scm5c35xvW6g4pu1W/brwB9Fl2x3RY9L4Vjm 7mhcgwA0fcfnkFlXfFSd2SsBgrqiXTnOjcQoBOAVOsGZ3mSALlUhyVgpzYF6qkclfftCSfuCRfvC Xoj6DV6hxAnFd6Hu9bjbFvXDjvYiohzCs8qFQ4QA20Y+CuMhR0e0AwMulKqdzj3Do4CAEwN6FXIi P6zZUBuZNE2h/A/7KisOlJv2C6sh6sb4+ayBjiEdtjPuI0kT1aSNfn2tcDp5U35qyp9jmsQH7wWv j/zUiOVHM5IeRLpykhoPzjX4tAYgbVqPVOZotEfd7SrYyhMP9uJBOQpBD7QHSujHbzdUJF0BsVdL U0fQFK90D7EMz6/tA5uewYfdimR6N2oBzB910gLJ/OTHkIwNWyrPy43HsKL5Y8u/EznrhefJUlGT 800DFm/tyyPUxmC7Hk+MB+MV7UCSG0NGqZ1Uy48otG5yx3LRVfhvzjqwi7oBDmOqEgu8zyEoTxmG 96zjG/2Jvb020HUojaLD0/Tsz9X1no5fXbPQZTwV+jUqvxgDNr+Y22fzc0ki2oK1qnz7JUf90Bl9 QxLPe8nqfcH2dGlDh/nM7ydjWkKbm0p0mnXnIPYHmzI0QmGWyvHCKjn6eEIexZPvwnQe4JVZiRHq FuI8vjJt+eP9QdFfo70u+Hl8poYQkBq9VeqEbCeL5lnBuV2JTKKCPbTNbUDGpiyxU6QdrORHwKOo LCen7Jzp+HYapJHPP0bvdVIWIfLKqstJrX5R7xz9ubRc8oZ+ItGnTJLCPuv2dYl9mwta6jHGEJvf We/ifp9iBWC47/S3cB7J2O65/pPyAxfNW+8mkXoGXA+4aeIOvxRpc3/5upnwcrMXVhk9w+TvCDIQ kFYm0n11rbQeuZXKFwK4PB9mSxzNkBofRwYp2TveL99VNd8dXu4ZcGbrWOilDevZuAQ1T1WO3Dhl FswG/R6nR+tZ6D2MSBDpavB2nX/yoSobZMA2bj577tVhvTe6PULAudie+KinWWW2hqWTnl+wd8bk Z+rx4O0ixGfnkdq0eehp7BV0PBgw7GVs5HjZ9YvBSmtGDzpP6Pyr1rRZLzG389XXyjbwrAWaGgAW 7O2x2y5Opf0lw+Kiz2V3Ec9FKuLuaxc9KTwlvOZLfu/evt/WNSISyGgnXjSiwrvm/JJBa0OtEszl d4N5OqWO4XPzsj82ozQestzDfjQPwEu/vHHd5RGYmly9VT98e4EoPeEFGE4QTAulNlgNDx3FLL4d 58lGstJg/1opD8mTQsG6b2YLKbif/KrUw/g8EZnf5FBjEDhxEXpUH9TTZje/NUHgqdCrtpufTnph FLwh6MtkJX0r9TQSt+JasnM+NNdmuL58rxm6JddmgxZoenfzp7Oap0bXYz4pA1m5PtMFOKHTQf2q fT8wIMVSVku02KoMhnzPqQsWYKJUyZi4fMttPYVettGaKMhH52jbOy9i5n1KczeG+s0t+58bZWzx tnYetZO3XciftgbX1qmz2SztojTakAQftRMzEizxCl17LkVo7OFVB1HqO29um0KWa1GsF0nV3Adn IdtEip4qNi0ePg9167aa5YOCsNsJJjfgUIlN/a0XN/OH5WEi5pX96NUQg2bPN/McHAityixxeA26 iYNUaP3F6PHtn3zmkMPv6m8GY7+Hg0r470VyYE5WLJPUR15132YsXUXwFxiukfk2O8uw5VnIRAaR hx6I2Lx9IRVme2dsT6m3yAB9umxuyyuhEhnU1/mGx7fJhpsxK9gB+ZeWoKukH3XHA9J6tXI+zU5Q 1qb+9QcRz8eLtjWu6ao2joNRF5zTN4MWaxK0u7XXa3brMwtWKgH8n4E2NRZTHClnVL2qn9d1v+I7 UA6TFO+PpTAzyFFEyP74aUmLvJoYHsEUTTXjevJD+cjr9RGab1J/VB9QF5DzLPDg1V3/7DHzkBkC pTHRxloLaDSwOZR6weIJ0nhe5LzCCtcZ2SiNXCQ65Y9gOPZilAj8OtvShoUfXxBNZDydFYV07eWA GNKscrovvv2rZiRjyZiG+VFSJQXE1ZCow0cyFEdQh2PgpZ7+Q9Q5BHex2287j4LfoqkDGwuz1SxP IuabIp1enfz0qWaXHdEYOYET78eaUE0dQh5NucTiw021J/WfDgfqQ5599xnvcznUrxsq/hyUM76g xemymupTwyfZ1kUSdDOOD1vnEivThLbFFucwL/wciLMQLHrYJynAqePyUlcCOAoEKg8D/tBp+Whn GGOvAJA9u4X9F85QcITf/0B7t/4JW5Ls4ztiHFS+IrGihe/f34grTNf0KAnhhrg/IKumoHyxKQ/D +EnavzU8v4vQr4fDiirMpcgzmz4+P9wFC/LJziJDd/8sdY6UZzScy9wVoHwJdB+RkBCvK6UT22hj sq9WFeF7Z8n2HJhwy3WPb8HiBlez+CjY4bRZU0veudR/SizdKUrY7FrK131pihPEjcf0dEDmkqx7 9edF6SVvEEMzzL7qVEIqMT/TvKh2djWY6bw0c21mr5BgNQ1tENVamx6Uu5I2ke3seik/NMhurxsb rxDgVBGVM1+bPZ79YfVo4vvkYOGDkEV2iY1IYuL2Uxf3GgLjwB2tEoEW3SEmtUnFp7G5dcYvTXJ1 4kfLNezR1OX2qqxOeyqSREl+9bnZWMNJATR1isU3a/FL/WKvMfxfGFMKiGlegZ5aFmecbFkfRqRF hpVq9vG8I+whj+wp+FiS1nFQvOEVtegUbxVZzoA9RPnDSda4E+IduhS5cEmKpJ/u7gK/YUZH0H7S N1m8/3H1Nrpm2pkg4W30LTS58Xj54nvIPJR0VeNUIzgYYuptiVU0vpStbsxlwchMZ6Qo00AlsuYY LCZTOYYsH3KjfeBha1Df86ZmaLmqeVpx67mFKwb+6XE/oSvvVHgtoeAVi4kWH9mKgYDqWJI7cdB6 1acEGhtdtYlaeI/85EGMOYeTff4e+PK6HbBLm/MrnH9wv3K9Sbl5kQlpehOz4xOWw8qZv7s8aska lVvcq6Ppfmem1KV+rUaqn1VDGlYOhQXWS/f8cXmqy6hsv4Sye4Grlag9K397QLfGpO4HvFITQuVS a2vN3UHlDwQnDYlC3y5v7kZ/wY4nLQS6qHvZc70jFmaUEjS0mJ+2QmCVXyoOOKxqDyL1e+jI3Bl9 zdpiPdNDkL0Mmc53UWNaiMdbrt/MxXwETeW01udY7B1PrWye75mtRfu7k2l8vXAPl0HsRzpDg/qt OFx67oRXvB9/xyBDLsMiPxwp+pteTsEicKNUsOeiCHt4QoLgKGqzMm34yZfv0RzR144Z8HNPLrn6 3WY9I1WBguY7atHratQvJVQ9iqDLy7cmJOKg+0nJR/JC7+MS6qXoSq+CwQBBuYDjPvSSjYpYNMzj pExV3hz6HCPGhWtbcJoXWSxhDpII3GHoDEL22LAp1jX0Cm9zXmdIgM9MyHErY3BLf8EZLBIuhycg 7/+5cIgpkCJuIcDQj/MM5X0t1hbX00hr2K56lhL+13KSb/OfepWyMpE7XLP5hs/WGmqTQ6razpkZ F0q3xLWFQWdYnmIu4WPhf6qWC0YxvdKSeJo3h1MpP5S+KmnWkR9QLJ+zGcxmTX0b6NpMWoqYZluZ MIDXlwkMkI6C4lnUbmYWE2NOVDNWo+RNwQHb7gzLplRGGg0EELq6bZXGAqNpNDJFrKyxB8MYV+ju +rS28mxHt9Bo5mlTFQtG68F80rlvEsNQfkimhRDR9QcBtA1jyCgsXYTgl6RUiQsSH/ROGswVdpi5 qb/pLQmTLAIaOK2MHGrnhVw55BQ9zVpHySOKGqipK6tpi6kraMhcO8jIc2/1+iECZEhFmIavSWHu yghi7EgQuwiLar1Lzo67gtOv6MYTM1pJK23wgR6+O/B3Q0N2i1NrEoNdU5U7HqPTMIu83/tvIIxW q1DWlH5uq+0OSQiRLFH1HGl1jGFyEazI9N3AxPE6k1bCKdytJjXCR6db6Yv5hesLRAyhsTVi5x8b T26WzM7GxJyrPOZtfW67j14p4wFnyTx7R6cV8VVINjb4ZQk99J4mJx40szWXISST2uEFhYtvtr18 BeHyOhDBkTnHEQeXp5hpwS6Vp8fraKyWuVYEzJRC/XBuDzNPcfpmPtUIiw0rCWPU0I0fsQa2Ts0Z G0LN4hitv90ktE9JZMI57HP5gp9EwT/a2QvcaYptWQt7GkG5MwL0XiiN7MloLFrYBQmJBae5ms8J QsaAqBN6NEuURBlq4UlfDxk9ierG05AhkvckXxufRcxmlrMQRWBZph4kS6ve8AsbxMyaPz53yvB7 TSssek3AJ4tL7hL8Yex+LxdHL2UzqRzrNCnCvdyJ8xJaG5sfNGDKZ0866sGRi5AwnSFK/rV7DkeZ GTGLJlvDWHVmxlXVMNXFerlKVV3BKVTomqZPJ/cGA2uJO5qwrGxvySOD1drc7m7Gx+f5eKLfcCR6 7elrbf+UBLDfkELFwis/WtE90nxoZZmXYBtJPslTmdR489cqqJ5mv8VtnpyDfJlEm2wswOGkWH/U W66//HubgkHSn3sL4nJEH+G6hmu3Ev6b8WfSunRWTjxmgyvnKiauh1gHkZoJVTTvP46sByNAIZHi k2/7FOnalcLCPxzoRtMO8dEEjTvAQoWZRsfzcSdiFJFMErbCE2RHG6Tsdw6DK3j8MD9/Igt4iidP mZANv76fDvkz5QA3M/XHWknIZfrwkxFXEyQx8mwRc5RAm3L+8MqPKyvU4huV7xD1V3bhvW8nUXub 5MA7qW0ZN6U2yIW5mzJMsTIAJy02GW0Nz9ml0bj8jVSM/XiaEhYX3bn3meQTif+hxIACpdfqrlJR CTnENHL/4U6PE7eLRWYd4QRaUxrOKEl2gKtdh8C+XiSZFin87RvMeIGo07wplEFerL8t8hqVNSYd 9MA3vwmwPavVN5dP59nDd6NUDjCw1Fb5tWsm5oDnufHN80OT2/EwFBZvA0+y7mdtG0dvnKUh6u3A BM8rI13bVPoJczOVfJm70CqDOGU/B8dqU4SKeNsUo4TDpBfNvmrYOmkXUsmX1BCM3QIZUEgkkUVZ MdSdvCPRXMYi9B54W+66D/F4J/C5/7cCAgfsU9iZmD5Z/GXpmonnlsq7NMffYbZkBMsNVIZNJWWm cSNFrEx/KV20K0pZ16KxTkY4UstguGUCyfxh/N7eyXO536a5BcDYuS/uy/comcRZyPJhfSBD1j4G S9cYmvpLEjO++V5sME3D5+UtzC+x56qKGNNuKQeuu+Ot4kELcW41e3I0CqddJPm64wgLqNFvq7py FwWDuUr61FiJg+kGuNPl2qOn2EXbyproDMcqBrfcP2TmSV0r5puQSCZzr3z4QyzOrpnEOHFsynzc xM++uL4DM4LanSwm33/AUUErYXDo8ItYzSeaMlxKFCOQDfJpsYlxtKqSMt66qgXuSMY6F5ulBtl4 zJbxmodH7eRhlgVHXyJCLGYsieGDhuq7HyCTirme+YTtiy4P2fB3zwXPqOWiqhriPibC69dhrDly CtGmKwFTysZTPLEkfYhnTpsIiEGEiGJJQY506OVg9yElQPaPZdIJj3MKE/cinJ0GG0TY/vdsMxho keGTYrpJCKMYEQjX4R/HSkXaOeH8kk/PRPP3Z7I7Hx4+LX+KRH5z8qf+8KcrN+jMlSX0RWQHFVMa xn1+nYHOFY0Mu89CiJenJaw4/HTb8X5phY6eaJF+qGLH/fiXgSSSF/SukeFqyTY1jYigEdYZ2UnH iAtWGb2craAVrXRpzZBrl5eeas1hjKOZ5jrgUWZgXLA9yXhap3eWvJHlRbp4fvGQ30aCZJbfpcYh fVzIs7y5O9wveHznh/WG0uLDQ4VLXU6MjaBCA6TZkPucoI6HZBkHm62UMwW/iZswjf+JgavhSW3d sFT6JVxyfeZe/Tg9WivIF/Vu+zuX0OHMD28+QvKg8Ki6jLnWhphKol8OAzG+lbsHOnpF/i4homnj ju+W/5AVS+8snND41B+YVxFQB8Bd9VkdThoRKv62Sg73X+7/HSj6OfN5nUSNvP/3x32G7DcfPCg7 ZRAtW0XvL9sE1N/ty1jHvVBGSbHXaRGDQkQa9yqpZBXojewPJr7lfEgspb1rNuLGcl6Lv49k0MoD FpbPGIrSJNrkmluy60sOP5pbfgDJB3PIJnNKHPJ2f6G+ZF6Sb58w7EQ558NtzHeTBiVak/YVD/dW H4gXEdOe78GvJuoHGelTM/MBz3xZ52thwtTytxi+n1wL61wmvuEuiL2aecWYHyzoCYLZm9k29Wt1 a/IHedw/mej3B3M55Li/aKSMXdnxcLL6GgANxDO8WJo5PaBTNRs1p7WUWCtKj6r34taODsunDje5 iM4JHDK5T5dCdkXxfaGu9DRfqMjn1ZPPRvlXRCLjnSz2jipEK9y8VUkJ5Y/GjFTEl+9ahKR3GAku UWJXtSp9CXt7QzAVTD7rBsr2rA11CL09sKUnhx5pl9d/QvBhJ5DuaHCN/PKKmk8nnYGKbOVs6eHp bmXm9I+hi7k9KjIPBxkb2T9GBmScBmQAAMCIjIydh8eAjIuNzYjMiOx/LAX8eymAHfAfKs5/qgQF WaXtHD2t3FmlHc08rSStLFwsrVgVrZxtPG3JANxc3Fz/PWEnY+djA7CxCQujIv8TlG/uWR5KoObQ 00MB39GZ832KZaojC9VvZ0RTKlG2UNdFpv3375HflyGF7bfmfPtAIVnFjfRdvxqDWTt2meLcZFa9 SkH0I3YaQ8u3CtFuMq1Y+WR9Vs1ZCrh76NSZs6wtnfn6zHOR8HbqEc/MZFYWoM3j/uO+eNi3FDL4 NDzlbt+zDQQ8IurzoVpJu4c4ZiYG4e93DxlygC2KuW4LWpXstcc8qwnZ2BNlsOz1SmVGIn7I0WWI 8treouRmfS6v08mv5lB2akkhbUypDOXs7LwmHzBOi+Qfsjp1Y3VfueN+nhzXnm0Mivmeqo4Y/+Q6 PdmuQMC0So3+yk67FfSGj+q+J+ZU6unU4WRrOqQL8wiDR6WiUldVZcxSKsCbrLfJevrutbOL9Zzs mnvNhqimtq7zIpSyOd8WSIIpgrIAYah6qziIG7o7IgsxZsY0V1DyIXtF/9PtcEpQd/sdBEPhRAQx cG9xeTXMlsShSljeCxzP9dPC2TykIqW5Jhmm9PIyGvK6c8vIVOtdibrNb8fx6nlAMISw3ZRA07fu bnE5P0zYIq21SefXF1xWhzzsbEVTGd8W9jrIJbTQew/7yfDUZOIInKDIx1KMWRhwe2XsXnLf0UFG drCGPqlosheDaCNF2+nciuNGd99Gdkp4eAWryhICZcokVUpu+6043VMyWEbotszyC9U9od6NcYrY Vh0z32MZniPEg6iZZ5ekk615CDvG2Dj3jAg+b4gf6BROPv3codYQIlk4KEo7zLcdGKUjJ7lGxABb mk/aZHuP5adg4DintPI6Js4FCyUezvOFtZNuQrer1jMlKHvl+M6FOp5ENnGjzD7/r3b4xjM7H/Hn NAO05OV+RAB5I1Qy/6eWrw395nfPuJhMcRi2lFofliU144I0d0XemSqCFEKiRvPc5xhUkhJdd/E8 bIT4El9bQWpRLDqMk2IqWwpqidTvNBryV6TfxSv7Slay5ZRKOW0J7r54l+cDSeQDUhBOyjwrECA4 pRqstqwnqFOFwsCtBby1r9MoJEU935GEVOxo7lBe86bLmWxFTtCmimGAr5xsj9SoqvxJ8GJNx+9B ZOOhxqLtQCKCj1OlgiBTEB5nRJT4re1nz4o5M04O38yoeToQYgc6v/oxXQeiP/mBBCuFy5XHePls 38yoAhxwVn5Elbz5S0xRJCeu/o/mzGGxkTlfEG82+guhkSJW+FdbQaP3eYWeFEbI3RE0YqylE4Wp tsieHEqRxtLzYQVz2KUalR/443tguw3tkNLgRIougZ629EYYL5njtvCe/FMRxmI64jaiIsVZnCj+ 1FriNvTM5Qy2cFoIb/Jp8tWjaLVlBBWJdWGQIlJ11KmopTkikJa8jQYx2D6b8AVlSk1fZln0aC4Q JKj/rvYryQ+HChj+AlxxPKBPEaqnEFi/g/wRhlkTYgQhAfPbhxmrTAEJCxFAAc2Ia7LbX7lnMW0B 0Hcd35w/vmbhMkKFoegdEc5hr1+cQ7cQN1VEfuCClDwZwTLyLmXrhW3A876HSqnj2uaPHd8vvmxJ +8Bvl6ynvWZehLGUFIhfqkKwOgj9aTcJAzMu1CEaHWgduRdft5TQPjzMCoEBoO7m9/6ktRFb9WAY CB/YBhzSJzKLXIo2JwFMA7OBj8CI4L+YQW+gDOBXWy6wWWk1SAcoY6t05eT/PRgVSi30yUgpdMcA zFjqYMsMXm7+BPlc+1W4jlOUsNDheGyHtFLrmH8N0Uglp1CFblO0F+milNYO0ByfH+qs2RHdKhoi 0YvaI5eTJiw1I1ZQtg33AASABT1RoCQQgzX4oHTjL8Iy60UGx1KgS1uZK1R/4+PL44Od0+Z4b3ET 1Y48bzGTH5tAYjACSAHMALbyJ4Ygd2MExnszbEoFFHYeK4FIbVnBWhCLKy3/+K2oHuVL0e0vr3/v ncKgHDCLZ/2cyFxA3yYYtxstKOf1Y9DXT6JvkqSiD7NioE757RK0ost5k/BOW5GgD1BA0Ech0QJR kS8XP8I9ESF4EEKwBOQjRKeUdNYMNAK2usKBfIBwBMmHfCUppgT20kPjEsRFyi2AA/K9hXtA1mPJ K2qIAFyRzAc4H6COuGgiMioErUgiEQnW3zCziPY7fCQ1XYjwb+YQ+D77lpQ6h+HlN91vJ/yrC/Rl IbeJxP980TM9UHKm7gtWdbIEhqaLhf8tJuzcTAhK63tm+JfI5dvALtkAm6LNNH7fmtfPUo24B62P A2z/aIEO3xIShCeC0mpP96efq5oqEv9VSDZoaGikL6on/5rtcj5XTW+TjP7baQ/X4PBwypgn9zOD zPJYV/0/a8yhQcz88cvMWTX/28qi3sII239v5OGMhYf3NSht1f0wF6O4U/kwCOe/EbBtq//Z2xtz FM4J0lJcHssLOYv5n/BkZWWTnqvmX9Sq6r6d869u0XvjPnP+j9NmTEQGpUX+24JtO2lwUPKn7rS1 ycEZf/ttfRNvLORf5XHaKSUlZb9n3P8vij8d/4kiJTW1sT6GPzZIK/C/YCiRXVb/0+5pKSklRVxN Ta0VcBSXBPxbWIMW9c7m/4fbubm5hvqfazO5AHHz/7LOG/pPvT8YJKZdPeX2d9+UDmVv75jrnph/ xQeVJPGrI3cAOMtD+h9Vm7TzLwqCfyKbbFfy9+f/NxizV1QI+Fji09c9zpCzNkZ/z7yzE2yB/zTo DYbS8fMfcoZ8r2IUNKKl9YnJGxKO/3dorXd+h2JjYQVki8gv4uAb0fq83v9uWiln/yeLuev7+/tJ 8/hH/B7TiEdeeRvdGmdM93b/IvmI28/PDxsPLyTbJH8LB9qhfLFK750tQjL5z3jf9o58w6CkExYm f5rko/wI4l+d/98LZMTEYKhpaEqDoJjhncoX8/TpNy6c0f/CmGveH4H0PXej9ugvLZ9nvW6e8sxt GlUs/kkDX1sWvxdDaZm3yhuEusuIFu3sf5EwFYcPqJBB8yn4GzO21tP9DeXG/zyipo5O6npe/tOd guGc1w1QuXHrTTr13zHj+nDMRoGAf5LzQoQtRfBivCKuNR+oj/8x5SUo5Lxx53m3RD7NYSRgttmN UuYjKTeny+jORi4KvBUaEVCkevsp6+jufF6gRKdjZLNJ5qF5wZl+TC66LuKR18ZRsXnAuUlab5JG YvnDHV7o97C5lk0mPbvj42Mr2P7rhenrL1sjT3r+X/4IWMkLlKo+aPwRUo5+cEw0ISDTKeQtKVTV 7kqPQftAR05mCJOig4GUsSO/Ky612ASIqUP2ZKxgYZWJ7v9YTqsaSCewga31oN9ZS1by24YQWLC0 duZ6fpXUFlxL1yNLJ8PIQtCoXVIBgoHCXuvB1KokN6/CXNYeuHIgq2FNU+UKzuNu/Gzeoxdv/JaB fiP52xC9oeLUvw7Zl/G9Z7WN0xszs8J6rqZe/kHFdEVdZmhytSjhcspWeYV3NtEIhd1BS/6X0PG0 H+RDGpqndmNJA2qaBp+m6CQrWeaTHZnpoGqQ9GZRwf5iUUNtUyb3uG6zkOwt9e/uaTLSBvrB+0g1 XTXNe6uelVZWVvS2rgpq8AySVlJNI4WM9KuwkK8QbJIvJzerN9lNjJYCsdYB+s53la0sWk6qerH2 7Ow4NuOLc+qaeWqaRmpCNJoBYr8FlOA4nfwrT8ii6hqYcrGnvwCi+DWMddNJCP4fADFAzr/sCVNK C2TDMioK00LT3p5SHk5BQlHkpEe24GJUEPBUeQI0pTQDWYdJ8Q2jlqphavGklwmUmnyyVMDUx5nh afmCAqI84+OPOqdUhFPMfZxfkHSLM4rLW1qKMzzFLeUtFW3BxZUZHmdGy9oJE1rqi8px1cmlKNUW 3HRrWqB4aVnAWV4rRmDs5QoonlKan5YeVxaJTo5ECUsKC8uuuoNRwNfF4QCjTNNK0z0YqMtLy9Iw TqXSnwY/FMqFhIU7DHMcHjY5Rr5h7cNTEHbT0+XqvLXNS5WIBBZfVhqKe6gyrZW82VmYj3J5Zkvk TOLl8sziyJn24uUZuMp69UhKDET1bf+KdSYlFNWOCIikf3HaFzofSCgo1dO0spCnpenSs2XhTh8V SM6Cn5nVgknYmRFwZgVMpVvSRpV5nHF4AsjZm5ox4bLppZ6ilvZVEEoJ91SuAyz1jIralvCtJBd9 16kTpkYGXK5Y3NK3YsQXV87GosFXxVL5+ElvcQaKv0xPS2+Jy4j3DM+WTdUKppV2vGrkwdS5JXj8 jFmbIW6+bK1X3Dx1eulGJ57vN08rbdWEVlA+pmxtb5wr3ejBI12lajJVJsqIR0ZoglzzrVqUyp+2 EZ8bi9VZQyWoeFWbIJUWFUkTVNWmhdKckTQNaUYozavSJANo7TQaHS+aUMQJ9cKWwXTKF9fSLGUL EfOKeesyB+R528S81uS0vDZxzTp9RPqy0aniGpQcBJ0Mq4c9CHsG9ieYmWKh+bBZsEUwI7hFTG3t 3iNvI5yq1vgE5Vzamjs47PTui8ovXTcqyR37lLiCPoVpuPr0dd1S5dWnr0tMVGGr06lKlK2z2mRC fbh59bJ58sTM1sSQU9nqSgw74etOiTg1rdl5YSemr3L8rdZo5VREHF9rbl7YyewXdnp40Ehfa2o3 dyjrpMvCZS7KDzvdQheoWJegmluxzh4tw1mtmTnqxKTWkukhZ93wkXmDRieJSejlJIziJIx2PXQx TMM7QzXmpRreTug+6Ynq1vpqdeHi1gRXXshJSgo7GA3pjGmNk0O7FY4tRqVc1JqcopwLW+1wxCCR 7bXnuD84WO0+uHuQ27NZDMc8Dkf9w1v1FPdomxgpcshJbjEUYTTCISKn1eXOHu1AXIg8kUsxSB2M 0IXwApHb6nR7N4lhWEDDvNla7PvZ72vevb165+16I9/9+hup7sWvidcQuN8Q9W+I7S/0c29/Yfiw 7cK+rXCbhkfYhrescXmTdgu43p6t5+fkOVs9rd7Wya31rYtbV7YGWne27mu1bWk91CpzewufQIfc hSK2xF2iTbp81uXasGf6uec9Ix585vFntKEbE93ZvxGbn052P/V0kvvppxLdmzZOcW/YeL77yY05 7jbYxiHD3W1igXdEfo57FOzC/AvdF+Wnuwvye7jH5E9xj4Z5YflDctw5udXu3CGD3UMGT3MPHtLT vXPwvsGHButtwU/Wre8zLq8tuG/demcGwk+8MeutsXnrU8e5d84V+65RvbHeIxfpNeheW/C3Xmt9 PBbFPKwMeS51rjU+r/5e4a1BsXr/Yv9Kf8BvPO57xqd62a8apebduehObd4yUX+7WLT0waXa4pWC KidXbqnUvRX1FZrzCs8Vy67Q20SD90lXjrvWNc69DjbAFefu7+rjznINd/dzJbj/lPlppvZKpgz0 TJfTvcJT4Ha7errx4eL2uEa5H0yd4k5NG+tOSx3lTkU9iSiX4BrtjneluuNg9S7hdY0uyCOziBX4 yhb5Yp5YJB4Xz4hXxKciKGyxJGIpm/JpHi2ix+kZeoU+pSDZbNah7lgtVtde0V7Rg1pQNxzRw03G cF0bLmj4ZJNoQ+lA/ASaMG1MIEEgnDpmrTUna0KgesqYH952W4/AcvnJuLhHWVsU8uAjNiBuLwtE yae3cikLLGjA14KGgF4UMBfVVgTMGYULZCRGRmLwQhRTFIiVfmxGoQi4imoDrozCrAVZHUEdYSdM lvzqcIquzeqKBnV11YIs0ZBFKKVSVE1SsiLSfqGGrmsKnVUdysJztqgWgo6o3PIC+Fg19zS7TIdM u4xGY6a+GzcpBT8IvnviuhPVJ8r0+9Ufvl1Oq2kjPU8vt28aNtOzKlxIrbSFXuy0M/k+3UWraAft xXRFuIdW0K8oAO9ueE3CLxppmUp9iH5Jj9E62kTPnXHP8wfRI+w9p7lEqAV/IYe2SywQt6Pmu2kM juc7lLiZFtNwHN8AEdQu1vO16doO7RZtnhb+HyjtBvRui75bf4Qm4thCr9PTXRT+vvhKfEUN9GeM 23bxU+15WkOP0A/RnjvQ64cRm0c/oh/T/bTy1KLmFlOc8VmnpDb6Nd1EM+iPGOmtKHETTSU5kndA m8hGqeQ2lYfzrqZffJPe/jcwrtSewGjdpb2kj9E2awE9WzP0zeIOrLejukHlOMrQ/okYBz9NwHis okexsppU4aVYWa10O9aH5Boc99ER+oG2GvmvpWv1B/QLcG4zXUiV4nsiCqWH0waxgt6j6Tjq8cB4 TzyH0UdJYzPVYrVtNvZaUiwf0Sy6DLZaPGlsML1GzVQH2wrV5EumBe8Z+NC0kOtJs2aQtOyX3n5J yQWD0uPS4/pABHIdXWyif8iQ4GBh0H6sma2mXar0dG+srmua+XJTFJUbWXq5ST26o51DyeQ0aYi9 sz462jwSznvrHQ7lvPWE3Q7HipxPxiCj1WnVZmZl406dmbX/+H7K/zg3O/+CQULP0BMyhuSKrd1X 9Xx9xw7Trn+8YAw9mv0H2Yb5+i5tq9ml2tDb69LMZrJgi67rRn+yOC0ei27Jnol6Pqb8UbnZo0K1 yUPbmnVj1gqY2XX8Ka1Amvw3hruJTHeiTw7R3ZtcYhPDtGGmPNs8bZ6p3LZIW2Sqt1nxufXZetly A453uPQut5bYptv1hVZhsmm6VTPijfONIUahMc242rAYnuhobaRhWOxWXViirDa7btJc1Bb8yBvn cGgjyWy3QzWZC6kH1zudZul8uD42VjlHvXY5ZOSQI4j4AW+avCr5YmJjJsdoJpusRSpGM8HSFjys aoBzYr2sE84Rb5ysy2KSeSy6rAep2zbIaizV0c4vQw/OjzH0ER+xuOThGLb8UfHDs7NmxicPx+jN nI9n68z56RlxIkPEZWBliHTTnc+faLzuxKKNIkY0iBqRYNKP3a1fdfS4adex5/QLMUsjg+/q+zFL 3aivyFxrlq//Xldqby0qOdmVQj3HuAwR1XtMlA19+9LrUn1NThVO2Qthlg0XslMyHc4+by/ZbCEy z0uPUXliXDJPjCoYkyQ7F4PV9aTMFROTeV6cbL/kpYi3ZctLWVhe+fiKy82Jy43LvWBQmrdfpldO xAj9Qs/gXiP6TvIU9rq+uyVVi0pTrRwdaSWaJkc0QY66SCWPmj01ByRfYXqreZyXmZ4WkxQbq42M URliUmWGmFR5Mqb+vNAof6yC41mjRrW3Bm1BY2aKrLL0jCFms8VszujV97y+fYcMzhual5ebk5Qc l6vH9e2b0cuc6ErKzcnT92/u783KLBl+xf15Q0dNLLjw17OmNRZt3lw8b/QdDzXfOn75/D6DXAmJ Ey8e/+Ztd74x+eKpfc4T+48e027slfrmS7/bpVb9zbiV9hgzKZ5WeNMo2hntiR4UbTissUSLjB8b mlFoizVZo9C9Lets8UNl6I1VS5BcDkuU7BmW09ENanWl4oY+5I1zOrWRVrWmrYYcAKQeU+sSzgmv Xc6Y1SELIL5dLUTr3IT2xXc8K2tUXC4mi/LzRx2fmZONqZPDkqF6bsHKy00MDYe2x5aYnT5xecHm zTX3juvRI16/06yPGX3sA2Pmqism6Lp8mrrDRwXd8t848Bp/Fgc2n6c/Gvjggw8++OCDDz744IMP Pvjggw8++OCDDz744IMPPvj43znU//zL/5R3QeV/uUsup7HBLxH2Ec/K74A3dNLIQaR8E3wnDumb VbpH+RaV3l/5UcofpXwrylXTxLAvkD8Q9jWKEdvDvk6DxKNh3+iQx0QpYk/YN3dIt9CRdj+K+one Yd9K3cWhsG+nYs0R9qO1e7Qpyrd16ItdttP4UPmODukx0jeOKt8p22myKT8BfrwpRfmuDvkTVX9D flKH9G6qbD/lp6lrhers0SGPu4PfW+Ufpvx+yi9W/gDlT5N+VIf2R3W4lqNDuiPSl0tpHs2nOqqg OTSXrkeskq4X0eSj2Yj/BXby/FRqQDgXc1WBtGr9Pn2t/pT+DGyjvklfQ7/EPOfQIBzD1E88XEVV yDePFsD8KOuhAlVbvdIKpFwFby4NxJnRqH8OwvlIq6FanFugYj6EPoQLodXIOQ3lalFKtsiDvDKX D2EDUmU+j0qX5WrU2QaVKst64MurViNWp3pwNdLmtZfp+qz/rHoiWzRX1SVb48FdMle1LXT90Pg1 qD55wiOZHW7BvA49qELsWpxtUKMhcw/ssg2dx2KK6vO1GEXZ+hJV14L2dg1BHYMoD/XIFoSu9V3V D5k7NEq16kw9jUCrsnFWHgNR+6lXHqhaWIc8DVgxcgxq1CjUo4brqUy13qNadT3Ca9UMhsYkNF9+ 1aYGNQYyXq+uXqdGKjJWlapsZByLMJITsUZCZed3OFOvWlaNq1SpGkPj/111rSpo19cNxWXeKozX tWrWQytkHrRana9XI3l9+0yFrnVVuIaqcF0+pXIFn9pveX6O8jJR6ny1TuvQr8iVumrV3H+q+euP 0cnaq1VNNe33T2gdVbWv0q77fnLldm7XyA4jIHsS6kuDul5k/cv6Q32tRsp3Vc/nqbup656Gxrmi 05j6wvfBqXeDHFW5Kq9VJWVrF6re+NrrkTnnIMe/nqGTTzr5LLuqPf6uevL5Oj0JfZ2edeppZ/Q0 LjAmGGONC6HDkbsC7ZA9nBtqrQiIn+ukxn008s8P38EVpIe+Cy9YQktO8w16OoU+DUUw2P7TZKSV aFcitQLexSS08doM0rWZ2lL4t2n3wr9Puw/+/dr98B/QHoD/M20F/Ae1Q/D/ph2B/5XuIKFH6/gs 1uP0bvBT9VT4aXox/LH6BPgT9Rvgf0//HvxGvRn+In0Rafpi/TD8L/Rj8I8bOfiMyTVySTcGG1Xw q41q+D7DD7/GqIM/17gW/kKjCX6zcSv8pQbaadxnoJ3G/cbD8FcZq+A/YjwC/1FjO/wXjRfh7zD2 wX/XeB/+fuMT+J8an8M/bKANxhfG3+EfMb1PwrTfdJB0019MH8L/q+kw/C9MX8D/0oT+mr6y4FqW +y1/Jt1ywPI5aZbD1jEkrAXWcaRbL7auh/+E9Qn4G6wb4W+yPg//99Y/wd9n/RT+IWuQhI1seFex Rdmi4FttcfDjbfHwE2zj4U+wTYA/0VYGf7ptOum2K2z18K+xXYP0+bZb4S+1rUb6r2y/Qsoa2+Pw Azb01/ai7TX4r9sxp/bxdrxv2KfaMZ72arsffo19Lvx5dtRmv8Z+C/wW+21Iv91+J/y77Mvh322/ F/599gfhr3RU4LO80uEj3eF3/Az+CseDpDlWOjbB/41jK9J/Fz0Va8oIv8Np1AdraTxWyARtAhna RO2S8OyH5tSE2ZwNvRpzqqnZNBk/xTyaMKroi+XXlgAZlrWWtfDXWZ6Ev8myGfqM5QXoK5bd0D9Y 9uDsm5Y34e+17IX/R8vb8N+xYJYt71reIwMzUhwe/8j4vGh7Cf7Ltl1k2Hbbdqu+30qGfal9qeoj RslR7agmw+FDf4Vjs+O30GcdzyLlOcdz8Leiv4bqpY1uFwvJVDG/opI8VdfPn0MX1foq59PEORUN c6m0obbiKty9NhKXTyn04L2WcOdp6ttOQ57AHWmou1bGNLK2x+TPe6LclEmXnCxnICXkmfBGebKc fBuNrquYfzVNVlqqtFypX2mL0hVKW+uurrua2pRuUbpN6U6le5TuUzMYmclQKEh+36uTEtCeREqi ZEqhbpRKadSdelBPcuNZmE69kEf2yYRWRaE/NrQ0+jRpQr2pyn7rncIYiu0yjKN4yqJSKseTuJ6u o8V0s/qu8pX0KN7A22gLbaOdtAetP0iH6Ag2EVHCKVKERwwUo8R4USrKRa2oFzeJ1aJVbBLPiu1i t9gr3hMfqvkU4j60EaF9M1qKMMYVCmNPhNa1c0Uo7NM7HH4ZCs+bFgozc0Jh3phQOLRfKBwWEwrz 7yJsYEh4e5IZQyouTSIzTojJ80Pnp/QnMwZZfKc3meXP75S2htpVegDjhnD69FB8+k3hcFUovMIV CmdqKp8xK2ZWr1l5s8aHY22zdszaN+twKFYeKN9avqf8o1CsYnrF3IolFctD5SunhMKqi0JhdYrK FVX9mc/s6+7L8Y3zXelr8LWo1Fh/vf9G/z3+Nf4t/lf9B/3Hapw1vWuG1UysKa9pqLk51OLaaWov J2pvCNVYuyQUXjUjFM7eHgrnUChf3dxwuFDdHaLuMdy9hdblahexV/6+3cYW2DISzQcRLofhE6n5 E6LvvQ7/F7BHYY8R1a1HKG0T0fytCLfAnoftgO2G7YG9g7KHEe6HfYh8ss5DMOw4G4+FrAkT0YS+ NB9FGIM8mKkm7FDnFhItSAmFTakwD6wvrD8Mn2KLMKFNw5A/E+FFqCsPhtFoHBO6dlOhltq4pPmi ZtecE43bmxuarmte0dTS/GzTo80NSF/RuKauV9Oy5mcb1zSPl37j0821jVub5zYtR54Hmktkujzf 5Gi+R1lPxHsi/WBzQBr8Z6U1voXysKZBYTuG9GPNB+rXNBfWy7pvbi5svB3hdpSD1Y1ontx4V3NJ 0/RQvjoD7dnePB7phbDxp7TnhqY5dZlNKXWZja1Ib0X6TuR/HX6btLpekfId2rlCtbVzfEV73KH8 FY2vo96eqHd7qP6mMegTDHUraxqHNkq7tC5J2WniyLtCWnv8IPxpzSvQl39p7e2ZDr8clgJfmh/+ HJichxY1vg1Nj6n4NsRLVBznMYfPKouMf2g+DqDuBjmO8D+DHWlcgj5Ka1NzfSAyfk3l6LMjbD2b V7f3Ozx/sG2wEjUPT2MerkO+eNQj4x3HXl67N871w7m3UIe0NajjHdTxYd3ApkOLkmT9uM5Aac3a ol7NUYsym44hjEG4rHlb431YIytR5yqEq9RamAwraV8T4bUTsUgbT10Dp67l9jXzXvNi9O2mf8rf MX6wU/mlKP+TpnjMR7yalxXKTo23rzE1hiWnrLmS9jn9p/yh82jTQwgfauoN69f8UGQttqcPQjwP dkrYfg+O+dcWmdP2/F9zTXexxjdIa49vx/rb3mEt56FP0ubDl88Z+dyQz5btza9ije7F2n0Za/dl rI19WOsb1HOoRZ2/B+c3N/0Ccbne14efU+G13r7ml2CN7W7+qM55yjPnOsSlRZ49m+BL2wIfhnIH lL2l7puSyD0Tyd8eP5k/cr5E2mnjzyP/8yfvuaY9aPeek3E89xrks6+L8wfC9+g90tT6W9N8A+7J WozvDXIckCbX9TZlO9vXrbp3T3mGlbTPb8Qi98hbp1gk/ZR8uAe7q3v95LO4Fuk3dHgWjA/bNmWn Wx8HsT5gHZ5hm/GM2oy+nois5fbnVWPzsMa3sI5HdVjH8Xg+fIn4muYZsMrIs1/em8o+Qfww4mvq ijvf34jL+/uoekadGu+Y/x7kL1HnpB3G/X60w2dE+DPh1M863JercV/KZ+Nq9QyL3Fsnx2Ghski/ m1FHc4f74Ub4N54Sb1afw/KzdTz6Xosx2dAhru6H067THYjvUPGXlYXXNdr8GeyIeqZL67nIgNmQ 5yFlbYuc6tkfHpem/aF11kRYl2b1HAx9NnyCcTn8T58lDWqeIs+R1/+5/3h7ilY7dVL78ii1I7eq PXGM2g3HYh/8KcUbX2IHnKD2vonY9R6iVNPn2Pt61K63F/aRl1EftSOU/wqcon2q4V1JN+tm7Nxd ugv7+iQ9GW+43fRuZNa7693JovfUB+F6uXoepenfx07frR/Xj9OdelAP0l3Ymz9KP8Wu/B1arvbg v8TuezGtNi0xLRG5phtN74vBpq/MhrjLbDZHiZXWVus68X9ytysexn62RKyyl9rLxGrsT6PFGry/ f6RddPJNsRpvYzUlJGpmIKyE1eKNFm9q16yCPxfWALuBqApvlFXLYHibrFkMuwm2FPYT2D2wFbCH QmVrVsMCsA1Efry01mwOh8/CtsFeDud7FbYXti8cXxoOD8A+gn0Gw3zUnAil1+Ktsha7u/lmmAMW T2J+CsKesN7Yb/WnEVRIl2L3U0lzsKdcTC10F63AzqeVNtPz2PfspY/ohIgivUqrSfKNqenuG1fT i7SqlJrUqt41HngxNc6q1JokeEaN2bevxkFa5VH/Md9bNdh7VR7yf+bb4z8B74D/oO9l/1F4b/nf 8W3174e32/+qb5N/L2m+Df7tvoB/Jzy8+ftW+Z+H96h/g+8B/2Z4K/xrfD/xt8K7z/8L383+R+Et 99/ja/avQC1L/at8Df674C3B2dn+FjLkGd+N/od8Lf7VvmV+7Po7xirL/RuQe5q/pP52/wx44/0T fTn+Kf+VFW1S/yJF6t+ihOUjy+dk/X/sfX1QW9mV59UDy2pMs27C0ISmMbYxBoe4aUxowtCyLAti CwwK63EcQoPQ1whJcdteljiskIS+kJ4ExbAMRXkYhmUo4nFRHkIYhrAM5bhY1uN1MR6GdljWQ1EM YSiKcbyOl1COy9lzrt4TQtBxz9RM/po69XvnvKv77j333HPPvffxfE3fkbxD33Z8CfwrVmCnfzca h30oUcHOQBcPSALAvvfTEuCw2tedBOQQUgO7jJosAKz2dfkACaAIAPm0sDPQwr4eWkJ0l0GGXYOu CqABGABXAfUAM8AO8ECeSwDwT10roANwE9ALAH/WDQKGAWOgB9x/CvefPgjU8ekj8pWa0ppz6vya c1f61ZKarJpzQcqtKaAkBSpQF6lL1OVwLQcqURdBSrnuIPKaAl28Lh6vNQWfpn968tOcT/M/xXNB YqEXwJeZF8z/IwzzS+iRSNojQtoj+2mPRNMeeZv2yEHokU3yDu2RWOiRp+Tdfc+gX96j/ZK075f7 fkmSoV9KyaEDCuidVOidbpJ2oAf6KOO3Xp+ASEgd7fGTsJ8lSuhlDfSmZpGQ6vs78d1pIqp+qblX /UJzn9LMd5dAXxHzC+YXoO8ms0kEkb8Eb2T2/Xzfz0kEeOAmidy3BX6470DZgTIiPPDHB/6Y7P8X PSOIXftSPokg0YJJiA7kmoowvljgegBEumsQ6a5BpLsG3lMNe9hrbu4eAZHuWnvIPaKLywO4ghGz h0LgHCOMcS4AXwIFlsnL20gmTFVfWFoqYapTdufFNB4h5fK/kWv9nE4Qea8Ncbo0cL8N7cgf0HV0 Rzq5BhH6GkTna/c59PwLMAOYo/YItp8DubYQ1J/WzyGgH9pwicMqhw0K5jqM1mvPgY8xT6pnHdHe G0qRI1Y9U73uSPBazAZHstdpvupI9bLmescJbxukZ3kt1YuOXG+n2ewo8HZDutTbZ7Y7zqnnPplz lEJOj+Oi9xbkqfB2Qn4llFPv0KlnzK0g34HyTSDXO657R+Ca4G0zd0DO8epncL1rvum44Z2GdAuk 98L1IVyd6iVljIP1zpoHHG3eefOgo9O7aB52OCFlzNHtXTFPOvq868o0xy3vM9DhjnrJPOUY8W6a HzjGva8g5S5NmYaUR46HLKNMdMyyIsg/z8aYH8M1zvzEseh9Zl52rECeNcc6m2h+6njGppjH9NNQ /gvHpnrD/NLxik0DeVG90UicDJvZKHSK2OzGaLDPjcZYvKLd2LzGBLRYY7IzxtvZmIqWbDwB1/HG NmeedzZ4FcO1k17bQq7dThl7qbEP5BW45tEryrfo9Y5TzlY2jjgV3k24yuE67rwE17vOSlbUOO0U szFwzYNrn1MF11tOPU25QlPqgqUF5FvOBrhOO23wa5YzjhU35joTWVnjQ6ebVX3COP2s3upxeXwH GwucKdBGKW3pOdqiFWc/29C47rzN2hpnnQ3slcZnzhj1UmMpzXORWqDUmQZyBZWV9KpzZnq7G3XQ X92NJnq97sxkYY9Gywy9WqjFQq+bziFo6SvnqJe1MN81sG6LyDnB+i0xzntsoiXOeV+9BLIKesQJ vaBonHe2e+cbWWe292HjIljmCqR0gYbzzh62zpLoyGLbLSlOlXrVkuacYeXmeucc22XJhN7vsSQ6 F7wWS7ZzybvIySnOVfQ65wb0UQG20ZIHv87iqGH70T/Z2xaxc4NVgGemQvq8IxlkGDvsEHopO2oR owUsMrS/Jc5RCtrKnc+9mxaFcwvkS87XKNP0S65IkCuh1Z3KFFcUK7JUoi8pU7CXLYmug6iPK56N sahcSd42i955D/JfcU6oZyx1riNsJaSne0csDa6T4Mkwytgu81NXDjthUdER9xTKSbHYoMxxi8yV D/q4Q2Q/lPnQ0g7t7bN0uZJAnx6XBOR+8I17ltvOVfa+ZchVxM5YRl0lYIcJp8o7y1npHlrJcp/K E/DUrGUGxilrmYM8K5YFaoEUaoElKq86e0DewKgClsG+eE7lLace5NfObDbPGonp1iiMOZY41Adi S5a303rQFaVessa7yiEKTeFYsCa5LqPsqgI5NP2I6zI7B+kadsKa7kxhF6wnXQZ2yZrjOMeuWvMd d9kNqwRqXLIWOUpBLnFMs8+hlgR2i8aK16Gy5TnYymItd9axMfpbKIPmIIOdTWBniCHsc7Ah2j+G t7+3zXoZakyxVm3b2apB2VruymdjrAY+HcrpcMb4IpVprqu+KOtVV7132lrvMrNpUKbd+9Bqhr67 YrVDSzetVzFaBn4NlW3zKNsWm4fwKYyiVrNr2ddRve5qZduh5A6sxZ3lHTePuXO9K6E+3FjQPOq9 YVvBGAU+zHmvvxS9l1VYZM0T0F/Uz0G+512xreOIBu9VoJ0dBf6LGHv9FRjt/UoaY0dhrFWgxzbf h3rtjgq/Tpmmn4Z0N0Z+aPUgxFiI9n6T7ZmT8XWE6gxyLpUf+zp4T4bIPAFtuem1gM7dMAvAKPPf onrewbb4r2Nb/Ddsm80z6iXbK5g1xmEWiPWX4gzit+Ac53dSubSJcW6oZ2w6BwQ7SE/2O5tEILfh +PV34izD3qbyOZT9Qk4egPQNmLNS/d1NoIO/L1SHpjicK5sScVayPG+e81psJ9w31KtNKejDVo3j hHqpKc2R6x+xHnTc8UkgHfy5KTOYPo7poBvI7BaV76Bt0YcdI+zzpmyIdXMQQ2Cma8pznPPftcAc x44GZPRnfyl6MrQXZj1/BdhhwV+q7G9e8k/jHA0liyGdyuxGk8wx7ZtqkuOs3aRwn2OZpktUrsS5 Emdz/0OcN/2zlvs4pzep3BWsCOd3/4gyzjHrL6XyOI4OnwRlduuTK3SkqGCMt0F8q4Ra4ppXwSZ6 Vy/bBfIGyFeaZTDbwqjx63DU+OepvBiQm+oc11l/U0OzzL+CqwVoC8zL/nUoE1YOTbbm5xDzVc0L vNzkdlwHS/oh/zrYH0ZcU7tbCDM4+Izfgj7jf7YtfyLb9iX/Jq5AfJE41/vvfJ5sWWje8t4FP5xU Y79X+F/hqqCFCR1ruHppEeE6oSUGdIA1TFOXa1gNbYd+b2vq4WTw7aYe9zz6NsRJLtLiOsdvwhWF by1U5jyhH2aolKbbOLqbhlzL/r6m0ebX3tmmCRh9m+YBV693HkbEgC8e5EGIY60Qf1asHVDjEqSM eec/mXNN0jxTELtuuh54FwMzlLXX9ciXZB1wPYYYBV7tHYH48MR3xDroivelw1PxsOKqh5F4Ep5d g2eHXU/ZLuuY6wXUNeV6CbWb3QQiLYxr9Zw13xUPtU+C5d3WQXe0L9065Y715VQvuhN8+cpEvQ48 ZN2djGtLdyqU/MJ9wldk7oA1Rol5oDqBrVOKXMO+8qZ7uGKxmTyRLXHmXpcHIsAD12XfZfNTd4Gv ylzvlsIsNukq92lQZrugzHMQDURQjsH6yF3qu2p97L7oqzf3ooUbhe4Kb5/1iXOBvRS4Nt0H+8w2 zXiivHegf+/CmJ3zHGxJbFrwxLekNC15klrSmlY9R1oymzY86S3ZTc89J1vymrY8OS3iptee/BZZ ID2wEoBoCSs32zquZyASwowDM1oCXTPAGgxmLli9wNwNKy5lpqO7RW6P9EhaFPYoT5F3OrCixrWr etV+0JHVckmJT722XIEV9UxgLsZVNJuHsRTyxHtK2DyYNytBToK2vIY1z1JLpf2Ip7xFZU/3XG7R 2096qlqu2HM8mha6zqGaQP7qRY+hpcFc77kK65xKHMtQ1xKsGwvAGlwr7PnbLbJLtlcs9qJt2bbu qceWesw4z3KyHVqdyLWazozbskXlnMBViuuId1PfBz7GyRD/EzD+o2WsVQEZ5xTroDOlxWZedj/0 z4OewXnf3OHxQKyo97R6R6AfcT0GI6XF3Sj0dLT47SW4Rm3qcbBg4XJndku7ZdVz07vSVOfphRHX 5YrydShj3ErvrDLOrfPOW5f1uAcZgDXwPNRl8pnNa+7rMF8Pu2+wt80Dbot3HvI7Mb8e9h3WNTfr s8O1jV47fXZlmrvb57E+dff5Wq0v3Bb1KqTcotdumOleuO9AjdnuEZ8BUsZ9UVAm7kTgCmuMl27Y jzRufhLn3bQR90NWbhO6Z30aWzSubK0l343y3bQOuOfZLluse9HXa0twr/gGlInudZ8keL2Fuxg9 1GVLdj/zDdpS9RbfMMw1m+pVW5b7lW/MluucgWuW+6Fv0rzczLDP4SryTcE1BuotaI7zPVBmNif6 HsGoH/al071Pj+2EcwFKkMLc9Nja2pzie2Q758j1PbGVNqf5BmwXcf4N7IxsFc2ZvmWw0nWYhV+4 X6k3bEr3CKxAdM4U2CUJYXXXF4hj9PrUZmrO9r3grteb83wvzcPNYlZkuwFxmyhj9Dq/0GZxKH3D yrRmuc8D12yfx+ZsVrAxysTmS5CTba4EDduaVf5oZUyzXr0AGl5hR3eU1tlc54+1dTc3+BOonGzr a7b5U223mt3+E7Y77lx/lm2k2e/PtY03t/sLbHebu7ydtunmHr/U9rC5nxU5iLeitb5x05vs3bRP eRO8r3CFACuQKc8A+1yZ6BlkX8OK2tDSZZttvu0/F7jaL3uGW3rsVZ6xln67xjPZcttu8Ey1DNmv eh60jAZ2x/Z6z6OWCbRzyz20Sct9u9nzuGWG29sGdrV0Pxu6V+V2qXR/ard7nuzcpQb2oXaPZ7ll zt7qWWtZsHd4nrYs2W96XrSs2ns9L1s27ANeAk/RcuyDXmHLc/uwN7plC+uFkqHeltdYb2tkcB99 F9Jh/dAahZq0HkRNWuO3NYF00KE1KeAtOBuymbg7DuyLW4/gGgzKpDtr7KPWdFwdtZ7EcdSag+OI vc/t32FV0xplH3N0tuZzpYF3tabbJ72xrZLAG4ngW4Jo711ca7UW2R97T8AcHXj/QHf69iferNZy +7I3t/Uy954hsKOnbxICe3b7S+/F1qtcXzyA1pVwby3oOwp8qrXKvuYt8AvtT73SVo0yzXvO57G/ 8Ja2GuyPvKm+l/Str5y5QAj9kixy/x/t/yHZR78PS6Lfhx2m34el7v+b/cvkA/rt11n67dc3ov5X 1Cy5eIA94CeV9Du26uiJ6CmihhLzSCr5mBAiI5+QRKIiTSSHnmt1kbSRPyC/R3rJfyPfIgNA3yaD ZIhUkB+TcVJNpslnpIYskZ+Ra+QfyQb5HtkkvyaNAkZwgjQL8gT5ZEggEzjIjwQ+QTv5BVPEnCe/ Yj5hlOTXzH9mGgQRjIvxCN6KKIkoE7wdoYn4fcE7EXUR3xf8TuRXI08K3ov8SeQ9wfvCLwsTBYeE ScKjgsPCNOEHggxhjvAjwSlhvvC84CNhifD3Bd8QXhV+T6AWNgj/q8Ao7BL+UODavylKF/yJKFP0 VcGs6APRB4I5UY5IJvhMdEF0QbAqKhf5Bf8o+gNRO3NE9IeiTiZV1C0aZ9JEE6ItphD/usLYo4ai fsg4okaifsy4DlgPeBhfdEx0AfOH0b3Rg8xU9HT0NPO30fejZ5jZ6M+iP2P+d/R89DyzEL0SvcL8 HyIA2xnoW9Nk/K6pGFCyCFgBrJNE+VLJYslKyXrJs5LNklcXGFAq5kLchcQLKRfSLmReyL6Qd0F8 QXZBfkFxIUW+Kt+4cOlCJX4bRr8hJPu793cTZv+f7v9Tgv8WJFawIFggRLAqWCUCwZpgjTCCfxL8 E4kQPBP8XxIp2BRsEqHgV4Jfkf1MBBNBRMw+RkTeYt5m3gZfOsi8Q2KYeCaeHGTeY94j7zBHmaMk ljnGpJMvMTlMDnkX+uEnJAEtR74MbZoni7RlsfhNnDyXqOTrxZXFqmJ98ZXiuuKGYluxu9hf3F7c VdxT3F98u3gIMFo8UXwP7vqL70OumeIr8hPyZ/JN+St5bjEjP1cskhcUxxTHFScWp0BqbnFacWZx dnFesVguLZYVy4sVkOcSPLNNuRxNy2cBD7m7ecAdjkrlF+UV8hW5Ur4ob5Pr5Cb5dfkNuUXulLPy TvldSO+W98lvQc4R+Th+afXWz8Ga8TvGAn7hnEOugmfnk+/DuJDSsVAMY2CIXIBR8GNSCmPgM1JG 1oEU1EbfBF/qIeWiXlEv+T1Rv6ifXBINiH5AviX6M9GfkW+L/lz056RC9CPRj8h3RH8h+gtSKbor +gn5RDQn+oxUi34q+imMKQHphtGGVj6C3xyWXQeMA+4CpgEPSUHZJUWRokRRrrisqFJoFAbFVUW9 wqyQKOwKj6JV0aG4qehVDCgGFcOKMcWkYkrxQPGobKZsomyu7ErZQtlS2WrZRtnzsq2y12V1ikhF lOKgIl6RVNZQZitzK44o0hUnFTmK/DJ/2f2ye2U9ZaoyveJxWXtZF36Vtv/B/hn6PWLUDmt9HyiH /A3Q18g/AOVCZPgZ+YisAeWJ/lr01+TrohnRDMkX/b3o78nvEkH0s7cD/2rpBH4PWtULgFarXgEf BAwTgRpq+4Yp4sOqm6r1ql7Vs6oB1WbVoOpV1bCaqRpTi6om1TFVU+q4qgfqxKpH6pSqx+q0qifq zKpldTb9bU2dV/VULab8hVpW9VItryZqRbVQfak6Wl1ZHatWVSeo9dXJ6ivVqeq66hPqhuosta06 V+2mvEDtr5aq26l8Tt1VXaruqb6o7q+uUN+mslI9RNN16lGaB2FST1RfV9+rvqG+T3/DvBb1TLVT PUdlVr1Q3aZaR9D2QFuqO9Ux1d3qvOo+0At12AuoE+oTCtQhFLwu4cD0UEzDTvKWegntUv1Q/Zzm mVVv8XpRXRY1kdUrmiiqM9oH0++ArjxHjKgTdwCf44Ft4YG6rWsOVj/TxFdvQh+gfV6BvdEW47A7 wLrvQh1Y17z6NbUj2gQ49q2SqXiOz6C90A5KEcdjNEnoG2gfnivjVK+UiZojWC61LdrpToArU9SZ qAv6iDJNk055puYkrQvtwnPUH2yizFbLsD95HtQdfQj6V5mnVijFmhzaRnyO53zbOK6UafKVco1E qdAUBfUU7WxLuK5BztkhaI/JAFdeUscpK9VdSpWmRKnXlKOdaNs4Tvsj5B7HB/oujhFqZwC2n/42 GWh3kK8F2h/kL3a3X3lFcznYXmFY+/l7HF/o+1zfKus0VTXDgbRwHszToNEobRqDckIzoLynGeTt Rf3uDbxm7Iv9viNfuL2/AK+ZDLkPtzNnM96HfhOvmdq+r3kQaPfncd4u4baueRSw05s4HcPY73fD OOfLVG9oD++HvN1rHqueUb/r3cmD/gvjjaYP/mYebsdgPWF+X/NELapZhpjbue3n1CenApz3e/4+ yEP8vmZN3VPzVJ1W8wJ8nPP3IOd8HmMB5guOAY7XvFRnY1znOc4lNM53ho2RMP55/cpzFVGLsT08 52MKP7bC7/mxRucsHHNwrxLu5JiOMYjONeRzuDBsTIaPVeBoTxXOh+gPHA+OS24Mq2JhnoQ5jOdB /+FjXWoYx7KxfiwD84EvqRI0VbTtbs3VoB/5NfXUT3Au5OI7xm5lu8bM56ExCPxE2aWx8/M+6qns 0Xj4sReMazjHYBzp17SGxjPlbU2HckhzUzmq6aVlwjzD21Z5XzNM56Aw+ylnNGNoL+WcZpKWzbUN 9UDgM8rnmifKBc0U7dtkbbcqVdunOqG9pcrS3lHlakdUBdpxlVR7V3VOO433wbjDxY2gn/D9AWNA VapewnmZj/X8WAj6dFiMUV0EXdDmEN9VFds68M+plNqHKp12Nji/hcfG8Bg3snMOCfflXfNi2Pyn MmnnVde1i8E5akuzrLqhXVFZtOtB/+Dr5svm/QnnxiXNA0RwLcavx7g1mXJV80i5oXlMbQ9lK19r 1oLrNLRTpOYp9eEozYsd6x5unYT+UnNQ85L6Co75eNgQ4xjn13MYV5O0QhqXj2ija9K1sVRHbGsY ak5qEyhytMkIOlbRl1Af4DX52lTqT9x6sEaiPVFTpM0KrgtRzxJtLtqkplxbQG2D4NvNAfu85rJW im3F9tVUac/VaLSl9HmD9mKorWquaitq6rXKGrNWV2PXmmo82us1rdobNR1aS81NrbOmV8vWDGjb sI2qeZ2MX9fiHKNyap+pWO2mqk37Cv2vZlDbqerUMQi6DufGKI2XOFawvaCvqlsnCvYRtp23Jbcm pjaCOqkdsH3ol326GNUtXZzqji4xGL+x/8A+aKcd5SEPX3eHrrfB1qoRXQqNTVg+50dBn+H8Jbhu RlthP2E5kJ/GGm5fEJybuDWTalyXhmUFYzM3l6pmdWK0g+quLlM1rcumew3Mg36N60NY86ke6vKw LtzB7/+H/T8jJOrv8N8mHmg50EJw//PV3/L7Fw/5dURJxDXBV+jblm/Sty3fom9bvk3ftnxHmCT8 oeAT+g7lF6JM0QdMGr49YU7g/pb5XXx7whTQtyffo29Pvk/fnvwX+vbkJn178lP69mSevj1ZoG9P lujbk3V8exLxZXx7EpGGb08ijuPbk4iT+PYk4gN8exKRBfvefnJ7+x2D2EPOicfEU+IH4kfix2Iz 8CfiZSCzeE38FGSz+AXgJZAH6TQRD8NVKJ48HX069nTC6eTTqadPgJx1Ovd0wWnp6XOno8WtcF96 +uLpitNKcYd48LTutOn09dM3xK2UOoBuUuqlNABSKwXKAHxfsH8Y+u5A2A64AfqukVhh73sH6Ot0 N5xP/pbMwn53DuhjwfcEN4gY33kRCb7zgicF5DKpCmnvTXKE1tYLGBAPQmsGQRoTT0KbA1ZAO2Db 16DlL+H6BNqMfI1aYeC0EFq/RnX8K9DxXdAxFXRMAxKQdCAGdtx4EkYmUCQ5ST4g+8iHJBt24V8j eeQt0ElG3iZFQDHkHNB/IHKgg/R/gHmHlJIy0PSbpJzEgXdeJvH0X8onknqg94gFKInYgN4nD4GS oe1/Rw4JYgQx5DARCOuF5u226t0RH+rdev/Zi/p2abmkQrZ1NkHCStgzPeLsM0Nnk8XZkgoxczZa ojzTJV0+06Xvkl4Vi874pcvSYcn18xZ9j6RC3w95Y/S3z1vOiGUb8IRTP6QfPRMjFn08ft4iMekn JH36e9IxqMetn5OWY6nwfAjpF/Q9AToTEyAshafzFo6yZKvi7Np6ibN2AMsC2VPbqr8nFund0nIE tIANkDgbKVA6libOkyip3mP69lozPHFPUlFrl23p+yWsfsHAnr0ouY6AFrmlywap4Zy+HeR2Q6nh IpSN1hDzQP0RqOPZ6DMxYJ1kLN3QZug80/XxuHT5vAWBtSGkZt2k9AmWy9eCJfJAHRAGsOPZBCg/ T5oP9o/hoX9dGwU63j7Tc94izjboDCasu7aj9ibWH9DBYKGtC6kbYbhouKXv0k9ga2t7UeKBKfgk 5kK9/jkAnVdD9Q/DKupsUNbG156slfAahmKv9Noc/Uzt1W3NQ4HphkXayxTaHtNJcfbH01LzR1l6 N/itXzqsv6+fMSQbUvVz4EnYb0vwTIJ+y3DivEVXonnG66fr1Q0Ysgy5UrOhQFKB3h6weSj0z/Vb tZEfFWA70OYIqaf2oGyrNh6QZLhuuKF5pr1/Zki2wYP3iNojBmdtupYJbx+MkSFEwFtqyxHiSqgD eq32cm0Vcl7GXjR012oMfbWRhju6l4YRw7jhrmHa8NAwG/SsLonJ0G2Y5/tTelXSh0D7BLyuMN6w Ylg3PPt4HHLcwzEA47WvdlA6XDsMklPWJbkOI2GsdhIsPFX7oPZR7WNo3RNpzhkxjn4YtyNnL9Yu n02uXYN2Pa19IS2qtde+DIwiAzEIqZ7RMMbGCuMDtdYWGWI/HgHddPoh44bxuXHrLDG+NkWaokwH TfHoO2hT3u8+npatmpJ478caa/NriyiKTEf0twMl4G+m9I+oz4d4IO1NfoRsjwO0LrSUs5Ip56MT 2KOmfOnY+SzIo8enaW6wk2Hz7EXDKyNjFBljjHGgz6Yx0ZgiFolF0mFjmr5f3194xJh5dtwI49yY R6NS+5l2cZ5RbJRJq4xy6PFOo0LiNF6SPjJWSqYl00ZVrd2oh3yyMynGK9oFY50xTaI0Nojjag0Y KT+ePm8x2mAUxxnd0jGj39guuSuOkZiMXVBDj7HfeBv4kHEU6pzAX4z3jPeN92RbxhnjnHFBtgWR s1TaanqKsVZ60yQxFZ2RGZeMq9Ic4wSOBMl1iB5dphJTubRIOgw9WIHRWD9E4ynEYoh9/aarpnqT Gawm1g+Z7CaPUWZqNXVA+k1Th6nXNACpg8ZRY4NpGH4ZM03WliCZpkwP9BumR6bHpiemZdMajLnl M9mBPtDfNlWZNGh3GlVBB0kszhpno8HWceIYk8F0mc6Ek/++0tpjpYXnCOAbeDy9iuT2EEHuFonL bQW6CdQLNAA0CNSb+yJ3GAjTxoAmgVCeAnoAhGmPgB4DYfoToGWgtVxciTD7x/b/mJ7bUEi+AT1w nhTD+uMCrCKE5D+CnQ9Aj3yC/8IENHtKNaJ/OTsbQwRFNuBxwGGtcFYkyz8bA4gDJAJSAGmATEA2 IA8gBsgAcoCC++0SoJLjKoAecAVQB2gA2ABugB/QDugC9AD6OX4bMMTJo4AJwD3AfU6e4dLnuDyI BcASYJX7DfNuAJ5z8hZAxCGOawuvax2nw17o5/QJxUQYeF3CMboTsijgrwN1yg4G8sjiQ/TC9COA dE5nP5eeEsJTOLuH4lII6kIAuslOAnK4Plji7A22kEVydfsDdcmSODtmchzKRaLPxHF24LhMwunT FcLBP2RFgXKpjrdDuJyzE3BZCcfLubpGQ/glzm4qrj95zut+hetf4LLLXBtHQzjXtmAbqwAagCFE z7C27NKV57wdwnk215dXAfWc/Sd+A8fxgb4r4/r0fog9Pq/94XYIab/MvEe7wzmOr42QvrWHpIVz Po8H0Ap4AHi0R//+a/PPs/sX5eF2DrfdF+TBdr+Bh9uYt9ObOG/fXZz35Uth7eLtE8P5Wzjn/TaR u38T/6L2xLiOMTfMz9/Iw/uB9/NwHhID9uQ4d8zswcPHyJvGTDiv5NrD8/DY8nmx5k08JBbtyd80 RnnewNmH5+HjE+fJ5yGc95+wWBfko1z9G1y+Lm78Q9tlHbKgH8luyrb9iY/rOCf0bueh9gP/kA3I tud90FM2GNLnXP/SOQb58M6+kY0BJgFTXL1J2zaUPebmoDD7yZ4E7CNb3tlW1IMCnikkwNcCZRbe BUwDHgJmAfOARcAKYD1wHxxX4fGC7wccA6+5eTk85vM+HB47Bjib39upA/9c4TPAZog93hQD3xTT wn01zJcKX8nyixhZcGwWCuEe6iqKCfEPvm6+TN6f0E+eBhBci/HrMW5NJnsBeBmwPZZdGC3bXqdh e2MDZRUmyHauffh1ErSrMJnzFbgvTJUFxvjMdt7CEwG9CrMAuZyOC7tRWMBBGgD1p/iAPtQ/znH+ xK0HC0sBF2Xb60LUsyJgk0IlZ5utkHbzADsV6gJtxfYVmgDXuedv7LRVoQXgBLCANkAnoBvQB7gF uAMYCbSxSC8LrmtxjimCMVgEMbuIW5cWjoOcFkBwzYr1yLmxshTQt4j30R6uL3hb9oTYaYSzw1Yg vQj8owj6okgc4ms9AfugnXaU1yPbve4OWW+jrYtwfDznyu8K8aHb2/4SXDf3c/00yuWPkW3vC/hx wK2ZiuRcWby/c75apArYoQjmiCJ+r6Hi/Ho1sOYrqgzUhV9Q0ZP4yL/vSHfvSAVtgpf4flgQQySE nLoJ6AUMAAYBw4AxQg4XAZ/k7hFTgAch94hHXB5AVjnwxxzg+VNPuDzLgDUufTgg07xPufQXgJcE OiWAYBn/DOQIAdEBPXJiA+XzoGkJHJI5pHI4QSSnTp7KOZV/SnKqKEWeIqZX+amibYK0El5COlV+ 6jJNraJXzSkD0NVTV+lv9Vwe8ykz5XZ69dCcRVBOK1DHqZtAvacGTg2eGgZLMeQdeoolCTm/MoKe UBk4m/J36BmU8fT0ySR67uT79KvjFPrVcSo9a/JDespkDj1f8mv0fMlcerJkHj1Z8uv0TMnTv8Wa 8BQLw/YpFtmVhCS/+M3IVgH0e6Rf+Zw08L3sOkDD7t+ybbvT31i/G+AnX/lw5cP1f2V69uEmnjBJ Tykl9NTRwHmj++j35FH0e/K36XmjCfSk0SR6xuj79HTRFHqK6BF6fmgaPTM0nZ4TmkFPCD3xb1au IHIocpZEQQ+W4mm+GZmEpHcCSJCLMrIp3sqQwf0rsj9DTEgGQxhIi/hKNIn8SizZB7IwI4/kHY/c TWlDuym9YjftlW8vOv5gN6Urd9PxR7spXbcHmXZShihDlH49jNrS244/3k3pN3ZSRkxGTLi+GXEZ cXulHY/aSRmJGYnplj3IuQftke+L2m8vGxw/uQeN7aY97Ve6B00ff5qee7QuPSs962h2ei5NY3dT WkpG5rHFjOyMvIy8YyvHFmlq2246/jRDdHQoPTetByjx6NDxgeMD6Z17UPduOv5yN6Uxuyk8T0ZK Rsqe9gurMyMtI20v/0vv20n02YI96Ivmu7WTqA32aG/6nTDCtId70B46p4l3U/rsHjS/kzLEGeL0 xZ10PP54fPpKGGG9uj1sOrKb9rI9vvemZz4TeoI3nt1dT0SR5shG8hY98xn/74v9kTmRNZBDHakm JyO1kVryQeSnkf+JZEX6In3ka/R071x6zvVHMINpBA1EBPFPSt4mwlSYHXbBTwQJ2YQBRAAiAfsA +1P74bd2Evvuq3dfHc47uvnuq9Q5lAOUqkrVb98F7lOHgN97031q3bGcVHdqe2pPah3c3U9toNSV 2p86CnwmteHYZOpC6hLIo8BXgS+kbtDr89QtvD8mgbvXgC2QI1NtSMcOHouiPP7dV0dKoJ6Yw5eO JdGabcfyU/3w2+3UCbg2wO9F7746Cr8Efgf5IcjLRzePPeJbczjvmGG7vZj/2NR2fqRjDwK5jz7E r3WCfWbgzlvH/28lcncq7cO36bcV2fRvF4l4jvORbgrB0RkScXR8m3D9T0/9JiGSQFAiuLj9l5hD TiI4dItcSK9Lr4u/tE3pDekNh1TFi7ycbku3hf6ecjLlJE13p7tD02l+f4Co3A4E+fhyAjkC5SId Uh1ShZYZLDeU6rbpc3XcS78Q3Xid9tKHL4PPR9M2Dm3w9fH5eN34vPjXJqYz+r/jueBML/NXYOaf MP+DJDP/k1klR9/6y7f+kpyl40h24DsHVKSQ/k8ACYBY7pzvo/j3QgZPXI6E52G8MAPMONnHTEBZ ifSZJMiRSI7QNSTtryOwvpdnE0HcAK0d/38AKAPPpCe5pGD7e5f3B8k779vftycnv28/3Id0yH/I f/jh4dn3B94fPjx/eP494SE5rR//pc1bzA+YH/x/3s4GvKrqyvv7fN7LzeWCIYkhBAgEKFKGImaQ IkXESBEhRUTMYAYxIgBBQL6/HxqQRkyRQUSMURFTQKBIMaUpMmARkSJSyiBSipZSjBYpMpQiMpRB hiJPBIyQO2v9ziGE2r617fvMc5/zP+v+99prr7325/nIjZT/sv2yMK/Yr4jtdfY649g/E19cqdHb JkJdmohfd5lYyt3iXTPpTU9Zu+lNw8wVxnTcaayOupPMMSYt9S8f7Y7+xbQhWVOyN2UN7VievaPj +o7l8pndcWXHufJZ1HFR9sHsXdmbsjfxXdKyitEoF36rHJtaF7cu7ri046Z200XrYPbBjtUdq7OG ZhW3zmmdk1WcVSxaW1Vuu6btGrWTvePSJ2t51vLsU5d/VK/xB98uHkNFY0frSarXcXbWlNbjW4/P 3icfsYssvJQYWBLfOi7N3odf4oPk3frn/Mk5kXPiYtmBffFraNbQtn1aV0gUVrbt01HqqVIg6zlr Trbuq1P4vxGG/+gQ/EcEO1YZm2ec2HOxBdJ2i2OLTZPYktj3TSz2QuwFE4/9KPYj0zS2IvbvJhF7 KfaSaf6l+7FlrbZO0Opl0jtNK7l+zpRr3Q4ZcmQHcu6e4MhuE/AXuQ7tLx3Zs4Oj8Xc9p2ZfOsLv VpsFZkjmyKxlmT1z78tanbskd0vufbmTcyuztuSWZdXmTs/anrUua1nWslYFuWW523Pvyxwo6dtz twu/Qo5lbbNaDcydlbusbbHYGJm1PbN/7lOZPTMHti1u5WcOzBwoeVdkT2vlZx1ovUDtCLP64pG1 JXO2WNrb+ECv0YFvF4+ekr661fDcLaI7WZgtrQqytshH7GYVioeSX+wGdsS33FlZW9Qv8XSF5F3x 5/zJ2tLmPbWr+cLzavG/Z+v2rUpyd+ZWtm6fK/WUc2UgZy/PrcwszTqgfztnP2svlDb9nv09GefP 289LD3g29qxJic2PzZd+8L3Y96QfVMWqpR+8GHvRtOA/V6Txvymu/JvmNn3/Yagck5jdOvBXoyN5 77BPOOPxH7vMNFYwywxopNfDjJVvaQ16Ort9X3uxzEGUT2ltKE3/e1aU3m3o3S6926d3R+jdTejd MXp3Cr27KZa0DoY6eNShI/7MDf1eQdkBNx2vLbOpEfd26HdjvfV4bfFXuMr9I/FeSLz/fH19bBhs WNiwseFgIyq5Fxj972reF0vHfkrKQrGf+ItRsE25mUMcghboRO2mhlGY3MDZpihsv8Z6Y8MoDAy5 v6d9/lqL/yW/55p1jfz+Ctx6U9Wo1wXc+LD9GnNzwva7yP3jrfdl4v+PtO+fi4JlNphdrP3sBzOW yHFYjmNmSHp5RlaL/IxDeqR3aJGvZ/kcjc9okS9ph4L09LHyWZ9xVKT18hmLzqGWR8ETLU9I2iGO cv1cbvGivSBFLV1mJyvjqJ6D0kQ7KHl9ernWJbYwJrGKLY8tlzqviq3iP5N8yTVIWn3TpX1R+jI5 Vkh9q9P7pKam90lfmb5GSqnm3IdPdXpB+mjhCtI3CbsybRlafdK3SsoOPhc1+7S0W0b1kJTqL1i8 qFWArZVqo2UitDOalJXgrvT3hHtPPrtEb6v279jzsaV/dw07yNFFathJPl3Te6T3uqI0vW9aiXwG puenD2qxV+X0oekjBAelF8mhWvJJOyVMV/1Ijvz0/MwemcrxwVqDxRaDW5y8aI+P2lJLDXZanBTd HqHt4vTx6cWUWpzeK30SNVwUW/k3rBk6UvdKvtXhCOwsnGP1sHqZbfJ98WVsZ6ub6Fn8z61LbBur g1kk30suY9OsLDNTvo+4jI1ZzZmn+13GGss3+r9TujRibXPG9G00M3RuVLe/PsJT7Wr7R6Lxor1C 5rRV9irZQa+2V0vOtfZaic1Ge6OJSGzeNFF7u0Soif2OXSM7uPfs35im9vv2+6aZvc/eZ5rb++39 5gr7kH1IbH5kfySzTVFKkcw2d8kePF324HdL39A9/DzwWfD5L8jzGsnzG8kLGskLQ1nqbg23Rsoe r2tY96vgBlvDhMu8jMu35ArCci/j+lj95dupy7g8q7d8O3AZ19XqwYramOtgdWFFbcxlW3r1s+wy TlvXkrm7MRe3UlmvGnOuFZNvYxpz5rxlN1otAq7W1DVaLQLuhDndaLUIuCPmeKM+cRX9XNvfMHdb zN02c7cjc/cyWfeqZQaP/GlLxKq+0BLzG/HPIS9qJM9v1FrzGsnPfkFe2EhnYaO8CxvZXNiorED+ wWU9IJC1vu35C44MuQoNatzlkrbULrh2VdT1N2Y801L/j1bIXjZ3JbYY02yfGZI4mDiSOB6fkjiV OJM4Lyjn+BT5frCZLWnnm0UFRZZPQjSPNEuLrxXmOJ9QM3Ewvjb4qPwFiw1aakstNbJzJnEkPkUY 0dfvzbLkyGmWo9ho9/Flr4ESVgE1LJV6m8R5Y5pKD4+WB0czqXWzqBwJY5pUBbKmJ2QWT93Q6Ngd HirvuSQ3S7t0kHbODGm6rumKpqubHmi6LjEwZap8W5coSAxP6dl0b9PtTZclRjbd2XSZfPY2XZEY LcfYRInoLpMc8kkMTAxPDJe0vcIFn3V8LrPYYG8ZttTSvot2EgObrpC0FalpggcSpdje3vRwYmrT w/8f9k1fdk08bGUQdf2LIRORIz5cjpFyjA7lsXKUhOdSY5xqOcu8EJ8hh7RMfLYZEh8RL4oXNzkR Hx+fJH1hvJ6bnJDvI+LT5JgSnymo8rR4hWgWxefEOsv3Yj4XNUfEOgcfdP/U4qRARz4zQ0uX7EyK F0nqNNXn+3w5FstH8O+8svm7+mxKmRwLjGkufbN5IvxeGRzN04JD01O2y7FTjho59soh/TjlcCgf k+OkHLXSv3tJ318dnPV7E9mtxOpjp2PnUjrH6lMWRLfLt/qUJSnLorNS2qc0j51IWZGSETsh5/ax 0ymr5ViXslF0T8TO6Uf6xjL5tJdP5+Cj+f/U4kV7YiUjsBTvcNFOyoLY6egs1ReNzilb4JqndEvZ ntLt/7DPRk1w7XhxB6H3AKP1ky+cu3CuPq54YXN9379hNQn+a7e2o87Dbyd7XZyXrWyvTPAbfifB Hp7+qr5J6gpwFJ06v0Jm506eXHdb29y1isqLfFjXe+S5AdbvEaytn0yu5ZpaX621IHVUfSWWRfbP +1obE9F3/I0/HNT/M3egPrhmlJXDqfCLJFeepzuydyNxfLtd/fTaCLaJrFC0N2PnBAwYHaron1b0 JinWtwNvU0zK+mLPjswSzNe/9LOj/rvGuvC5J/sA535HvTX2EyJvdcrVf+esyO+4KTAi+6XKOwed O0Tehc4gdF5A5wPk/3FkBXbizquC5WBf5e1zpJZrKc4LME/AVDoHjeW9gnxQ0Z1C6s3IS51jUsp1 KlvXaSnWIMp6x3kI1Fyvon/Su0vkamcrpShu9V4RfrOi85yWay13/kfkImy29l6SWiSo0av4+aqm 2j9Sf5w8tWBH0X9O7XsPUtbY0IL6luWl6dNucJ/7gOBg9cFNAQ+7nwv+UmW7BNwBP9h7UOuisjcV Zi24W/WdV6nFYnAD/A8V/b3I94L/GXlLLFS7d9DuzaXVNmnrSy/aSn/ogCz9pz7b075v3POKKtvF 0VaC42j92eDmACOvC9YgFys6Rcjdke9HLgFTvc7af8DeAWovkjGichQsUbSmI/8ruEPzWm+pbP4Q WUmvBv1+2tsjC8AoWCM4TzH6I3+91P19/w2pdU1kmlg44hbLuE04SyV1hCv92TupqaYuUiKp1/vP 0c+3CF7l6473tP+U4A6/I/I4xpT6luffKhgNdmmeXLckf+8+LnJ/T8aj1cIvBa8Tph18O+9mwRRX R3FXLTf5qUY1eVz1hTmqqf7H8M8rot9fSzTXKgqzjbL20TqlYEfwEaljUfJOqWOOzjzW/fq3uM7b yZ9oLZIatzn12eBXdIzoWHZq6+VaILpYU/1xSf3/wz2T31Ydvbpp4qtm5Mr62cJ/Uv9b7DwpOJp6 taHcC1quROY6GJ1tricy1xOZ64lMTCMj/aeSeOp8lUEEUohJCq3ZztXf1MsI4oN+hvZS0azRyETa U2uNUoaWIngrcdumMScaGUSjq6/3NtsFkYloq5lgNiMmLZK/ZB57XXmNgOA/SxyOeXPEzifePEbW HEboQWakDows2V27MzRVGOkPzkOKMnLnMDOo/o3od0E+CA7RmdNtrrI7Gs2ZijJjCHqd0ckBhynK 2FTNq2DuwNrXwee8XzP7HWRE/FYZV9eXpM4t1nDmqLj6Yz5UTe9FZ6fOXcrY41TTPknqKW+MpE5Q RvxXnEZdBqIzLrlbdBbpkyW7JvmJjmueWU5XtDdrql2GXIJcgs4CMBXMBzvVax+oRy6k9T8mVz7Y HeyE5TXIC1inunC/c4Kio/89XfxHhytc+2T9Bkl9L6n/p/aoMh5Xr05eoKnro1z199D1lFz1im5b dB7Ch5HmSWyKvj3AfpwVSuYK6z3rV+qbJS1l51i6Uzhny7xqDlqyflmfa6qp1f9Sa6239PlcZ1st fNdo337D+qP2GVt7UQvQ2LrydrVvEJ1bre2CH0gULbuD9Zqu6VYLkdOtt3Sus78qjGMdEDnXOqaM pevmf1m6+t9m6RPOU6yAd1oyou0brLuwo3mH4Emu9YHG06rV+kqkLUeWYJHr1GfrjxIJsa/PKO0n 7N8Lvq9XuvZv8f9O+x3B79ha9zv0tyzt39tvin6Z/XOR77LfYNUWHSehV5T2D21pF/uA/W+CI50n kGWetEc539cWlNhLfW3x2V4u+zHLftr5uuSdYUtd7LuJwC3WYMHr7Ed13paZ6eL9jEXgFnAHuAR8 l3ZsgbyWPnA18gXwNPgHkHsb9hFwJrlqkVeSyt0Qa3jQh5ErkJmxba6upb8pDkQ/uLMR3OeqQ587 VtYo8BB8D/J+CBPlHv3PwAshsjapLLNoH7xVeRAY3Nmh91obkbn34YwF94BF9N7B4BR03kN/r2Jy n2L9NJj7wdFgHjiI1B/jIc+6k59iIQVr3bC/E81SdHrDZzGmuIPj8J+wPe60uEQ+vOvC/RiZPRWP wwR3fC7eH5JaJ9dqHd3mWEbHKcBOL3TmIz8Fvw4d2sKi9d0TlBvsWmlNj7tHDvcnk9i05qK5HX6r ok/reNy3comMc0x317Izo17I59EZijxW5wqnktRNyri9YLa6OloLdbdg1wQYzDyBJthc9+rufVKO IHEOSllKuX2RfXCGkZnWPaPo0Ys8eqlPP3RpL0lV5C6p2yFscdU3Mi8qM0Z3ldSdspJBKcPwaj/y ZOQqnQFk9lDcr5jEZpKYJ/EnSS9Kzgh9U3/q9BrBHazo7ATP6+zqjlCUlUYt03b2jqCUoJXr5QrC jAlRRnc9IzF5OEydTE/Qe1DGYpciLaajSa8gusrIU9/GqFek9kA+jHwATaNzuBkA87bGQZgx4Nto 6v3qoZS1SHWS96G5SHm5vlb5KDiG1A6hD3u1Z6p9KVdxqbXchPcmncVBrHTNSs5InsC+3k2vU29N G7Ug65qudxO1djZ9uN43OtPWytgK75kmaVOf/uzRnx14Z0MwTnX3aJXpTskaHW2ivulIcbjv7TBy 9b/80WoyjuoXM290DmpBicwMScajRF9l5of6yiDy7i80hrqzkh0pu0H2ri3YN74b7MrYdx3QXZPs r/Ru/oHIq8pH9ComGl3MXvo92nEC+7R+7FW4yvAlblYHX+//nPJ/gE0tKxru9/rqdaXfh+vK69ll fcpuTfZyyT3s9K5lX3eBfWMUT4zu/WTndjOa17DTW47cWnOR97jukE1K5Ep2esp8GvjPHs/obkcs aysPUcvJ40HdyXVAfbPHy6wm84b+v3nLi+YJ5oKZXFk3j9rwNnIeVx8GHAOeUk3yZsool1VAGVOn qSIrP0qv64U5BTMGyxXkCvLCcE2RqVcl1jaYbehsQ2dbaOc4/HHk5ciKr6M5Sku3Z+PbSfQf9bTV arE2F6zF2lywllxzwY0wG7n/kE+98rGTHzBY7oRmDzycyz2KryCPCrE3WAPqul+oFkxdEDGZ3dUC PqtsdcXDbeStRa6Fr5XRoDtezXsUvk2wG0++QJ/Zoy0b9Jyk7ljGS3+3rFVJvTtxmrsfbbiXcvrC fpUVzRiYRaSaeu2Hw0ET6AeyjlyRJyPnoKNosLMxvOuimnNhugY8zEbko6E1vfafhXwtqR+A7cCj qmkXknpI50Y7yp2cbVg4pDrCoBl6pann0a8N8oKtmA1YHw3zsPUoOB7+dRDGvHzhpPAfkfoMPLId rJV/DNdlnWeC3cIu5v8V8DeBrEeGNcUEey125vokW/eWut7VD5OVyrpQA670GaEqy+iLIe8GZXeX nA8/KUjVtVV0dC9k/FHIafC6C/2aWra/pozIopl8ilxpbn+RTyjaz3C9/x1611SuKG+TnYX2213i yRHF+mnIO7QfSim7QDyMxpFZU/xaRfrt15QRDK4Nj4DnwP3qQ2ghgbd16oP2Yfs7OhPaUwOEeZi+ fZuvrZyd5P2TJHdLkiNA6p7k2jPJdXpSdheWLXsu3aOq5ez6Lsy0XZRXtGeC43UGk/El6527S+dk 93Vwt6I3EfkRsCvMHeA4Rfu8onM7qeuRP1f0u6CzCn4CeBZ8CFxN6vXIOxQj1yK/CC4FHwavAUuw /CpyT8qdg1ymaO2BuQEd/PE3kloIfxh+PvLLlHsK5gxYSekF8IvIdQ9MDHkUWAFTA94E0wFrPVi/ DAx5vUfhP8LyXPAN+A/QyUGeDf4UZhn6RNtmNfQd+Jno3I9MDP12yDfiQ2eYY8i3oPkE2Bp8E839 4IMwVSARc34HPxlmK8xykFK8DFKDdiEm7iFS2yJPAmdR+s3o01vsnfCU7lbDJ5CnkBfGHQMSMfcx +KvBYdSiOTbrkamXR73cIuQPSaWtPR++lLy0rN9dscknIKkR6h55jdR5aNIiUVoncieyjZ1pILKD t+5KcAAMPdxPR36AvHFSb4N5HLk/fC4yPcEjGvYgmGdgVqC/FobWSd6pIy45WkecrLDXKsq1iFzD 6r04+2ndKbm7Iqk6EsHdit5E5EfArjB3gOMU7fOKzu2krkf+XNHvgs4q+AngWfAhcDWp1yPvUIxc i/wiuBR8GLwGLMHyq8g9KXcOcpmitQfmBnTwx99IaiH8Yfj5yC9T7imYM2Almrt0XpUZJo/ZI49Z Ik9HaFB3Vv/z8IsCD1V278HzGMwosAKmBrwJpgPl9gjqTq6Hgzk8iDDMoiDO2H80iCElfoQ8N4ge mqsVnTfQ/wA+B3l20CLolGHnp6Quo3Ra044SGQd+Jvr3I9NGfjvkG/G8M8wx5FvQfAJsDb6J5n7w QZgqkBZxfgc/GWYrzHKQUrwMUoN2D2J7iNS2yJPAWZR+M/r0RnsnPKW71fAJ5CnkhXHHgEGcH4O/ GhxGLZpjsx6ZennUyy1C/pBU+pLnw5eSl57jdw/6J7G9BuwJFirKzJnH7JfH+pXHapXHSpHHGpHH CpXHGpHHCpXH2pTH6pDHSpTHGpTHbJzHrKKIJxHiHHkNT+bhFb0iSj+J3AkWYOHGIC+pNrWYBiI7 xMpdCQ6AYfz66cgPYCdO6m0wjyP3h89Fpsd6tIU9COYZmBXor4Whb1jfTU40etc0XUeWrvXu6+Bu RW8i8iNgV5g7wHHsCs4rOreTuh75c0W/Czqr4CeAZ8GHwNWkXo+8QzFyLfKL4FLwYfAasATLryL3 pNw5yGXsUvbA3IAO/vgbSS2EPww/H/llyj0FcwaspPQC+EXkugcmhjwKrICpAW+C6YC1Hsjk8h6F +Qibc8E34D9AJwd5NvhTmGXoE2fZe6vPDjx7Le9+ZKLnt0O+kdI7wxxDvgXNJ8DW4Jto7gcfhKkC iZXzO/jJMFthloOU4mWQGrQI0XAPkdoWeRI4i9JvRp9+Yu+Ep3S3Gj6BPIW8MO4YMIjVY/BXg8Oo RXNs1iNTL496uUXIH5JKK3s+fCl5aVO/u2KTT0BSI9Q98hqp89CkRaK0TuROZPa07jQQ2cFbdyU4 AIa+7acjP0DeOKm3wTyO3B8+F5ndskc07EEwz8CsQH8tDK1jr+MJI79CaxfyxHA68gKeQmYgHwGr YBYjF4D5/jO6P/f0PnkqcneuPuZyZfEx1m4Knmx6N3A1PYl7BXqPazmah7jqOeV/S+R6rmLOebnI t+hVGMy4SD64Uv3UaxB7c+RX3HssU/8VnY/Ugl3j36SawfPW4OkqucZFM4w+h1WcHZmpdlS2pgeo jPUYqTVgVaDp36M1RU71N4LDtb6uPq/pDtOddwmOqiz1DVB1epPaSdEp91pqjeDzFUUW3h3h99S7 qdSxIKLPRD5GLtPrKauFr3PgzVoXay9Pe/OpVw3YSRnrMe6WHCK22TC1aM5Gp7vK5mPk/EAmdTNM IZaXw5Qgz8XCIZiV6FSBBaTuCnzQqFrb8O1XtFot7TvMX0jMbyNK2hZXor+Oa8kysLte29rF3DGe GTJq50hQL5hUdGr8JVpHrh/Xhf6Pp6VqwE700kz1SvuDlUlZC5QRzVH0tKHImdT6GSI2Ue/D4FsV PlRR4kqefS+mlHNEoB5cRb3ieNgdC/naXtLb9elYTjhelI+Gcib602k7zfsQcj/kvsG7H94BWgp9 +n8tuJB278TV9Mf+v2jLhuPoGaw9oxFWRsaR4lj0j4S51AcH2UG/K3mXwJfAbANHwZSFo6wzNVV+ DfJy5FJ0jgQR835Of8CC6ngDVPbS8KdcUyUOIrtZKrsz4PuSdzO5apF7g7PxfDExP0dUU4nzdHpX vfdP9K4S5hk8R85GLsDnQnr7LvjNAdLiC5AX0IILuH9Sx29qHw1mMOWdIi3LyVBNkScyuifSahOp +0TGoNo/DnOI2aN3ML7oOaeQ69GMouMGdQGdoPeiswq5U/DmBn1go/of2aGeRAr8P8pM3l798ekb 3ktonlSM0Jf8UkV3O94u1rKcOLU7guXeRCyhFiK8PRLhnRA/M5wta5jfWjHuamA0136sVdBGFczD 4/w/MNb+QJz7EQ2Vr/KfFvursdaTdzPe1PvVdjtPd4n1qmPNUFnmK91z9gafVLT26VpgvYV8E/2q IxHY569kHLUX/C9fn8z2wn6qMjL/Pyryb7xbsaDWRnt6d7qN3vWSuUVH1mltWXet3n11p+hIdPsj +4qeQd7NfdqV4A6YFYrOTh133hyY7eB83oFZDe4Ezysv8dfUpeBg8hbhw1Z8KEderXfknLxAR+/p OXu4J7yG+SGVWb0aZjm+nSLXBr2L62zVe3eSa7uOFPLGNdXaqGPfvU95v6uiOxqdnciH8S0ba1Px qhzcQE1PhjWqoNwE/oB6t1BmgASRVyzhvanBpB4LEN/OU7ofYKDDm1rLeYo3WOdSGeOKvdDfoxg5 qXHza/UJgrWRmKzWOLu98GQa1vbh4WaYrfg5I/Q8QeQTtGYFcVP+v+EH4m0B+lkqezHk/uhnhREI akEbqSyzjaY+FVhWD700fB6BTl8wh7IK0N9GexUGufRJpX9IU/2uMKMpca3KMh6VOawxkTlQ7Z8m Sofhl4KDw7hN1XYkF887vAHeIsE+9Nj55D3ozsC+6vDcwRsTtC89YQ0ezgZpcen/qkntvDZhb1dm epBXc/lLkF/iLnGh+iCztOqfAtcHqZS+gRasDryl1cp52ltNW89A/0DQXu4UemCQulajgbyHO9Jl MPeRK0vRS0PuBvo8S6pVdHLQLySeo/F2rjJ+v+DpM30+gSen0dyMPIzUycg59OR8mGE8fd7PStqJ /nYYnQ2Ml2ptIyn9gLY4NS0PfEMzy+uh1uCPhaUMpr4JnUXVQiRb0euso1ViqHE7QI3mB28eMh4H Y20+s8rIYMxiczFxO0h/6BD0kxDVTg8i0I2WLQk1mZ3AyaSeQa4kVzzwUC03gW9C/49m4C3jxU8w 2xQpRpgH/L3IPKXylzAKOlNiofJNNmGnl1qO2oqRddQrizkwjmYZo6+KWsxQXnwO+u1h9qtpjLIK VsYKZgN9nnuHzpD+HTq/SY99XHSK/U9U0+vDOBLZme63EfyhzntuifuIXrl47+q4dt+WvMTEPq+y 7El0rYmq7CUUnUpFOzUYI0T7JvL29IaIziBf3+VzXVmbnHmeriY3+A/rdS7t9Q5eDcbm7W6B9hze Nza8o2ySzyK30TWRd7FqkroOrkMuC97OAjcrWtPBXYpOBvJG9AvBKrCY1MXkKgjf+1I+H8wGuyua uvBNsIG6nqpspqrsFMH3DlKDvMpbh1S2RsGco/R6+L2B5/p03vkorMVu3UkG76eB2ZpqjuJbORY6 8dywvn4s9sfqbKm8s5VSWoT+s0/QJ/52IW+sHVK0x+n71XYqWAZ2V7RGkforfKulLsOCuJF3F7We is4CMB+vPkbeDPYGq8BOgc1kN+2feJ4TRkx9jhKxOmr9EKmrg7iRa2/YIsqU6PMmeyY+bAPnhrzW ty9yVG1ay6l7bRgf9Xx48J4euJyyhqGzjRLHkvcIzNXoX82b50fRP05qd/gl1KgELEN/F37uUt+s NeiXork86DOht5W6jijjpSkj8ghakGgo42apNXcGvvUN/afdwwhXEv9K4lxJP6kkwooF4DjKqkW/ EKaEXPVBj4WZDRajUxDUAuwOriN1M7iAsuoUnQywCGvLSV0XRkb93Ai/JogDdoqDcsm1GP1zgY7q R3ZovSKMKb892E957yXynlSMRJXxS2GQ3e3EKk6Jeyk9gSZvb0YYZX5mOMb/QE8IInMar07rikO/ PUVvqQhQ+7bMGBWMjumMa67sksyNPAHfC67Bck/G6ZvI7VR2efPTmhGOdC33STCV2aAumBOC2YCy egczQDDeYbqHWE3bKe4j9S34Mn1DyeqI/f8iGr3CHjiQcVqtu25isg+d0dSxTVL3qHfyXLskfMIe 0z1Y+AZOGq1cru+N0Mpv807UNN6S6s/T8/Ywi81IHR36nqq9nzeCOsFXw/Pejl1l2OHjyX78H6WW pc9X6/tCKkvrq7yFEt9TdCajv5ae7/PU/nzwjhCpRZQ4G3kDbw5UBLm0XPsIb1jNpZTp+HNQeb8Z 9Tqiq4DUiF7Ee0rU19mDhTg+8Lab9ATZOTg2uU6iM1aj5PDrRY7DGxTjkDPQ70MEqhQ93lF0yhnL LxC3+eBobM4IRgfv2uWQ6xx+tqfWb4E1wZt4WhcZa9XMbNXkUjsj8LYvWA3airJ/kv2wNZ667+IN tGVYziHvN8I4T6amyrxG6YXUpQK5Ny3yJqUPRB5Bj/oBqdeBR/DnO+APSL2OGu1Fvzu4ktQe4Arw VPi2nsbznKJVr/G0XyFWB9Epg1lFH+sH0z3se0WUq37+GB9qiHNa2N90L8e7ozKyghpVMxepXExZ G2FKyTUA++F7oXgbBV8JLOPhOpB3p2VWn0yEJ9MzJ+vOnxLnkKtALbu89ecyUtwplDJSsQlvpkV5 izXC+yReZ2aemYo+b317p5j/e8C4lJutln3eX5UxWERP3qP7NCKwhhJHE58C3q7pwSgYxTuTHzBq /p2VYgPW9ttNiJja7EmtXwRPh710MnNR0CvU82C8L4Y/SkxOUtN8+HItyxlLuTX0t13IM3WUSd9T nZ0w+xmzvPuaHKpvCSb1v6gHb+LETJX1kvHuLr272OTc83BpiRk+/t7iUjOq5O4pk0zJlPF3TzBP aW+4fVh+joxZk0zq/0w3TUyKucK0ME31m3BRY/G7mM1MqtQ1Id/1LXlNMQ2SzX8dFFvDvjUkR3/1 Sjje6yHNNc0bNC3jmfR77pk42cwEK8A54AKwClw5pmTCOLNu7IRJd5uN4JYJkyZMMdvBnRMefKDE 1IB7RfFucwA8XPLAPSXmGHhy4r1jJphasK5Uki0D8o4qNQ3Qlho1kTNvIenfMF8mueJvkOMKMN4I E40wpRE2a4SxS284SUQvYfMQM0w309P0NQNMgRlhRpmxMh+VmRmmwlSaRabKrDBrzAazxewwu81e 4+sLpmYt0dR3sDn7y2hvK9rP+Pq3A9ER+G5FSwPPozNEz5LzmuDcRFtL/45wu+GvC1O6CEr/TckP z4XBuXlVcE7rGuS7cpOc5XtmavC9ZS/xQey31HVSz0WBHy3HhulTw3qnytGetFR+92OwGWJM9CfR n/Dt/+w3er37pC2bW+3tPGeAW2iyTW/T3wwyw2RUFZv7TKmZZmbJiJhrFptlZqVE+VLcD5oj5oSp Nect14pLkzpNzjQ5G7M4n4vZnD+LOZzrYq6czzY5E/M4n435nM/FIpw/i0U518WaGFtSY/LtnGin cD4bi3M+F2vK+bNYgnNdrJlon4s1l2+fifYVnM/GUjmfi7Xg/FksjXNdLF20P4tlyLc60b6S89lY JudzsZacP4tlca6LtRLtuj+JiP4fp6lm5peKSDY1PxNrHUamTRiZtmFkcsLItJNyzsTah/HJDePS IYxLxzAuncKIfCWMSOcwIleFEekSRuSrRKRrGJF/CiPSLYzI18KIdA8jcjUR6RFG5JowInlhRP45 jEjPMCLX/pWIfHFsXh6RXmFEvh5GpHcYkevCiPQJI/INItI3jMj1YY/pF0bmhjAy/cPI3EiPyQ/j c1MYnwFhXL4ZxmVgGJGbw4gMCiNySxiRwWFEhhCRgjAi3wojMjSMyK1hRIaFEbntb4jIdrPL7DEH +B2N06bOsq1YbHgYkdvDiIwII3JHGJHCMCL/QkRGhhG5M4xIURiRfw0jMiqMyF1EZHQYkbvDiBSH PeaeMDJjwsjcS48ZG8ZnXBif8WF8JoRxeUBrGrsvjMv9YVxKwrhMDOMyKYjL3xyREw0RmRxG5Nth RErDiDwYRmRKGJGHiEhZGJHvhBGZGkbk4TAi08KI/BsRmR5G5JEwIjPCiDwaRmRmGJHHiMisMCKP hxEpDyPyRNhjKsLIPEmPeSqMzNNhZGaHkXkmiIz+Bqn6zRo1X9aAuJmkL0vK7J9tOpnuEq98We0K 47IuRZZGXrIHxx8NpSHxmUg/Fu6xUBoSnyVSFXqPh9KQeDmS6j0RSkP4VawOsp72kvYYLKvpaJnV p8ha+lS8oqGkJxtKeqqhpKcbSprdUNIzDSXNaSjp2YslxReJtCyyVLjvhdKQ+GKkKuGeD6X/l0eV DR59t8GjuQ0ezWvwaH6DR881eLSgwaOFDR4tafDo+w0eLW3w6IUGj2StsrpZ3aRp3ta/P7Tetd5l FU4Y1/2q21X/ewPfP9O/R7PaWjmao2EVz2IVb6G7I7efe2PjX5s1+uQ1Kvx0915d/d2x/F5ctrn0 K6hp6Osv25q/8qu3A2QHkTCZsmvoKt9c55vGts8i3dwgDUJypMyESUPjNKm1pHzKL6id1h24XSvf LPss2pa11LT8YnuYarNaxulWs98c0a2RlWa1sTpbPaw+1gBrqKV3Ot2UMWL3eaR7G6SxFyX71yIt RtrdIL3TINU0SO8ihX7b7+k3+yP9fVn7TWPHf4bObxq09zRI71+Wby/5tgk+a/9ccCE6v22kk2Fv x+ovJA6L5byvwdIHDdL+Buk/G6QDDdLvGqSDDdLvG6RDSBHZw2aaHBnXuo/tY/9SSntByvslpb5g v8Vv1+6Ub1XyfSdslf22sFX2hw22DiPZJmJX2nOlxZbZK0Rzpb3axOw19hrTzF5rv2qa2z+x15tU e4O9SfqSQy9Kk/lEf+dL+1d6+Pu6P5SEH9s/FpvrRd+x/0N/2VZ7tb2AXwHR30/VPi77MeNxpSQ7 EXuJvcS0tpfaS00bsfGGactve1zPb3v04zdQncinkVpbr2gch+KdmKP3K+JOHHui4fy3c8F5Tr+5 e9290rs/cPfraLFGmpeca50cJ8PJdto4nZ2uTjenh9PTmeWUOxXOU85sp9KZ6yxwFjlLnCqn2lnh vOSsdtY4a511zgZnk7PF2ebscHY6u533nL3Ofuegc9g56hx3TjgnnVPOaSfp/tp91/2N+757wD3o dHA/cz93L7hJz/Icz/MiXorXzGvhXem18tp6ud5XvK96X/Ou8a71vu5d533Du967wbvRu8n7pnez d4s3xPuWd6t3m3eHd6d3l3ePN86b4E30vu095D3sPeI96j3mlXtPe89687yF3vPeC94PvRe9Vd7L 3qvea95Pvf/w3vB+7v3C+6X3K+9/2zkPqCiSdY/XTHUNoUgCKkpOSpQechAVEBZZMoiKqGRBySAI YgBJBsSAioiCYADBsIKCIooBEwiCYiaYwYQiBkTw9ZRh3b3et++c997dc8+5M4fuqq7ub6q76v+r 76vm1GXUhJrRVdSKbqBb6A7qQPfQA/QRDXHYHH6BcuyOPfB0vAPvwiV4H/4NH8ZHcQ0+hevweXwR 1+MmfBXfwHdwB36An+BnuAe/we/xAP7MPHI+IQEh3irnxZAf8jNtIQ/lmbZQhsqADVUh4ztCTagJ OFAbagM+yIVcwA8NoAEQgEkwCQjC5XA5wDAVpgIhmA7TgTBcAVcAEZgJM4EozIJZQAxuYNpyGNwI NwJxuAVuARJwG9zG0GYH3AGGw11wFxgBS2AJGAlLYSmQgvvgPjAKHoAHwGiyOoc0PAwPAxl4FB4F srAG1gA5eAqeAvKwDtYBBXgRXgSK8DK8DJRgM2wGyrAVtgIVeAveAqqwDbaBMfAevAfGwkfwEVBj elc3UIfP4DOgAV/AF0AT9sAeoAVfw9dAm+l5g2Ac1UA1AB3qCnUF0FQL1QK41DXqGtCl7lB3gB7V RrUBfaqP6gMG1AfqAzCkPlIfgRH1ifoEjKkhagiYIJ4oTBEbsYEZohAFxiMO4gBzJIgEwQQkgkTA RCSOxMEkNAKNABZoNBoNLJEckgNWSAkpgcloDBoDrJEG0gA2aBwaB35BukgX2CJDZAimIGNkDOyQ KTIFv6LxaDywRxPQBOCAJqFJwBFZIkvghCajycAZ2SAb4IJskS1wRXbIDrghe2QP3JEjcgRTkTNy Bh7IFbmCacgDeYDpyBN5ghloNpoNPJEv8gUzUSAKBF4oCAWBWSgEhYDZKAJFgDkoBsUAb7QQLQQ+ KBElAl+0BC0BfmgZWgb8mf6dAgJQBsoAgWg1Wg3morVoLQhC2SgbBKMclAPmoTyUB+ajAlQAQtBO tBOEomJUDMJQGSoD4eggOggiUAWqAJGoClWBKHQcHQfR6AQ6AWLQaXQaLEBn0VkQiy6gCyAOXUKX wELUgBpAPGpEjSABXUFXwCLUglpAIrqGroHF6Dq6Dpagm+gmWIpuo9tgGWpH7SAJdaJOkIzuo/tg OepH/SAFDaJBkMphcVggjcPH4QPpAocEDoEM7IbdwAo8FU8FK/EMPAOs4q27BFbjnXgnyMTFuBis wWW4DGThg/ggWIsrcAVYh6twFViPj+PjYAOuxbUgG5/FZ8FGfA6fA5vwBXwBbMaX8CWQgxtxI9iC W3ALyMXX8XWwFd/Gt0EebsftYBu+j++D7fgxfgzy8VP8FBTgl/gl2IF7cS8oxO/wO1CEP+KPYCce wkNglxBbiA12C3GEOGCPEL8QPygWEmSC7xKyZl80VIKSkA+OghqQhvqwD66G62EOzIMFcCcshhWw Ch6HtfAsvAAb4BV4Dd6Ed2EnfAi7GGY+Z67so5pgF3WTsbAKCSBhNAwNR6OQLFJEqkgdaSMuMkBT 0Qw0C/mgAKYfzUfhKBrFoUWMLUm0HKWjVSgLbUCb0VaUj4rQHlSKDqByVImqqSZ0Ciqh8+guEoaK 6BMHcCiUhT1xEd6DS/EBXI4rcTU+ic/gy7gZt+JbuA3fw49wN36BX+O3uB8PCrGEkBBvxa9IQjZA yMYiZGMTpiHCNA5hGh9hFz+hlgDhlSDhFSa8EiK8Eia8EiFcEiVcEiNcGka4JE64JEG4JEm4NJxw aQTh0kjCJSnCpVGES6MJl6QJl2QIl2QJl+QIkeQJkRQIixQJf5TIeKhMyKNCqKJKqDKGUGUsoYoa oYo6oYoGoYomoYoWoYo2oco4QhUdQhWaUIVLCKBLCKBHCKBPCGBACGBICGBECGBMCGBCCGBKCGBG CDCeEMCcEGACIcBEQoBJhAAWhACWhABWhACTCQGsCQFsCAF+IQSwJQSYQghgRwjwKyGAPSGAAyGA IyGAEyGAMyGAC9GyK1GxG1GxO1HxVKJiD6LiaUS/04lmZxDNehLNziSa9SKanUU0O5todg7RrDfR rA/RrC9RqB9RqD9RaABRaCBR6Fyi0CCi0GCi0HlEofOJQkOIQkOJQsOIQsOJQiOIQiOJKqO+qlIR joTDIAeqQx2oRxXDVXAd3Ay3wnxYBPfAclgJq+FJpq/VwXrYBK/CG/AO7IAP4BNe72GufEM1wifU DcbCKsSPhJAYkkRSSAYpIBWkhrQQjfSRO5qOvJA38mfadh4KQ1EoFiUwtkaiZJSGVqI1aD3ahHLR dlSIdqO9aD86hI6gY1QjqmXUeI5RpRCzH0CfORCtwdNwId6N9+L9+BA+go/hE/g0bsBX8DV8E9/F nfgh7sLP8Svchz/gT0JAiBIS+o8q/6PKfxNVsoAdmYEZA/TJWxoxHM7Ezh3MSPj0W4rpAbxINoLJ vWGikDZynghcynjQTNmXPXxKoh6ebwyIl8tiruzgxfMsDmNdjomkv0XQl8A10A66QC/4ROZ8pJhS FaDBxGlMfAiZuJyJed4z2xTYz2wz4ACzXSNQxURM/XyPme0AXxezHeRjfpH6/BML74iFD8TCR2Lh E7FwlFh4Qix0EwvPiAXm3vie884gqRffUy+/p3q+p159T73+nur9nnrzLSW0/Xsqn6SYJ8Z7kgAw tGHiToY4BwDFUKcccBjyVAJ+hhqIrJkrDr6sEkmxmZoy8S0LsNgFX2JH0Cr4m+DBn7whEWTuI5da 9cOsixhAVBy1kIqnEqhFP8yq8FobMaW8eRNDErUyrcOuJ5Fvw/dZgoe8FXBJ6tH31ONvKYFK3tn/ bST95Q0j68vbHgCkU8jcDvlIJ9LJ0gs5AhpptmnvhVl87IJk6WDmUACbxeJiWoCDNEUgezQCtA9H UJPDoljJRmwWVeBGu9BaPxyRKZRbJgPGk68T8AXRIByEgAAQw/xN4H1pxR+MUZJZFjmiJTvXXnJg 71Gqm7hl7efujTsLkkf8QidT4nQy+2MBZLPYbFFwCqwaPz5jWPOEd37POybRwt9ryqKYOkVwNWl1 DpxKYQklq/CI+KjguUExCmp+6gpcExMjBYdgv6jw6PDAGAWr8KiIcVw5WubLycP/WBIe5RMTHB7G VaTleeVQQur3ctfw8BgFiwUxQeFRwTHxtNxIYRMjmsulaSOa+XiOFNalubp63K/Zv6FGySylHx8L CwGYzBIFzHFBdjKLBUrYNaciHpv1Okqr5W9eOJt+WliSqTrnw9BG+6LKoW2FChMSXQq3FmZ5685v tvSPf1kWe9H9du+zvDSZrPyUwPK6+Qm+ytdlx7eLstZ3bTp7UjswNzdozJYrplonhQ5PH3PK5ong BONNWiVqJsXPpyy3fJAiWp0bMtWnLDlxh7d2nH33lgp/s1xnGS6/imR+yZN1mlKPzXP8JL2no4B8 WSPX9Pd7erLZ56SvnpxqXb5i2UnT5+7ZjvsH9ySExjgekGrYJKCmCKat9Q42qv5VnG+8x+eZAzsD Bfl3tyR5TOs5YjZ7RFIcdfvdif3LNg4dvLz0+p7RUV7jLx1/xV+kRJdzUi+WK8RJpHaweevIFyUV 00m76KRC5mnKsqikXDpp8zKxmVcieoKjtiu7LJE85LDmc/2OqH99+yX/RR+HvDbc2IVrM99sljJ4 UcVSuRk37I2Xt27+dlw/Aa3LyLpo+lix99W0DVqHC3654Nvz6UaDmZlniaF78JBK6MSLDXvbUWIb N9M8XyxiXvWQuJNUcO2nK1YPhnkqOD31XXRg76gLmkaq2icCdoivVBX1K3rvLtOvePH68DeuZWFW unyDySM/PJobIuzyrua16/maJ2fpTwpcgQzZjeqjHVpl2bteL+uEFTP7fmu7MO1lwJTzru5HKqCa +Oe111/xZy2p2lxXaqT1MOFhcdyD2AJwZd7EUy2GKzstxIsN5knPu2Nw75oM9bDYmrrgqWcc5iAj 7FspWLj6aqv7RJvLMlN3R9wRN03fsCB/T0sBQwVvOhnaf6GC4LjSYXedP3ttq6/9xhTZvwsGjO6N dZkPQwBdBgZcXSZr8A0G8YSgjBGOBHuqG1eCHsbL8EsITvOJDgoOmxvD/IwYLcI7yCfB5xrgHxoe 5v+tYoL/rGLKtOKXio3+sdw/QMEteG4YY1XB2criL6lQGb/4+qxya5Ni/TLu7X5VgylxtQPy289b R/Y023RdW31mvr2rb98W9hmHm1NCdFQmBJxsVK7EtpVLF7RZ1+zNEnGuU9XsLXgirCzfbKHy0XdL 0yjrXRvs5LdcLtdROmOnnRh+a7ic2WoTMZO2GvW+QDNtlu7nobG2uw+HsNLzBo4d8lua3O9VkJSS uuZgb1V2UZPxbufUkWPTHdvod8C871y/edKJtBchJnvG6b+rGHdAcLHvuoWBeTnRwmkHes++UTjq JJ7pV691S9d61Mtqu01mzm5SjYEu8Xv3pV/wmJCf7JwRhn4zOLVIpcY10HyLY4PmEr2wlF84zduv 2KWxw9LAztr0DrevVPhIJ72nJXhQUKWEaEEOPzOgIcQH4b8HKkR5dZRgsT5TiIbMjpblHRChRlCS DbKNsSBi5oHXt8865rpMHlc02e8VjXnFohTFyCjtB+kQxiwq3b/Ebkxv43HHmMLpY2M0FpSnDZba Zy8EDt2XnkndDa4TKUx8w7Y6dym94YNbw+n8Go/wV36TSyaDl5su5LbKVOH8UcLZN27L7VNf3PNi d3RZVrvJGvOceceNQ1syDigPdnRfDxZYl1EzdA9U6795n9gvJj4OPVPftMFyvlpkpXFWJ5/wxVlB l2uWWcwPLK6urF6jf6kXiiUmvG3ptOxYNHTvXtnQu45W4fKI6+sfOB0xLkzUvmZ+Rx/7GrHzk+Yp r3jn5Zd10LPa5Ib36qkpo/XemuUUJAsVzllVrlW5Y1d96W2FIyfpUakKksIax137LDpn0w/WqwWn n4q4/2ZPaeMyy6hYEYYxCQxjfL8yxoczNol4SPw/6ggxnPkbVc0DjjFDGl1drq6+gQEPODTjfjBZ PV6WTlr+/1I3YdJxmK5LOTg5u347Hf6T0/+SPTVRFSueyOSnno+p8vaChuZ5g1sSctVtlA7uSXd7 8dLG9PxMhKcVV15CDVft436JSC1/VN8x90nRYMzYDXPzb6yEk+lz7y8eu2gqy+8x2Wkkv3B/xaig vSoyA2haanedI5+i0Z5njVo6RywvK6I91x9fVZt2XjqhUd2Q7/L2qQ3Vr5WeFSvvFFY/PXDljOcE P/PzWlPwovjUVxk9kTVWng+KyoXfTB1Q7byvcPVJ7uzsXXraakunSU+dJ6Q7uScwJPyVcV4Pe1/u jrYcPjGR8VLB9+MdbSQ7j66+siA0rwzkaVu+dany7Ftovbx7XKJm9azLo3zU9mVbCdbNs/x8WHf/ TnWl9hFdV7+y5wOd9Pbn7PldxcrN0Rr2NQOPFD9Gym0Z3jyy/+zulaT5ZEV5qmeEzLeMcENWmZKi Ryz7uewn806Qp8xpM9qkwKjAIE0vKCYmwlRHxy8qZFzotzYc5xceqhMxP5h3VCciKtx/gV9MtI6V G9PxxjGHaNtvNWT8kvG0KW38LU+z07S+GoyLi/uZwYCoHyzF/ElQhD5W6k1+NSEPokPPbLkRKpRh ds42OkG1Ueu+0aJt+vk1yo0nOm56xQ+bL+GiwPI7GvWe/8G5xS4aI9SuNT/ZqtEkJdwiEblO/blH Tf/1OmGdAwHaoQ7W6h5RKU4TW+bJWviWxHuteXU+bmU9W23ctvN5mo+Oagi0Pd98/1FC5myxDLcd bd5OcTmR3sUzTdZdLRWXR91nrEuunnY5eqDq7idOCuiLKbrzuUG2QBnxPRxrcHrz2lF7k73Hdg2k aMo1U/VrmpKFbxQ7WE1a0NLeFtez0mu+aLp/VsWxymOlc90VrffaBT1xn71K0mvuwudrvaDYOv5t KgqbuzrAsIiS/kNREZX775/OH8Fm6LONoU/qF/qIzcNbnGqBaumwO9by0xPmFv6ZQX+Pr2NIm3AN aS6tr2/EQ48Jk/0bfB334NCA6Bif0Ij/qa9z1yhs4MAFS7tIqQuNthPcaj+WSh7T0q0Wd3K9sPzF BL1bU7jr1Y6s8++Ud045dvrX5qXoQ8+CE6vOF7fuD44IXDg2sOtIZU/q0csv9w6K78QzlNR1mibd 8qCkYw+H+ofaud9pe91+Mn/5+WUdS+3ZRtlva7fze8gF/XL5Vm2sl87iI6pUhcfMeTJ+n5cljn/Z Sqk6mMTF8M067XUzzUhrwUWRp3ImAomxQ9tCwhI6n0/I2rw9UmSOhpOUr7fu9pbljppKXkHWq9p1 UsScD/UfHp0Z8lJ1q8SHerEbqSJ9ybHRhuc2JhQ2eHOeo4NpepUfsmemWKRMT80OOyivZdsQnmfV Oa9r6Zg187/wJpmlxjwRlZ8Rh//fw9sR4wh8nW8YzuK5MOAHUIZ3OU7cfFS/9Ne0rON5T8vMLKzO XaFHfb9Akk0JyQkCN7AA+AIrYPFHT+gf3KifACrbYRj3dKJz9bA1O3z4WCKrI6wze6LdayYKIO3P VS5uqTIvTNZVFnng9tVHzKSbB8r2XKz8zUVROpw/eMl8WKhk8yKkIjRRqcrmasqbTNETfCsNTz1b 0h0xyzp/fUtDY9ua2nsnNS4nPr+4X7c1/Wi931nDZinFk7HtZrnl0tHbFTNuVlSIu6/uyzsdYJer NibPe6Wo2XmJgIW21U37lps6HfSd3k53d5vIPljRe9skqV9CcbX/Mj8Otak3l22ls8gm49hn9q2A frv22zBmQzkKE2rYdlfNJ9H29ci8YYrGbJn0Mk7dJt2qR5POuZnXlKxo7wo0yuxT2pTXcDDO3cX0 etTkQ8rvGEDtZQC1/rt7lK1N3COBv889+gcQEPeINtI1YNCkyyWM0vuS5fKydFL5v8I9GkurfsnK hVkFRwQFRClMdrNWsHZzNDWyMNbVNjQ2ttA2sTHR5arSyl/uSeaP96TtxrspBbeAqNhgv4C/xNvG JEEFSymXhFsbX2wdvJvePCCSJfF0r5GaeOyQg3Np7GaNDb90lngEsx9lL3FIvbM0smcBuFNtFTIQ Xhb5SrM5cX1j9shtO+qO9b9f0uZzT5uWyxujHTvxsc2mNftvrjC62dDzpmnmmU9Bnb3+WVu7zoj3 F51I+XR9VSMyr2HFOo+FH1IqR6Rlep+Ypa41vmnXYI6ngazTiFrjm3I+E80Nyz0kh8dtNBP7CA5u uD/LqHRstZ+WrWTS1AchT0s0N2ZmiCwpArviVPhyNCJglYbK2tz2ukKlX0/az+DEuUdZHZzg37Yh hX/6kaHu9CkChuXlH/RKltgXxi/VnaEusv3w287x2yc+tzH70Z36HQhqGzNOss2e3c4+tthG9GN9 35Jtn5v/4Cn9lBj/G08pJjrCz+f/xFP6Zinm57D+g//Hqf0ZrcDLsk/3WzICL6k/8Dx6GSQvGelV pzJDvLr4/fwb6UOZ9Ydj5aWV3r2/d6niqAVrtNE+W6NNER8b9Paora7CR2Ik1CrLF9zTELi/yqkj Z+LmSn3xpKdibbJ3j/k3OTqb2a8cHNWmur91U/rTX88+etVvMXIW69m0jMWxCY/Ch9IVyjbkrc49 OWd0wXBapbNwic86WXX1M1PWmlotX/GyvXV5m5OWgdkTCwvWXiCEe69PkW60zFx08I125iz1eycy l64bHlvhPSA5dm+4uJ+l2nTTlWarJj2srGtYP03GxmN+Vv16Bw8ELn2gJ1k7dozKqHkr9qptdIea XIVLb1znmAfVAknid+VMr1hzk6kihlj5bBaLTkr/G0O2PwSSv0+AFyQ10pLfRyc1FpcPIvIfarwx 62tjCkCu0I9z7kxtfs9hrgj9Y+lwhiXfL6S4jADsY84IueyfVLzZi69FjT+6vnFm5Sl6xZd5UBNX GMABhUIUg6BSpcjKTFIuzSZ7csoRQKuYSKyKEQUlUTThiMGAKFZtS0URVCxSUDwrlAIixANiU8FB QEmhiFKhoKIWRTkriBhoirZ22DfTvzrdndl9+5tv932/t7vv231NTzeOfrGx2aC15Kprj76X7u+U E294n2bw42rxicmhsqWulU6CoXPuONPDdntEGo/LV5VnG/syij0151SW0euTuKdryzJfTdzqP/u7 EJPEDN7io8I3EaPJVXckmaqq29FHCHmXdECGtxCBIb8YPq5JP8YqP0N/kenRsbNblNphf1abkkcQ vwdI2BZEydHouoZsKwvFtvzedsU+9+Cae5afdJRY1fx0sEX/YYMPU+HHoze77HzavD2zqPfu8QM2 O/pfnqjeXdUzlOA8ZV+2cc3cjGqt3ZH4m4rHaZcKhwNuFU4paCJim+rsmOcfesoTsxWTta/vSK37 V3iY3M6vHKHnO9I+WPcmpalbMbAp6WpY0Omg3tfrax89nFnGmC8PsHS8s6bR/XrpacWZUkFCXuDy b0aL87o7h/Gs+nmmZjH7l7k0lkU1ivr7rKslcS4Zc7XxZVGXqyVznpiNqlXCkbicNxV6mkGlcMat U2cTnu94NXjX2+kJoU6HCuyQur4vV7qvWtHGT+kdGW0ZWlOktFmw/4V1TZwyT+lZfePkRdcl/bys hzEHq3IfnHLvGgj3Tzsu3pWziHFo6gFiUenXM1pndXRqmy76V9yf/NuAkatvfVAuUt6d5kDPHrlu pbIYQJ0m/SxIiUwdrL/Ly85cmxDd9Wlz+ASvw5rLzLgFyUkW09KNChOGzzjWqwtifPIHTpXUO0Q2 SKRDTZvxllJO9bW+S3XeGY1JzFzOFqbU/GRbdbDlR2rptfLplT/YDu+M/9AJXvT8W0WDQ1vYy7Lh ZaUMZlfL1F97xZpHF+xj7B1vTWs3n1UYbGJj0c4oY8drhFpl76TB+Ijo4qODcxLW3VSuFaa3zyxq dqCnbcaPaZQWwRXznz+rzdMW39uQktOqaB0R1FxZ+HEbrTM9PS1878SAvDVdV56q9SZ1mK0ypYki wrbIZaJQ6Vgzct0mUxqBQTA01nJzYy2LixKxVgaKxCxB+DYRRGCsFUKIDaEQJxhiBUZGynUHMBTI WhghjoQ479pcoZuXD4LAfiTXmUARHwwlvP24JAmjXC7hjfniBMfj3yN0HfiFS+QiGctPEioXcUXr I8NErMWiiA3yjRAHdvbwMKX9lXtsFlbnusQg2uxGb5Anf3mIIs7ECaI/rt82wVFI1xs83+NUyTdL znef/sDg+iEzXshJ613z1awl7OzF7MMZ7C1FbfHzEsX+xx8IYtfaDuupy0dnXLE8qLb8Qv97bg+z fO9Xs0MnuC7Nqkix0+7tS8xRZTJazKVW5cZGZj6zDqV+JmhrCsjVjDjSNZChR5aP0YUo/TmP7pvT UhP1HPifG9fwdxut9pr+jL+H2eJpc69u95TVPvTSqM4DBepne5INJb6qabXKKJ7LBdUee7cMa73Y fFt94J2JlYnEpjQYInDd9t3C4UA4hiEYJH7P2AQ0toci/mZsDkZlJJvCUILCODjCoTASplwPgVGE wlCSkguCYzCFkYTzeIbqVgrj4JR+URSlMpykXo9EKG4oiVMYBlPjMDbVF0NwnMIwlKQwEqaMn24E Eep946AAhgEYDmAEgJEA5kxlCAxgbAADPGsIwAMBeCAADwTggQA8EIAHAvBAAR4owAMFeKAADxTg gQI8UIAHCvBAAR4owAMDeGAADwzggQE8MIAHBvDAAB4YwAMDeGAADxzggQM8cIAHDvDAAR44wAOm 9IuT1DmRYMMolSHUOMB7TuCAOGdkfBymO3n8PKRj5Pj5AINJeHwcSaD/7FcuCw2XiGRjRfltKcb/ 8/r7tsKGyuRvCw9JkH9WHgbDl+f3vhjB/09uLL5MtBUaS2ns+0Qgl0JjQzY+aWfdk/Au6T8AUEsB AhQAFAAAAAgArmpQQFnTe5PXtgMAOVAEAEcAAAAAAAAAAAAgAAAAAAAAAFtUYW5dIFdTRCByZWd1 bGF0b3J5IHJlcXVpcmVtZW50cyAyMDEyMDIwMyAodXBkYXRlZCAyMDEyMDIxNiBDTEVBTikucGRm UEsBAhQAFAAAAAgAK31lQMrp8x5iSgEAhF4BAE8AAAAAAAAAAAAgAAAAPLcDAFNFNDMoMTIpSW5m bzAzX0RyYWZ0IFVLIHJlZ3VsYXRvcnkgcmVxdWlyZW1lbnRzIGZvciBXU0QgaW4gdGhlIFVIRiBU ViBiYW5kcy5wZGZQSwUGAAAAAAIAAgDyAAAACwIFAAAA --_002_9983D74B649EED43B27BF353837B20C57D942DE4WOKINTRAEXC02in_-- From Gabor.Bajko@nokia.com Mon Mar 5 11:46:02 2012 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 45C6521F8888 for ; Mon, 5 Mar 2012 11:46:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.367 X-Spam-Level: X-Spam-Status: No, score=-4.367 tagged_above=-999 required=5 tests=[AWL=2.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 yD+qxEu1o8Wt for ; Mon, 5 Mar 2012 11:46:00 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 8BACB21F878A for ; Mon, 5 Mar 2012 11:45:58 -0800 (PST) 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 q25JjvxG010613 for ; Mon, 5 Mar 2012 21:45:57 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Mar 2012 21:45:57 +0200 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.157]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0355.003; Mon, 5 Mar 2012 20:45:56 +0100 From: To: Thread-Topic: WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03 Thread-Index: Acz7CHkh/FNx3kOiQQWaHcNbcyzaWw== Date: Mon, 5 Mar 2012 19:45:56 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601E1A52E@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.21.95.63] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47601E1A52E008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 05 Mar 2012 19:45:57.0377 (UTC) FILETIME=[95858F10:01CCFB08] X-Nokia-AV: Clean Subject: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03 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, 05 Mar 2012 19:46:02 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601E1A52E008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The authors of the use cases and requirements draft have just posted a new = version of the draft and indicated that there are no unresolved comments/is= sues they are aware of. Therefore, I'd like to initiate a WG Last Call for comments on http://www.i= etf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rqmts-03.txt Please review the draft and send your comments to the list by March 20th, 2= 012. If you review the draft and have no comments, send a note to the list that = the draft is good as it is, we need these notes as much as we need the actu= al comments. Thanks, Gabor --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601E1A52E008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The authors of the use cases and requirements dra= ft have just posted a new version of the draft and indicated that there are= no unresolved comments/issues they are aware of.

 

Therefore, I'd like t= o initiate a WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-r= qmts-03.txt

 

Please review the dra= ft and send your comments to the list by March 20th, 2012.

 

If you review the dra= ft and have no comments, send a note to the list that the draft is good as = it is, we need these notes as much as we need the actual comments.

 

Thanks, Gabor

 

--_000_1ECAFF543A2FED4EA2BEB6CACE08E47601E1A52E008AM1MPN1006mg_-- From Gabor.Bajko@nokia.com Mon Mar 5 21:40:34 2012 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 9313121E8047 for ; Mon, 5 Mar 2012 21:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.731 X-Spam-Level: X-Spam-Status: No, score=-4.731 tagged_above=-999 required=5 tests=[AWL=1.867, 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 Ooj1FeMBqoYH for ; Mon, 5 Mar 2012 21:40:32 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 979F921E8045 for ; Mon, 5 Mar 2012 21:40:30 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q265eOT2010394 for ; Tue, 6 Mar 2012 07:40:27 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.23]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Mar 2012 07:40:26 +0200 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.157]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.01.0355.003; Tue, 6 Mar 2012 06:40:25 +0100 From: To: Thread-Topic: slot requests for the Paris meeting Thread-Index: Acz7WwFLehKRZsaWRP6fiyY2J+USAw== Date: Tue, 6 Mar 2012 05:40:25 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601E1A7D2@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.21.95.63] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47601E1A7D2008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 06 Mar 2012 05:40:26.0428 (UTC) FILETIME=[A1EECFC0:01CCFB5B] X-Nokia-AV: Clean Subject: [paws] slot requests for the Paris 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: Tue, 06 Mar 2012 05:40:34 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601E1A7D2008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Everyone, The Paris IETF meeting agenda has been published, see: https://datatracker.= ietf.org/meeting/83/agenda.html PAWS got a 2.5 hour slot on Wednesday morning 9:00am to 11:30am. If you'd like to present, please send slot requests to the chairs. - Gabor --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601E1A7D2008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Everyone,

 

The Paris IETF meeting agenda has been published,= see: https://datatracker.ietf.org/meeting/83/agenda.html

PAWS got a 2.5 hour slot on Wednesday morning 9:0= 0am to 11:30am.

If you'd like to present, please send slot reques= ts to the chairs.

 

-     &= nbsp;    Gabor

--_000_1ECAFF543A2FED4EA2BEB6CACE08E47601E1A7D2008AM1MPN1006mg_-- From andy.sago@bt.com Tue Mar 6 07:42:30 2012 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 3B75821F89A4 for ; Tue, 6 Mar 2012 07:42:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.841 X-Spam-Level: X-Spam-Status: No, score=-1.841 tagged_above=-999 required=5 tests=[AWL=-0.920, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, 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 4HB4nEUZMnFP for ; Tue, 6 Mar 2012 07:42:28 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 90D7221F885E for ; Tue, 6 Mar 2012 07:42:27 -0800 (PST) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 6 Mar 2012 15:42:26 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.196]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Tue, 6 Mar 2012 15:42:26 +0000 From: To: , Date: Tue, 6 Mar 2012 15:42:25 +0000 Thread-Topic: WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting Thread-Index: Acz7r7czsJW4r5ouRdyl+vO7M9pCcA== Message-ID: <619CDADDCCD2B44380834BE8BF6F71414069146000@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_619CDADDCCD2B44380834BE8BF6F71414069146000EMV62UKRDdoma_" MIME-Version: 1.0 Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 15:42:30 -0000 --_000_619CDADDCCD2B44380834BE8BF6F71414069146000EMV62UKRDdoma_ Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable All Comparing the draft with the Ofcom requirements at http://www.cept.org/Docu= ments/se-43/4161/SE43(12)Info03_Draft-UK-regulatory-requirements-for-white-= space-devices-in-the-UHF-TV-band, I believe the WG draft is deficient in th= e area of reporting frequencies and powers actually used by masters and sla= ves (Ofcom requirements 3.18 and 3.19.8). Ofcom intends to collect this dat= a to assesses the impact of aggregate interference into other services. It = would also provide usage information (frequency in use) that would inform t= he operation of a kill switch capability. I suggest this deficiency can be = remedied with the following changes: New P requirements (probably best placed following P.12): P.12bis: The protocol MUST support a channel usage message from the slave d= evice to the master device. The channel usage message MUST include paramet= ers as required by local regulatory requirement. These parameters MAY incl= ude device ID, manufacturer's serial number, channel usage and power level = information. P.12ter: The protocol MUST support a channel usage message from the master = device to the database. The channel usage message MUST include parameters = as required by local regulatory requirement for the master and its associat= ed slaves. These parameters MAY include device ID, manufacturer's serial n= umber, channel usage and power level information. P.12qua: The protocol MUST support a channel usage message acknowledgement. New O requirements (probably best placed following O13): O.13bis: According to local regulatory policy, after connecting to a maste= r device's radio network a slave device MAY inform the master device of the= actual channel usage. The slave MUST include parameters required by local = regulatory policy, e.g. device ID, manufacturer's serial number, channel us= age and power level information. O.13ter: According to local regulatory policy, a master device MAY inform = the database of the actual channel usage of the master and its slaves. The = master MUST include parameters required by local regulatory policy, e.g. de= vice ID, manufacturer's serial number, channel usage and power level inform= ation of the master and its slaves. New steps could be introduced into one or more use cases to cover these Ofc= om requirements, e.g. new steps 6bis and 9bis in the hotspot use case at 4.= 2.1: 6bis. Prior to initiating transmission, if required by local regulation, th= e master/AP informs the database of the channel and power level it has chos= en. This is repeated for each slave that associated with the master. 9bis. Prior to initiating transmission, if required by local regulation, th= e slave informs the master/AP of the channel and power level it has chosen,= and the master/AP relays this information to the database. - end of new text - For information, for those not accessing the url in the first paragraph of = this email, the full Ofcom requirements leading to this new PAWS text are a= s follows: 3.18 After receiving instructions from a WSDB in relation to the maximum pe= rmitted EIRPs over the DTT channels, and prior to initiating transmissions = within the UHF TV band, a master WSD must communicate to the WSDB the follo= wing information: 3.18.1 The lower and upper frequency boundaries13 of the in-block emissions= of the master WSD, and those of the in-block emissions of its associated s= laves. A lower frequency will be specified as (470 + 8k + 0.2n) MHz, with t= he corresponding upper frequency specified as (470 + 8k + 0.2m) MHz, where = 0 =98 k =98 39, 0 =98 n =98 39, 1 =98 m =98 40, and n < m. 3.18.2 The maximum in-block EIRP spectral densities (in dBm/(0.2 MHz)) that= the master WSD, and its associated slaves, actually radiate between each r= eported lower frequency boundary and its corresponding upper frequency boun= dary. Footnote 13 states: The use of upper and lower frequency boundaries (defined over a 200 kHz ras= ter) allows a WSDB to collect more granular information with regards to the= usage of the frequency resource by narrowband WSD technologies. The upper = and lower frequencies of a boundary pair do not straddle a DTT channel boun= dary. Note that a WSD may transmit over multiple, non-contiguous, whole DTT= channels or fractions of DTT channels. 3.19 A master WSD must be able to receive the following information14 from = a WSDB: 3.19.8 [An acknowledgement from the WSDB, in the context of 3.18, that = the reported information on the DTT channels and EIRP spectral densities ac= tually used by the master and slave WSDs were received successfully by the = WSDB18]. Footnote 14 states: 14 While the communication of some of this information from a WSDB to a mas= ter WSD is optional, master WSDs must be able to receive and interpret thes= e. Footnote 18 states: 18 This forms part of a handshake protocol and may be an area where industr= y could harmonise without the need for an explicit requirement in the regul= ations. Regards Andy From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gab= or.Bajko@nokia.com Sent: 05 March 2012 19:46 To: paws@ietf.org Subject: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03 The authors of the use cases and requirements draft have just posted a new = version of the draft and indicated that there are no unresolved comments/is= sues they are aware of. Therefore, I'd like to initiate a WG Last Call for comments on http://www.i= etf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rqmts-03.txt Please review the draft and send your comments to the list by March 20th, 2= 012. If you review the draft and have no comments, send a note to the list that = the draft is good as it is, we need these notes as much as we need the actu= al comments. Thanks, Gabor --_000_619CDADDCCD2B44380834BE8BF6F71414069146000EMV62UKRDdoma_ Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable

All

 

Compa= ring the draft with the Ofcom requirements at http://www.cept.org/Document= s/se-43/4161/SE43(12)Info03_Draft-UK-regulatory-requirements-for-white-spac= e-devices-in-the-UHF-TV-band, I believe the WG draft is deficient in the area of reporting frequenc= ies and powers actually used by masters and slaves (Ofcom requirements 3.18= and 3.19.8). Ofcom intends to collect this data to assesses the impact of = aggregate interference into other services. It would also provide usage inf= ormation (frequency in use) that would inform the operation of a kill switc= h capability. I suggest this deficiency can be remedied with the following = changes:

 

New P requirements (probably be= st placed following P.12):

 

P.12bis: The protocol MUST support a channel usage message = from the slave device to the master device.=9A The channel usage message MU= ST include parameters as required by local regulatory requirement.=9A These= parameters MAY include device ID, manufacturer's serial number, channel us= age and power level information.

 

P.12ter: The protocol MU= ST support a channel usage message from the master device to the database.= =9A The channel usage message MUST include parameters as required by local = regulatory requirement for the master and its associated slaves.=9A These p= arameters MAY include device ID, manufacturer's serial number, channel usag= e and power level information.

<= o:p> 

P.12qua: The protocol MUST= support a channel usage message acknowledgement.

 =

New O requirements (probably best placed following O13):

 

O.13bis:=9A Accordi= ng to local regulatory policy, after connecting to a master device's radio = network a slave device MAY inform the master device of the actual channel u= sage. The slave MUST include parameters required by local regulatory policy= , e.g. device ID, manufacturer's serial number, channel usage and power lev= el information.

 

O.13ter:=9A According to local regulato= ry policy, a master device MAY inform the database of the actual channel us= age of the master and its slaves. The master MUST include parameters requir= ed by local regulatory policy, e.g. device ID, manufacturer's serial number= , channel usage and power level information of the master and its slaves.

 

New steps could be introduced into one = or more use cases to cover these Ofcom requirements, e.g. new steps 6bis an= d 9bis in the hotspot use case at 4.2.1:

 

6bis. Prior to initiating transmission, if re= quired by local regulation, the master/AP informs the database of the chann= el and power level it has chosen. This is repeated for each slave that asso= ciated with the master.

&nb= sp;

9bis. Prior to initiating transmi= ssion, if required by local regulation, the slave informs the master/AP of = the channel and power level it has chosen, and the master/AP relays this in= formation to the database.

 

- end of new= text -

 

For information, for those not a= ccessing the url in the first paragraph of this email, the full Ofcom requi= rements leading to this new PAWS text are as follows:

=

&n= bsp;

3.18 After receiving instructions from a WSDB in relation to = the maximum permitted EIRPs over the DTT channels, and prior to initiating = transmissions within the UHF TV band, a master WSD must communicate to the = WSDB the following information:

= 3.18.1 The lower and upper frequency boundaries13 of the in-bloc= k emissions of the master WSD, and those of the in-block emissions of its a= ssociated slaves. A lower frequency will be specified as (470 + 8k + 0.2n) = MHz, with the corresponding upper frequency specified as (470 + 8k + 0.2m) = MHz, where 0 =98 k =98 39, 0 =98 n =98 39, 1 =98 m =98 40, and n < m.

3.18.2 The maximum in-block EIRP s= pectral densities (in dBm/(0.2 MHz)) that the master WSD, and its associate= d slaves, actually radiate between each reported lower frequency boundary a= nd its corresponding upper frequency boundary.

 

Footnote 13 states:

The use of upper and lower frequen= cy boundaries (defined over a 200 kHz raster) allows a WSDB to collect more= granular information with regards to the usage of the frequency resource b= y narrowband WSD technologies. The upper and lower frequencies of a boundar= y pair do not straddle a DTT channel boundary. Note that a WSD may transmit= over multiple, non-contiguous, whole DTT channels or fractions of DTT chan= nels.

 

3.19 A master WSD must be able to = receive the following information14 from a WSDB:

&= lt;snip>

3.19.8=9A=9A=9A=9A [= An acknowledgement from the WSDB, in the context of 3.18, that the reported= information on the DTT channels and EIRP spectral densities actually used = by the master and slave WSDs were received successfully by the WSDB18<= /sup>].

 

Footnote 14 states:

14 While the communication of some of this information from a WSDB to a m= aster WSD is optional, master WSDs must be able to receive and interpret th= ese.

 

Footnote 18 states:

1= 8 This forms part of a handshake protocol and may be an area where industry= could harmonise without the need for an explicit requirement in the regula= tions.

 

Regards

 =

Andy

 

From: paws-bounces@ietf.org [mailt= o:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com
Se= nt: 05 March 2012 19:46
To: paws@ietf.org
Subject: = [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03

 

The authors of the use cases and requirement= s draft have just posted a new version of the draft and indicated that ther= e are no unresolved comments/issues they are aware of.

&nbs= p;

Therefore, I'd like to initiate a WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paws-pr= oblem-stmt-usecases-rqmts-03.txt

 

Please r= eview the draft and send your comments to the list by March 20th, 2012.

 

If you review the draft and have no comments, sen= d a note to the list that the draft is good as it is, we need these notes a= s much as we need the actual comments.

 <= /p>

Thanks,= Gabor

&n= bsp;

= --_000_619CDADDCCD2B44380834BE8BF6F71414069146000EMV62UKRDdoma_-- From jmh@joelhalpern.com Tue Mar 6 07:53:04 2012 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 52F2421F8901 for ; Tue, 6 Mar 2012 07:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.016 X-Spam-Level: X-Spam-Status: No, score=-102.016 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 RoNZqOfOMhzi for ; Tue, 6 Mar 2012 07:53:03 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF0821F8722 for ; Tue, 6 Mar 2012 07:53:03 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id ED880CD0FB for ; Tue, 6 Mar 2012 07:53:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id B6F291C0851; Tue, 6 Mar 2012 07:53:02 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.100] (pool-71-161-51-182.clppva.btas.verizon.net [71.161.51.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id B32571C0799; Tue, 6 Mar 2012 07:53:01 -0800 (PST) Message-ID: <4F5632E4.8070103@joelhalpern.com> Date: Tue, 06 Mar 2012 10:53:08 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: andy.sago@bt.com References: <619CDADDCCD2B44380834BE8BF6F71414069146000@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: <619CDADDCCD2B44380834BE8BF6F71414069146000@EMV62-UKRD.domain1.systemhost.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: paws@ietf.org Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 15:53:04 -0000 As I understand, the information you are asking for is explicitly out of scope for the working group. Yours, Joel On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: > All > > Comparing the draft with the Ofcom requirements at > http://www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-regulatory-requirements-for-white-space-devices-in-the-UHF-TV-band, > I believe the WG draft is deficient in the area of reporting frequencies > and powers actually used by masters and slaves (Ofcom requirements 3.18 > and 3.19.8). Ofcom intends to collect this data to assesses the impact > of aggregate interference into other services. It would also provide > usage information (frequency in use) that would inform the operation of > a kill switch capability. I suggest this deficiency can be remedied with > the following changes: > > New P requirements (probably best placed following P.12): > > P.12bis: The protocol MUST support a channel usage message from the > slave device to the master device. The channel usage message MUST > include parameters as required by local regulatory requirement. These > parameters MAY include device ID, manufacturer's serial number, channel > usage and power level information. > > P.12ter: The protocol MUST support a channel usage message from the > master device to the database. The channel usage message MUST include > parameters as required by local regulatory requirement for the master > and its associated slaves. These parameters MAY include device ID, > manufacturer's serial number, channel usage and power level information. > > P.12qua: The protocol MUST support a channel usage message acknowledgement. > > New O requirements (probably best placed following O13): > > O.13bis: According to local regulatory policy, after connecting to a > master device's radio network a slave device MAY inform the master > device of the actual channel usage. The slave MUST include parameters > required by local regulatory policy, e.g. device ID, manufacturer's > serial number, channel usage and power level information. > > O.13ter: According to local regulatory policy, a master device MAY > inform the database of the actual channel usage of the master and its > slaves. The master MUST include parameters required by local regulatory > policy, e.g. device ID, manufacturer's serial number, channel usage and > power level information of the master and its slaves. > > New steps could be introduced into one or more use cases to cover these > Ofcom requirements, e.g. new steps 6bis and 9bis in the hotspot use case > at 4.2.1: > > 6bis. Prior to initiating transmission, if required by local regulation, > the master/AP informs the database of the channel and power level it has > chosen. This is repeated for each slave that associated with the master. > > 9bis. Prior to initiating transmission, if required by local regulation, > the slave informs the master/AP of the channel and power level it has > chosen, and the master/AP relays this information to the database. > > - end of new text - > > For information, for those not accessing the url in the first paragraph > of this email, the full Ofcom requirements leading to this new PAWS text > are as follows: > > 3.18 After receiving instructions from a WSDB in relation to the maximum > permitted EIRPs over the DTT channels, and prior to initiating > transmissions within the UHF TV band, a master WSD must communicate to > the WSDB the following information: > > 3.18.1 The lower and upper frequency boundaries^13 of the in-block > emissions of the master WSD, and those of the in-block emissions of its > associated slaves. A lower frequency will be specified as (470 + 8k + > 0.2n) MHz, with the corresponding upper frequency specified as (470 + 8k > + 0.2m) MHz, where 0 ≤ k ≤ 39, 0 ≤ n ≤ 39, 1 ≤ m ≤ 40, and n < m. > > 3.18.2 The maximum in-block EIRP spectral densities (in dBm/(0.2 MHz)) > that the master WSD, and its associated slaves, actually radiate between > each reported lower frequency boundary and its corresponding upper > frequency boundary. > > Footnote 13 states: > > The use of upper and lower frequency boundaries (defined over a 200 kHz > raster) allows a WSDB to collect more granular information with regards > to the usage of the frequency resource by narrowband WSD technologies. > The upper and lower frequencies of a boundary pair do not straddle a DTT > channel boundary. Note that a WSD may transmit over multiple, > non-contiguous, whole DTT channels or fractions of DTT channels. > > 3.19 A master WSD must be able to receive the following information^14 > from a WSDB: > > > > 3.19.8 [An acknowledgement from the WSDB, in the context of 3.18, > that the reported information on the DTT channels and EIRP spectral > densities actually used by the master and slave WSDs were received > successfully by the WSDB^18 ]. > > Footnote 14 states: > > 14 While the communication of some of this information from a WSDB to a > master WSD is optional, master WSDs must be able to receive and > interpret these. > > Footnote 18 states: > > 18 This forms part of a handshake protocol and may be an area where > industry could harmonise without the need for an explicit requirement in > the regulations. > > Regards > > Andy > > *From:*paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf > Of *Gabor.Bajko@nokia.com > *Sent:* 05 March 2012 19:46 > *To:* paws@ietf.org > *Subject:* [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03 > > The authors of the use cases and requirements draft have just posted a > new version of the draft and indicated that there are no unresolved > comments/issues they are aware of. > > Therefore, I'd like to initiate a WG Last Call for comments on > http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rqmts-03.txt > > > Please review the draft and send your comments to the list by March > 20th, 2012. > > If you review the draft and have no comments, send a note to the list > that the draft is good as it is, we need these notes as much as we need > the actual comments. > > Thanks, Gabor > > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From andy.sago@bt.com Tue Mar 6 08:03:03 2012 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 B99AC21E8088 for ; Tue, 6 Mar 2012 08:03:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, 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 TXJKPMt6+oLP for ; Tue, 6 Mar 2012 08:03:02 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 9376A21E805B for ; Tue, 6 Mar 2012 08:03:01 -0800 (PST) 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.213.0; Tue, 6 Mar 2012 16:03:00 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.196]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Tue, 6 Mar 2012 16:03:00 +0000 From: To: Date: Tue, 6 Mar 2012 16:03:00 +0000 Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting Thread-Index: Acz7sTkSxX9lgg33RJ+kEYYbXeGLbQAABYPw Message-ID: <619CDADDCCD2B44380834BE8BF6F7141406914604C@EMV62-UKRD.domain1.systemhost.net> References: <619CDADDCCD2B44380834BE8BF6F71414069146000@EMV62-UKRD.domain1.systemhost.net> <4F5632E4.8070103@joelhalpern.com> In-Reply-To: <4F5632E4.8070103@joelhalpern.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: paws@ietf.org, johnny.dixon@bt.com, chris.cheeseman@bt.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 16:03:04 -0000 SGkgSm9lbA0KDQpUaGVyZSdzIG5vIGxhbmd1YWdlIEkgY2FuIGZpbmQgaW4gdGhlIGNoYXJ0ZXIg dGhhdCBleHBsaWNpdGx5IHB1dHMgdGhpcyBvdXQgb2Ygc2NvcGUuIE9uIHRoZSBvdGhlciBoYW5k LCB0aGUgY2hhcnRlciBzYXlzIHRoYXQgdGhlIGdyb3VwIHdpbGwgImNvbnNpZGVyIGlucHV0ICBm cm9tIHJlZ3VsYXRvcnkgZW50aXRpZXMiLCBhbmQgdGhpcyBpcyBvbmUgb2YgdGhlIHJlcXVpcmVt ZW50cyBmcm9tIE9mY29tIHRoYXQgdGhleSBoYXZlIGp1c3QgcHVibGlzaGVkLiBUaGUgcHJvdG9j b2wgd2lsbCBiZSB3b3J0aGxlc3MgZm9yIHRoZSBVSyBpZiBpdCBvbWl0cyBzb21lIHJlcXVpcmVt ZW50cy4NCg0KUmVnYXJkcw0KDQpBbmR5DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBKb2VsIE0uIEhhbHBlcm4gW21haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXSANClNlbnQ6 IDA2IE1hcmNoIDIwMTIgMTU6NTMNClRvOiBTYWdvLEFKLEFuZHksQ09EIFINCkNjOiBwYXdzQGll dGYub3JnOyBHYWJvci5CYWprb0Bub2tpYS5jb20NClN1YmplY3Q6IFJlOiBbcGF3c10gV0dMQyBm b3IgZHJhZnQtaWV0Zi1wYXdzLXByb2JsZW0tc3RtdC11c2VjYXNlcy1ycW10cy0wMzogY2hhbm5l bCByZXBvcnRpbmcNCg0KQXMgSSB1bmRlcnN0YW5kLCB0aGUgaW5mb3JtYXRpb24geW91IGFyZSBh c2tpbmcgZm9yIGlzIGV4cGxpY2l0bHkgb3V0IG9mIHNjb3BlIGZvciB0aGUgd29ya2luZyBncm91 cC4NCllvdXJzLA0KSm9lbA0KDQpPbiAzLzYvMjAxMiAxMDo0MiBBTSwgYW5keS5zYWdvQGJ0LmNv bSB3cm90ZToNCj4gQWxsDQo+DQo+IENvbXBhcmluZyB0aGUgZHJhZnQgd2l0aCB0aGUgT2Zjb20g cmVxdWlyZW1lbnRzIGF0IA0KPiBodHRwOi8vd3d3LmNlcHQub3JnL0RvY3VtZW50cy9zZS00My80 MTYxL1NFNDMoMTIpSW5mbzAzX0RyYWZ0LVVLLXJlZ3VsDQo+IGF0b3J5LXJlcXVpcmVtZW50cy1m b3Itd2hpdGUtc3BhY2UtZGV2aWNlcy1pbi10aGUtVUhGLVRWLWJhbmQsDQo+IEkgYmVsaWV2ZSB0 aGUgV0cgZHJhZnQgaXMgZGVmaWNpZW50IGluIHRoZSBhcmVhIG9mIHJlcG9ydGluZyANCj4gZnJl cXVlbmNpZXMgYW5kIHBvd2VycyBhY3R1YWxseSB1c2VkIGJ5IG1hc3RlcnMgYW5kIHNsYXZlcyAo T2Zjb20gDQo+IHJlcXVpcmVtZW50cyAzLjE4IGFuZCAzLjE5LjgpLiBPZmNvbSBpbnRlbmRzIHRv IGNvbGxlY3QgdGhpcyBkYXRhIHRvIA0KPiBhc3Nlc3NlcyB0aGUgaW1wYWN0IG9mIGFnZ3JlZ2F0 ZSBpbnRlcmZlcmVuY2UgaW50byBvdGhlciBzZXJ2aWNlcy4gSXQgDQo+IHdvdWxkIGFsc28gcHJv dmlkZSB1c2FnZSBpbmZvcm1hdGlvbiAoZnJlcXVlbmN5IGluIHVzZSkgdGhhdCB3b3VsZCANCj4g aW5mb3JtIHRoZSBvcGVyYXRpb24gb2YgYSBraWxsIHN3aXRjaCBjYXBhYmlsaXR5LiBJIHN1Z2dl c3QgdGhpcyANCj4gZGVmaWNpZW5jeSBjYW4gYmUgcmVtZWRpZWQgd2l0aCB0aGUgZm9sbG93aW5n IGNoYW5nZXM6DQo+DQo+IE5ldyBQIHJlcXVpcmVtZW50cyAocHJvYmFibHkgYmVzdCBwbGFjZWQg Zm9sbG93aW5nIFAuMTIpOg0KPg0KPiBQLjEyYmlzOiBUaGUgcHJvdG9jb2wgTVVTVCBzdXBwb3J0 IGEgY2hhbm5lbCB1c2FnZSBtZXNzYWdlIGZyb20gdGhlIA0KPiBzbGF2ZSBkZXZpY2UgdG8gdGhl IG1hc3RlciBkZXZpY2UuICBUaGUgY2hhbm5lbCB1c2FnZSBtZXNzYWdlIE1VU1QgDQo+IGluY2x1 ZGUgcGFyYW1ldGVycyBhcyByZXF1aXJlZCBieSBsb2NhbCByZWd1bGF0b3J5IHJlcXVpcmVtZW50 LiAgVGhlc2UgDQo+IHBhcmFtZXRlcnMgTUFZIGluY2x1ZGUgZGV2aWNlIElELCBtYW51ZmFjdHVy ZXIncyBzZXJpYWwgbnVtYmVyLCANCj4gY2hhbm5lbCB1c2FnZSBhbmQgcG93ZXIgbGV2ZWwgaW5m b3JtYXRpb24uDQo+DQo+IFAuMTJ0ZXI6IFRoZSBwcm90b2NvbCBNVVNUIHN1cHBvcnQgYSBjaGFu bmVsIHVzYWdlIG1lc3NhZ2UgZnJvbSB0aGUgDQo+IG1hc3RlciBkZXZpY2UgdG8gdGhlIGRhdGFi YXNlLiAgVGhlIGNoYW5uZWwgdXNhZ2UgbWVzc2FnZSBNVVNUIGluY2x1ZGUgDQo+IHBhcmFtZXRl cnMgYXMgcmVxdWlyZWQgYnkgbG9jYWwgcmVndWxhdG9yeSByZXF1aXJlbWVudCBmb3IgdGhlIG1h c3RlciANCj4gYW5kIGl0cyBhc3NvY2lhdGVkIHNsYXZlcy4gIFRoZXNlIHBhcmFtZXRlcnMgTUFZ IGluY2x1ZGUgZGV2aWNlIElELCANCj4gbWFudWZhY3R1cmVyJ3Mgc2VyaWFsIG51bWJlciwgY2hh bm5lbCB1c2FnZSBhbmQgcG93ZXIgbGV2ZWwgaW5mb3JtYXRpb24uDQo+DQo+IFAuMTJxdWE6IFRo ZSBwcm90b2NvbCBNVVNUIHN1cHBvcnQgYSBjaGFubmVsIHVzYWdlIG1lc3NhZ2UgYWNrbm93bGVk Z2VtZW50Lg0KPg0KPiBOZXcgTyByZXF1aXJlbWVudHMgKHByb2JhYmx5IGJlc3QgcGxhY2VkIGZv bGxvd2luZyBPMTMpOg0KPg0KPiBPLjEzYmlzOiAgQWNjb3JkaW5nIHRvIGxvY2FsIHJlZ3VsYXRv cnkgcG9saWN5LCBhZnRlciBjb25uZWN0aW5nIHRvIGEgDQo+IG1hc3RlciBkZXZpY2UncyByYWRp byBuZXR3b3JrIGEgc2xhdmUgZGV2aWNlIE1BWSBpbmZvcm0gdGhlIG1hc3RlciANCj4gZGV2aWNl IG9mIHRoZSBhY3R1YWwgY2hhbm5lbCB1c2FnZS4gVGhlIHNsYXZlIE1VU1QgaW5jbHVkZSBwYXJh bWV0ZXJzIA0KPiByZXF1aXJlZCBieSBsb2NhbCByZWd1bGF0b3J5IHBvbGljeSwgZS5nLiBkZXZp Y2UgSUQsIG1hbnVmYWN0dXJlcidzIA0KPiBzZXJpYWwgbnVtYmVyLCBjaGFubmVsIHVzYWdlIGFu ZCBwb3dlciBsZXZlbCBpbmZvcm1hdGlvbi4NCj4NCj4gTy4xM3RlcjogIEFjY29yZGluZyB0byBs b2NhbCByZWd1bGF0b3J5IHBvbGljeSwgYSBtYXN0ZXIgZGV2aWNlIE1BWSANCj4gaW5mb3JtIHRo ZSBkYXRhYmFzZSBvZiB0aGUgYWN0dWFsIGNoYW5uZWwgdXNhZ2Ugb2YgdGhlIG1hc3RlciBhbmQg aXRzIA0KPiBzbGF2ZXMuIFRoZSBtYXN0ZXIgTVVTVCBpbmNsdWRlIHBhcmFtZXRlcnMgcmVxdWly ZWQgYnkgbG9jYWwgDQo+IHJlZ3VsYXRvcnkgcG9saWN5LCBlLmcuIGRldmljZSBJRCwgbWFudWZh Y3R1cmVyJ3Mgc2VyaWFsIG51bWJlciwgDQo+IGNoYW5uZWwgdXNhZ2UgYW5kIHBvd2VyIGxldmVs IGluZm9ybWF0aW9uIG9mIHRoZSBtYXN0ZXIgYW5kIGl0cyBzbGF2ZXMuDQo+DQo+IE5ldyBzdGVw cyBjb3VsZCBiZSBpbnRyb2R1Y2VkIGludG8gb25lIG9yIG1vcmUgdXNlIGNhc2VzIHRvIGNvdmVy IA0KPiB0aGVzZSBPZmNvbSByZXF1aXJlbWVudHMsIGUuZy4gbmV3IHN0ZXBzIDZiaXMgYW5kIDli aXMgaW4gdGhlIGhvdHNwb3QgDQo+IHVzZSBjYXNlIGF0IDQuMi4xOg0KPg0KPiA2YmlzLiBQcmlv ciB0byBpbml0aWF0aW5nIHRyYW5zbWlzc2lvbiwgaWYgcmVxdWlyZWQgYnkgbG9jYWwgDQo+IHJl Z3VsYXRpb24sIHRoZSBtYXN0ZXIvQVAgaW5mb3JtcyB0aGUgZGF0YWJhc2Ugb2YgdGhlIGNoYW5u ZWwgYW5kIA0KPiBwb3dlciBsZXZlbCBpdCBoYXMgY2hvc2VuLiBUaGlzIGlzIHJlcGVhdGVkIGZv ciBlYWNoIHNsYXZlIHRoYXQgYXNzb2NpYXRlZCB3aXRoIHRoZSBtYXN0ZXIuDQo+DQo+IDliaXMu IFByaW9yIHRvIGluaXRpYXRpbmcgdHJhbnNtaXNzaW9uLCBpZiByZXF1aXJlZCBieSBsb2NhbCAN Cj4gcmVndWxhdGlvbiwgdGhlIHNsYXZlIGluZm9ybXMgdGhlIG1hc3Rlci9BUCBvZiB0aGUgY2hh bm5lbCBhbmQgcG93ZXIgDQo+IGxldmVsIGl0IGhhcyBjaG9zZW4sIGFuZCB0aGUgbWFzdGVyL0FQ IHJlbGF5cyB0aGlzIGluZm9ybWF0aW9uIHRvIHRoZSBkYXRhYmFzZS4NCj4NCj4gLSBlbmQgb2Yg bmV3IHRleHQgLQ0KPg0KPiBGb3IgaW5mb3JtYXRpb24sIGZvciB0aG9zZSBub3QgYWNjZXNzaW5n IHRoZSB1cmwgaW4gdGhlIGZpcnN0IA0KPiBwYXJhZ3JhcGggb2YgdGhpcyBlbWFpbCwgdGhlIGZ1 bGwgT2Zjb20gcmVxdWlyZW1lbnRzIGxlYWRpbmcgdG8gdGhpcyANCj4gbmV3IFBBV1MgdGV4dCBh cmUgYXMgZm9sbG93czoNCj4NCj4gMy4xOCBBZnRlciByZWNlaXZpbmcgaW5zdHJ1Y3Rpb25zIGZy b20gYSBXU0RCIGluIHJlbGF0aW9uIHRvIHRoZSANCj4gbWF4aW11bSBwZXJtaXR0ZWQgRUlSUHMg b3ZlciB0aGUgRFRUIGNoYW5uZWxzLCBhbmQgcHJpb3IgdG8gaW5pdGlhdGluZyANCj4gdHJhbnNt aXNzaW9ucyB3aXRoaW4gdGhlIFVIRiBUViBiYW5kLCBhIG1hc3RlciBXU0QgbXVzdCBjb21tdW5p Y2F0ZSB0byANCj4gdGhlIFdTREIgdGhlIGZvbGxvd2luZyBpbmZvcm1hdGlvbjoNCj4NCj4gMy4x OC4xIFRoZSBsb3dlciBhbmQgdXBwZXIgZnJlcXVlbmN5IGJvdW5kYXJpZXNeMTMgb2YgdGhlIGlu LWJsb2NrIA0KPiBlbWlzc2lvbnMgb2YgdGhlIG1hc3RlciBXU0QsIGFuZCB0aG9zZSBvZiB0aGUg aW4tYmxvY2sgZW1pc3Npb25zIG9mIA0KPiBpdHMgYXNzb2NpYXRlZCBzbGF2ZXMuIEEgbG93ZXIg ZnJlcXVlbmN5IHdpbGwgYmUgc3BlY2lmaWVkIGFzICg0NzAgKyANCj4gOGsgKw0KPiAwLjJuKSBN SHosIHdpdGggdGhlIGNvcnJlc3BvbmRpbmcgdXBwZXIgZnJlcXVlbmN5IHNwZWNpZmllZCBhcyAo NDcwICsgDQo+IDhrDQo+ICsgMC4ybSkgTUh6LCB3aGVyZSAwIOKJpCBrIOKJpCAzOSwgMCDiiaQg biDiiaQgMzksIDEg4omkIG0g4omkIDQwLCBhbmQgbiA8IG0uDQo+DQo+IDMuMTguMiBUaGUgbWF4 aW11bSBpbi1ibG9jayBFSVJQIHNwZWN0cmFsIGRlbnNpdGllcyAoaW4gZEJtLygwLjIgTUh6KSkg DQo+IHRoYXQgdGhlIG1hc3RlciBXU0QsIGFuZCBpdHMgYXNzb2NpYXRlZCBzbGF2ZXMsIGFjdHVh bGx5IHJhZGlhdGUgDQo+IGJldHdlZW4gZWFjaCByZXBvcnRlZCBsb3dlciBmcmVxdWVuY3kgYm91 bmRhcnkgYW5kIGl0cyBjb3JyZXNwb25kaW5nIA0KPiB1cHBlciBmcmVxdWVuY3kgYm91bmRhcnku DQo+DQo+IEZvb3Rub3RlIDEzIHN0YXRlczoNCj4NCj4gVGhlIHVzZSBvZiB1cHBlciBhbmQgbG93 ZXIgZnJlcXVlbmN5IGJvdW5kYXJpZXMgKGRlZmluZWQgb3ZlciBhIDIwMCANCj4ga0h6DQo+IHJh c3RlcikgYWxsb3dzIGEgV1NEQiB0byBjb2xsZWN0IG1vcmUgZ3JhbnVsYXIgaW5mb3JtYXRpb24g d2l0aCANCj4gcmVnYXJkcyB0byB0aGUgdXNhZ2Ugb2YgdGhlIGZyZXF1ZW5jeSByZXNvdXJjZSBi eSBuYXJyb3diYW5kIFdTRCB0ZWNobm9sb2dpZXMuDQo+IFRoZSB1cHBlciBhbmQgbG93ZXIgZnJl cXVlbmNpZXMgb2YgYSBib3VuZGFyeSBwYWlyIGRvIG5vdCBzdHJhZGRsZSBhIA0KPiBEVFQgY2hh bm5lbCBib3VuZGFyeS4gTm90ZSB0aGF0IGEgV1NEIG1heSB0cmFuc21pdCBvdmVyIG11bHRpcGxl LCANCj4gbm9uLWNvbnRpZ3VvdXMsIHdob2xlIERUVCBjaGFubmVscyBvciBmcmFjdGlvbnMgb2Yg RFRUIGNoYW5uZWxzLg0KPg0KPiAzLjE5IEEgbWFzdGVyIFdTRCBtdXN0IGJlIGFibGUgdG8gcmVj ZWl2ZSB0aGUgZm9sbG93aW5nIGluZm9ybWF0aW9uXjE0IA0KPiBmcm9tIGEgV1NEQjoNCj4NCj4g PHNuaXA+DQo+DQo+IDMuMTkuOCAgICAgW0FuIGFja25vd2xlZGdlbWVudCBmcm9tIHRoZSBXU0RC LCBpbiB0aGUgY29udGV4dCBvZiAzLjE4LA0KPiB0aGF0IHRoZSByZXBvcnRlZCBpbmZvcm1hdGlv biBvbiB0aGUgRFRUIGNoYW5uZWxzIGFuZCBFSVJQIHNwZWN0cmFsIA0KPiBkZW5zaXRpZXMgYWN0 dWFsbHkgdXNlZCBieSB0aGUgbWFzdGVyIGFuZCBzbGF2ZSBXU0RzIHdlcmUgcmVjZWl2ZWQgDQo+ IHN1Y2Nlc3NmdWxseSBieSB0aGUgV1NEQl4xOCBdLg0KPg0KPiBGb290bm90ZSAxNCBzdGF0ZXM6 DQo+DQo+IDE0IFdoaWxlIHRoZSBjb21tdW5pY2F0aW9uIG9mIHNvbWUgb2YgdGhpcyBpbmZvcm1h dGlvbiBmcm9tIGEgV1NEQiB0byANCj4gYSBtYXN0ZXIgV1NEIGlzIG9wdGlvbmFsLCBtYXN0ZXIg V1NEcyBtdXN0IGJlIGFibGUgdG8gcmVjZWl2ZSBhbmQgDQo+IGludGVycHJldCB0aGVzZS4NCj4N Cj4gRm9vdG5vdGUgMTggc3RhdGVzOg0KPg0KPiAxOCBUaGlzIGZvcm1zIHBhcnQgb2YgYSBoYW5k c2hha2UgcHJvdG9jb2wgYW5kIG1heSBiZSBhbiBhcmVhIHdoZXJlIA0KPiBpbmR1c3RyeSBjb3Vs ZCBoYXJtb25pc2Ugd2l0aG91dCB0aGUgbmVlZCBmb3IgYW4gZXhwbGljaXQgcmVxdWlyZW1lbnQg DQo+IGluIHRoZSByZWd1bGF0aW9ucy4NCj4NCj4gUmVnYXJkcw0KPg0KPiBBbmR5DQo+DQo+ICpG cm9tOipwYXdzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmdd ICpPbiBCZWhhbGYgDQo+IE9mICpHYWJvci5CYWprb0Bub2tpYS5jb20NCj4gKlNlbnQ6KiAwNSBN YXJjaCAyMDEyIDE5OjQ2DQo+ICpUbzoqIHBhd3NAaWV0Zi5vcmcNCj4gKlN1YmplY3Q6KiBbcGF3 c10gV0dMQyBmb3IgDQo+IGRyYWZ0LWlldGYtcGF3cy1wcm9ibGVtLXN0bXQtdXNlY2FzZXMtcnFt dHMtMDMNCj4NCj4gVGhlIGF1dGhvcnMgb2YgdGhlIHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRz IGRyYWZ0IGhhdmUganVzdCBwb3N0ZWQgYSANCj4gbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0IGFu ZCBpbmRpY2F0ZWQgdGhhdCB0aGVyZSBhcmUgbm8gdW5yZXNvbHZlZCANCj4gY29tbWVudHMvaXNz dWVzIHRoZXkgYXJlIGF3YXJlIG9mLg0KPg0KPiBUaGVyZWZvcmUsIEknZCBsaWtlIHRvIGluaXRp YXRlIGEgV0cgTGFzdCBDYWxsIGZvciBjb21tZW50cyBvbiANCj4gaHR0cDovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1wYXdzLXByb2JsZW0tc3RtdC11c2VjYQ0KPiBz ZXMtcnFtdHMtMDMudHh0DQo+DQo+DQo+IFBsZWFzZSByZXZpZXcgdGhlIGRyYWZ0IGFuZCBzZW5k IHlvdXIgY29tbWVudHMgdG8gdGhlIGxpc3QgYnkgTWFyY2ggDQo+IDIwdGgsIDIwMTIuDQo+DQo+ IElmIHlvdSByZXZpZXcgdGhlIGRyYWZ0IGFuZCBoYXZlIG5vIGNvbW1lbnRzLCBzZW5kIGEgbm90 ZSB0byB0aGUgbGlzdCANCj4gdGhhdCB0aGUgZHJhZnQgaXMgZ29vZCBhcyBpdCBpcywgd2UgbmVl ZCB0aGVzZSBub3RlcyBhcyBtdWNoIGFzIHdlIA0KPiBuZWVkIHRoZSBhY3R1YWwgY29tbWVudHMu DQo+DQo+IFRoYW5rcywgR2Fib3INCj4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gcGF3cyBtYWlsaW5nIGxpc3QNCj4gcGF3c0BpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCg== From Basavaraj.Patil@nokia.com Tue Mar 6 08:22:26 2012 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 3C6B821F8970 for ; Tue, 6 Mar 2012 08:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.295 X-Spam-Level: X-Spam-Status: No, score=-104.295 tagged_above=-999 required=5 tests=[AWL=1.477, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4, 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 GWcRyFsFc2R6 for ; Tue, 6 Mar 2012 08:22:25 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id AEB2121F8964 for ; Tue, 6 Mar 2012 08:22:24 -0800 (PST) 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.4) with ESMTP id q26GME6n023102; Tue, 6 Mar 2012 18:22:15 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.21]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Mar 2012 18:22:14 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.150]) by 008-AM1MMR1-012.mgdnok.nokia.com ([65.54.30.21]) with mapi id 14.01.0355.003; Tue, 6 Mar 2012 17:22:13 +0100 From: To: , Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting Thread-Index: Acz7r7czsJW4r5ouRdyl+vO7M9pCcP//8kEAgAACwQD//6DIAA== Date: Tue, 6 Mar 2012 16:22:13 +0000 Message-ID: In-Reply-To: <619CDADDCCD2B44380834BE8BF6F7141406914604C@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.14.0.111121 x-originating-ip: [72.64.105.193] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <56D95B9632E53C42B657438826220B00@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Mar 2012 16:22:14.0663 (UTC) FILETIME=[4AA12970:01CCFBB5] X-Nokia-AV: Clean Cc: paws@ietf.org, johnny.dixon@bt.com, chris.cheeseman@bt.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 16:22:26 -0000 The ofcom requirements are very much relevant to the scope of the PAWS WG. The only other regulatory requirements that we have today is the FCC. Ofcom requirements are a good addition to the set. -Raj On 3/6/12 10:03 AM, "ext andy.sago@bt.com" wrote: >Hi Joel > >There's no language I can find in the charter that explicitly puts this >out of scope. On the other hand, the charter says that the group will >"consider input from regulatory entities", and this is one of the >requirements from Ofcom that they have just published. The protocol will >be worthless for the UK if it omits some requirements. > >Regards > >Andy > >-----Original Message----- >From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >Sent: 06 March 2012 15:53 >To: Sago,AJ,Andy,COD R >Cc: paws@ietf.org; Gabor.Bajko@nokia.com >Subject: Re: [paws] WGLC for >draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting > >As I understand, the information you are asking for is explicitly out of >scope for the working group. >Yours, >Joel > >On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >> All >> >> Comparing the draft with the Ofcom requirements at >> http://www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-regul >> atory-requirements-for-white-space-devices-in-the-UHF-TV-band, >> I believe the WG draft is deficient in the area of reporting >> frequencies and powers actually used by masters and slaves (Ofcom >> requirements 3.18 and 3.19.8). Ofcom intends to collect this data to >> assesses the impact of aggregate interference into other services. It >> would also provide usage information (frequency in use) that would >> inform the operation of a kill switch capability. I suggest this >> deficiency can be remedied with the following changes: >> >> New P requirements (probably best placed following P.12): >> >> P.12bis: The protocol MUST support a channel usage message from the >> slave device to the master device. The channel usage message MUST >> include parameters as required by local regulatory requirement. These >> parameters MAY include device ID, manufacturer's serial number, >> channel usage and power level information. >> >> P.12ter: The protocol MUST support a channel usage message from the >> master device to the database. The channel usage message MUST include >> parameters as required by local regulatory requirement for the master >> and its associated slaves. These parameters MAY include device ID, >> manufacturer's serial number, channel usage and power level information. >> >> P.12qua: The protocol MUST support a channel usage message >>acknowledgement. >> >> New O requirements (probably best placed following O13): >> >> O.13bis: According to local regulatory policy, after connecting to a >> master device's radio network a slave device MAY inform the master >> device of the actual channel usage. The slave MUST include parameters >> required by local regulatory policy, e.g. device ID, manufacturer's >> serial number, channel usage and power level information. >> >> O.13ter: According to local regulatory policy, a master device MAY >> inform the database of the actual channel usage of the master and its >> slaves. The master MUST include parameters required by local >> regulatory policy, e.g. device ID, manufacturer's serial number, >> channel usage and power level information of the master and its slaves. >> >> New steps could be introduced into one or more use cases to cover >> these Ofcom requirements, e.g. new steps 6bis and 9bis in the hotspot >> use case at 4.2.1: >> >> 6bis. Prior to initiating transmission, if required by local >> regulation, the master/AP informs the database of the channel and >> power level it has chosen. This is repeated for each slave that >>associated with the master. >> >> 9bis. Prior to initiating transmission, if required by local >> regulation, the slave informs the master/AP of the channel and power >> level it has chosen, and the master/AP relays this information to the >>database. >> >> - end of new text - >> >> For information, for those not accessing the url in the first >> paragraph of this email, the full Ofcom requirements leading to this >> new PAWS text are as follows: >> >> 3.18 After receiving instructions from a WSDB in relation to the >> maximum permitted EIRPs over the DTT channels, and prior to initiating >> transmissions within the UHF TV band, a master WSD must communicate to >> the WSDB the following information: >> >> 3.18.1 The lower and upper frequency boundaries^13 of the in-block >> emissions of the master WSD, and those of the in-block emissions of >> its associated slaves. A lower frequency will be specified as (470 + >> 8k + >> 0.2n) MHz, with the corresponding upper frequency specified as (470 + >> 8k >> + 0.2m) MHz, where 0 =BE k =BE 39, 0 =BE n =BE 39, 1 =BE m =BE 40, and n= < m. >> >> 3.18.2 The maximum in-block EIRP spectral densities (in dBm/(0.2 MHz)) >> that the master WSD, and its associated slaves, actually radiate >> between each reported lower frequency boundary and its corresponding >> upper frequency boundary. >> >> Footnote 13 states: >> >> The use of upper and lower frequency boundaries (defined over a 200 >> kHz >> raster) allows a WSDB to collect more granular information with >> regards to the usage of the frequency resource by narrowband WSD >>technologies. >> The upper and lower frequencies of a boundary pair do not straddle a >> DTT channel boundary. Note that a WSD may transmit over multiple, >> non-contiguous, whole DTT channels or fractions of DTT channels. >> >> 3.19 A master WSD must be able to receive the following information^14 >> from a WSDB: >> >> >> >> 3.19.8 [An acknowledgement from the WSDB, in the context of 3.18, >> that the reported information on the DTT channels and EIRP spectral >> densities actually used by the master and slave WSDs were received >> successfully by the WSDB^18 ]. >> >> Footnote 14 states: >> >> 14 While the communication of some of this information from a WSDB to >> a master WSD is optional, master WSDs must be able to receive and >> interpret these. >> >> Footnote 18 states: >> >> 18 This forms part of a handshake protocol and may be an area where >> industry could harmonise without the need for an explicit requirement >> in the regulations. >> >> Regards >> >> Andy >> >> *From:*paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf >> Of *Gabor.Bajko@nokia.com >> *Sent:* 05 March 2012 19:46 >> *To:* paws@ietf.org >> *Subject:* [paws] WGLC for >> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >> >> The authors of the use cases and requirements draft have just posted a >> new version of the draft and indicated that there are no unresolved >> comments/issues they are aware of. >> >> Therefore, I'd like to initiate a WG Last Call for comments on >> http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-useca >> ses-rqmts-03.txt >> >> >> Please review the draft and send your comments to the list by March >> 20th, 2012. >> >> If you review the draft and have no comments, send a note to the list >> that the draft is good as it is, we need these notes as much as we >> need the actual comments. >> >> Thanks, Gabor >> >> >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From jmh@joelhalpern.com Tue Mar 6 08:30:12 2012 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 1D7FB21F8763 for ; Tue, 6 Mar 2012 08:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.717 X-Spam-Level: X-Spam-Status: No, score=-101.717 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_42=0.6, 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 pwUQeDcz0l6a for ; Tue, 6 Mar 2012 08:30:11 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id B969221F84D2 for ; Tue, 6 Mar 2012 08:30:10 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id A637ECD65F for ; Tue, 6 Mar 2012 08:30:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id E8AC81A1C8D; Tue, 6 Mar 2012 08:30:09 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.100] (pool-71-161-51-182.clppva.btas.verizon.net [71.161.51.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 8D6FA1A1C8C; Tue, 6 Mar 2012 08:30:08 -0800 (PST) Message-ID: <4F563B97.407@joelhalpern.com> Date: Tue, 06 Mar 2012 11:30:15 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: paws@ietf.org, johnny.dixon@bt.com, chris.cheeseman@bt.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 16:30:12 -0000 I would draw a distinction. Ofcom regulations about whitespace requests are very much relevant. Ofcom regulations about notification of dynamic behavior (which spectrum is being used) are not in scope as I understand the earlier discussions, particularly the chartering discussions. Yours, Joel On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: > > The ofcom requirements are very much relevant to the scope of the PAWS WG. > The only other regulatory requirements that we have today is the FCC. > Ofcom requirements are a good addition to the set. > > -Raj > > On 3/6/12 10:03 AM, "ext andy.sago@bt.com" wrote: > >> Hi Joel >> >> There's no language I can find in the charter that explicitly puts this >> out of scope. On the other hand, the charter says that the group will >> "consider input from regulatory entities", and this is one of the >> requirements from Ofcom that they have just published. The protocol will >> be worthless for the UK if it omits some requirements. >> >> Regards >> >> Andy >> >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: 06 March 2012 15:53 >> To: Sago,AJ,Andy,COD R >> Cc: paws@ietf.org; Gabor.Bajko@nokia.com >> Subject: Re: [paws] WGLC for >> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting >> >> As I understand, the information you are asking for is explicitly out of >> scope for the working group. >> Yours, >> Joel >> >> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >>> All >>> >>> Comparing the draft with the Ofcom requirements at >>> http://www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-regul >>> atory-requirements-for-white-space-devices-in-the-UHF-TV-band, >>> I believe the WG draft is deficient in the area of reporting >>> frequencies and powers actually used by masters and slaves (Ofcom >>> requirements 3.18 and 3.19.8). Ofcom intends to collect this data to >>> assesses the impact of aggregate interference into other services. It >>> would also provide usage information (frequency in use) that would >>> inform the operation of a kill switch capability. I suggest this >>> deficiency can be remedied with the following changes: >>> >>> New P requirements (probably best placed following P.12): >>> >>> P.12bis: The protocol MUST support a channel usage message from the >>> slave device to the master device. The channel usage message MUST >>> include parameters as required by local regulatory requirement. These >>> parameters MAY include device ID, manufacturer's serial number, >>> channel usage and power level information. >>> >>> P.12ter: The protocol MUST support a channel usage message from the >>> master device to the database. The channel usage message MUST include >>> parameters as required by local regulatory requirement for the master >>> and its associated slaves. These parameters MAY include device ID, >>> manufacturer's serial number, channel usage and power level information. >>> >>> P.12qua: The protocol MUST support a channel usage message >>> acknowledgement. >>> >>> New O requirements (probably best placed following O13): >>> >>> O.13bis: According to local regulatory policy, after connecting to a >>> master device's radio network a slave device MAY inform the master >>> device of the actual channel usage. The slave MUST include parameters >>> required by local regulatory policy, e.g. device ID, manufacturer's >>> serial number, channel usage and power level information. >>> >>> O.13ter: According to local regulatory policy, a master device MAY >>> inform the database of the actual channel usage of the master and its >>> slaves. The master MUST include parameters required by local >>> regulatory policy, e.g. device ID, manufacturer's serial number, >>> channel usage and power level information of the master and its slaves. >>> >>> New steps could be introduced into one or more use cases to cover >>> these Ofcom requirements, e.g. new steps 6bis and 9bis in the hotspot >>> use case at 4.2.1: >>> >>> 6bis. Prior to initiating transmission, if required by local >>> regulation, the master/AP informs the database of the channel and >>> power level it has chosen. This is repeated for each slave that >>> associated with the master. >>> >>> 9bis. Prior to initiating transmission, if required by local >>> regulation, the slave informs the master/AP of the channel and power >>> level it has chosen, and the master/AP relays this information to the >>> database. >>> >>> - end of new text - >>> >>> For information, for those not accessing the url in the first >>> paragraph of this email, the full Ofcom requirements leading to this >>> new PAWS text are as follows: >>> >>> 3.18 After receiving instructions from a WSDB in relation to the >>> maximum permitted EIRPs over the DTT channels, and prior to initiating >>> transmissions within the UHF TV band, a master WSD must communicate to >>> the WSDB the following information: >>> >>> 3.18.1 The lower and upper frequency boundaries^13 of the in-block >>> emissions of the master WSD, and those of the in-block emissions of >>> its associated slaves. A lower frequency will be specified as (470 + >>> 8k + >>> 0.2n) MHz, with the corresponding upper frequency specified as (470 + >>> 8k >>> + 0.2m) MHz, where 0 ¾ k ¾ 39, 0 ¾ n ¾ 39, 1 ¾ m ¾ 40, and n< m. >>> >>> 3.18.2 The maximum in-block EIRP spectral densities (in dBm/(0.2 MHz)) >>> that the master WSD, and its associated slaves, actually radiate >>> between each reported lower frequency boundary and its corresponding >>> upper frequency boundary. >>> >>> Footnote 13 states: >>> >>> The use of upper and lower frequency boundaries (defined over a 200 >>> kHz >>> raster) allows a WSDB to collect more granular information with >>> regards to the usage of the frequency resource by narrowband WSD >>> technologies. >>> The upper and lower frequencies of a boundary pair do not straddle a >>> DTT channel boundary. Note that a WSD may transmit over multiple, >>> non-contiguous, whole DTT channels or fractions of DTT channels. >>> >>> 3.19 A master WSD must be able to receive the following information^14 >>> from a WSDB: >>> >>> >>> >>> 3.19.8 [An acknowledgement from the WSDB, in the context of 3.18, >>> that the reported information on the DTT channels and EIRP spectral >>> densities actually used by the master and slave WSDs were received >>> successfully by the WSDB^18 ]. >>> >>> Footnote 14 states: >>> >>> 14 While the communication of some of this information from a WSDB to >>> a master WSD is optional, master WSDs must be able to receive and >>> interpret these. >>> >>> Footnote 18 states: >>> >>> 18 This forms part of a handshake protocol and may be an area where >>> industry could harmonise without the need for an explicit requirement >>> in the regulations. >>> >>> Regards >>> >>> Andy >>> >>> *From:*paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf >>> Of *Gabor.Bajko@nokia.com >>> *Sent:* 05 March 2012 19:46 >>> *To:* paws@ietf.org >>> *Subject:* [paws] WGLC for >>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >>> >>> The authors of the use cases and requirements draft have just posted a >>> new version of the draft and indicated that there are no unresolved >>> comments/issues they are aware of. >>> >>> Therefore, I'd like to initiate a WG Last Call for comments on >>> http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-useca >>> ses-rqmts-03.txt >>> >>> >>> Please review the draft and send your comments to the list by March >>> 20th, 2012. >>> >>> If you review the draft and have no comments, send a note to the list >>> that the draft is good as it is, we need these notes as much as we >>> need the actual comments. >>> >>> Thanks, Gabor >>> >>> >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws > > From Basavaraj.Patil@nokia.com Tue Mar 6 08:38:54 2012 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 7014421F89AA for ; Tue, 6 Mar 2012 08:38:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.418 X-Spam-Level: X-Spam-Status: No, score=-104.418 tagged_above=-999 required=5 tests=[AWL=1.354, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4, 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 4UVTo5+dQfD1 for ; Tue, 6 Mar 2012 08:38:50 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id E696A21F8913 for ; Tue, 6 Mar 2012 08:38:49 -0800 (PST) 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.4) with ESMTP id q26Gclla007694; Tue, 6 Mar 2012 18:38:48 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.26]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Mar 2012 18:38:47 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.150]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.01.0355.003; Tue, 6 Mar 2012 17:38:46 +0100 From: To: Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting Thread-Index: Acz7r7czsJW4r5ouRdyl+vO7M9pCcP//8kEAgAACwQD//6DIAIAAZtWA//+dy4A= Date: Tue, 6 Mar 2012 16:38:46 +0000 Message-ID: In-Reply-To: <4F563B97.407@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [72.64.105.193] Content-Type: text/plain; charset="Windows-1252" Content-ID: <2298EBAF72A27443A48F8C68DF19F5A5@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Mar 2012 16:38:47.0638 (UTC) FILETIME=[9A7D1F60:01CCFBB7] X-Nokia-AV: Clean Cc: paws@ietf.org, johnny.dixon@bt.com, chris.cheeseman@bt.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 16:38:54 -0000 I think it is worthwhile having a discussion about the requirement (which spectrum is being used) from Ofcom rather than ruling it out of scope. If the outcome of the PAWS WG is to be relevant across different regions/domains, then we should consider it even if it means revising the charter and expanding the scope. -Raj On 3/6/12 10:30 AM, "ext Joel M. Halpern" wrote: >I would draw a distinction. Ofcom regulations about whitespace requests >are very much relevant. >Ofcom regulations about notification of dynamic behavior (which spectrum >is being used) are not in scope as I understand the earlier discussions, >particularly the chartering discussions. > >Yours, >Joel > >On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: >> >> The ofcom requirements are very much relevant to the scope of the PAWS >>WG. >> The only other regulatory requirements that we have today is the FCC. >> Ofcom requirements are a good addition to the set. >> >> -Raj >> >> On 3/6/12 10:03 AM, "ext andy.sago@bt.com" wrote: >> >>> Hi Joel >>> >>> There's no language I can find in the charter that explicitly puts this >>> out of scope. On the other hand, the charter says that the group will >>> "consider input from regulatory entities", and this is one of the >>> requirements from Ofcom that they have just published. The protocol >>>will >>> be worthless for the UK if it omits some requirements. >>> >>> Regards >>> >>> Andy >>> >>> -----Original Message----- >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>> Sent: 06 March 2012 15:53 >>> To: Sago,AJ,Andy,COD R >>> Cc: paws@ietf.org; Gabor.Bajko@nokia.com >>> Subject: Re: [paws] WGLC for >>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting >>> >>> As I understand, the information you are asking for is explicitly out >>>of >>> scope for the working group. >>> Yours, >>> Joel >>> >>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >>>> All >>>> >>>> Comparing the draft with the Ofcom requirements at >>>> http://www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-regul >>>> atory-requirements-for-white-space-devices-in-the-UHF-TV-band, >>>> I believe the WG draft is deficient in the area of reporting >>>> frequencies and powers actually used by masters and slaves (Ofcom >>>> requirements 3.18 and 3.19.8). Ofcom intends to collect this data to >>>> assesses the impact of aggregate interference into other services. It >>>> would also provide usage information (frequency in use) that would >>>> inform the operation of a kill switch capability. I suggest this >>>> deficiency can be remedied with the following changes: >>>> >>>> New P requirements (probably best placed following P.12): >>>> >>>> P.12bis: The protocol MUST support a channel usage message from the >>>> slave device to the master device. The channel usage message MUST >>>> include parameters as required by local regulatory requirement. These >>>> parameters MAY include device ID, manufacturer's serial number, >>>> channel usage and power level information. >>>> >>>> P.12ter: The protocol MUST support a channel usage message from the >>>> master device to the database. The channel usage message MUST include >>>> parameters as required by local regulatory requirement for the master >>>> and its associated slaves. These parameters MAY include device ID, >>>> manufacturer's serial number, channel usage and power level >>>>information. >>>> >>>> P.12qua: The protocol MUST support a channel usage message >>>> acknowledgement. >>>> >>>> New O requirements (probably best placed following O13): >>>> >>>> O.13bis: According to local regulatory policy, after connecting to a >>>> master device's radio network a slave device MAY inform the master >>>> device of the actual channel usage. The slave MUST include parameters >>>> required by local regulatory policy, e.g. device ID, manufacturer's >>>> serial number, channel usage and power level information. >>>> >>>> O.13ter: According to local regulatory policy, a master device MAY >>>> inform the database of the actual channel usage of the master and its >>>> slaves. The master MUST include parameters required by local >>>> regulatory policy, e.g. device ID, manufacturer's serial number, >>>> channel usage and power level information of the master and its >>>>slaves. >>>> >>>> New steps could be introduced into one or more use cases to cover >>>> these Ofcom requirements, e.g. new steps 6bis and 9bis in the hotspot >>>> use case at 4.2.1: >>>> >>>> 6bis. Prior to initiating transmission, if required by local >>>> regulation, the master/AP informs the database of the channel and >>>> power level it has chosen. This is repeated for each slave that >>>> associated with the master. >>>> >>>> 9bis. Prior to initiating transmission, if required by local >>>> regulation, the slave informs the master/AP of the channel and power >>>> level it has chosen, and the master/AP relays this information to the >>>> database. >>>> >>>> - end of new text - >>>> >>>> For information, for those not accessing the url in the first >>>> paragraph of this email, the full Ofcom requirements leading to this >>>> new PAWS text are as follows: >>>> >>>> 3.18 After receiving instructions from a WSDB in relation to the >>>> maximum permitted EIRPs over the DTT channels, and prior to initiating >>>> transmissions within the UHF TV band, a master WSD must communicate to >>>> the WSDB the following information: >>>> >>>> 3.18.1 The lower and upper frequency boundaries^13 of the in-block >>>> emissions of the master WSD, and those of the in-block emissions of >>>> its associated slaves. A lower frequency will be specified as (470 + >>>> 8k + >>>> 0.2n) MHz, with the corresponding upper frequency specified as (470 + >>>> 8k >>>> + 0.2m) MHz, where 0 3=8E4 k 3=8E4 39, 0 3=8E4 n 3=8E4 39, 1 3=8E4 m 3= =8E4 40, and n< m. >>>> >>>> 3.18.2 The maximum in-block EIRP spectral densities (in dBm/(0.2 MHz)) >>>> that the master WSD, and its associated slaves, actually radiate >>>> between each reported lower frequency boundary and its corresponding >>>> upper frequency boundary. >>>> >>>> Footnote 13 states: >>>> >>>> The use of upper and lower frequency boundaries (defined over a 200 >>>> kHz >>>> raster) allows a WSDB to collect more granular information with >>>> regards to the usage of the frequency resource by narrowband WSD >>>> technologies. >>>> The upper and lower frequencies of a boundary pair do not straddle a >>>> DTT channel boundary. Note that a WSD may transmit over multiple, >>>> non-contiguous, whole DTT channels or fractions of DTT channels. >>>> >>>> 3.19 A master WSD must be able to receive the following information^14 >>>> from a WSDB: >>>> >>>> >>>> >>>> 3.19.8 [An acknowledgement from the WSDB, in the context of 3.18, >>>> that the reported information on the DTT channels and EIRP spectral >>>> densities actually used by the master and slave WSDs were received >>>> successfully by the WSDB^18 ]. >>>> >>>> Footnote 14 states: >>>> >>>> 14 While the communication of some of this information from a WSDB to >>>> a master WSD is optional, master WSDs must be able to receive and >>>> interpret these. >>>> >>>> Footnote 18 states: >>>> >>>> 18 This forms part of a handshake protocol and may be an area where >>>> industry could harmonise without the need for an explicit requirement >>>> in the regulations. >>>> >>>> Regards >>>> >>>> Andy >>>> >>>> *From:*paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf >>>> Of *Gabor.Bajko@nokia.com >>>> *Sent:* 05 March 2012 19:46 >>>> *To:* paws@ietf.org >>>> *Subject:* [paws] WGLC for >>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >>>> >>>> The authors of the use cases and requirements draft have just posted a >>>> new version of the draft and indicated that there are no unresolved >>>> comments/issues they are aware of. >>>> >>>> Therefore, I'd like to initiate a WG Last Call for comments on >>>> http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-useca >>>> ses-rqmts-03.txt >>>> >>>> >>>> Please review the draft and send your comments to the list by March >>>> 20th, 2012. >>>> >>>> If you review the draft and have no comments, send a note to the list >>>> that the draft is good as it is, we need these notes as much as we >>>> need the actual comments. >>>> >>>> Thanks, Gabor >>>> >>>> >>>> >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> >> From gerald.chouinard@sympatico.ca Tue Mar 6 08:44:18 2012 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 A496221F864E for ; Tue, 6 Mar 2012 08:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.028 X-Spam-Level: X-Spam-Status: No, score=0.028 tagged_above=-999 required=5 tests=[AWL=1.596, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803, 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 h8H1tyej+J7S for ; Tue, 6 Mar 2012 08:44:13 -0800 (PST) Received: from blu0-omc3-s24.blu0.hotmail.com (blu0-omc3-s24.blu0.hotmail.com [65.55.116.99]) by ietfa.amsl.com (Postfix) with ESMTP id 0EAAE21F8644 for ; Tue, 6 Mar 2012 08:44:10 -0800 (PST) Received: from BLU0-SMTP86 ([65.55.116.72]) by blu0-omc3-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Mar 2012 08:44:09 -0800 X-Originating-IP: [174.95.242.231] X-Originating-Email: [gerald.chouinard@sympatico.ca] Message-ID: Received: from Gerald2 ([174.95.242.231]) by BLU0-SMTP86.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Mar 2012 08:44:08 -0800 From: Gerald Chouinard To: References: <619CDADDCCD2B44380834BE8BF6F71414069146000@EMV62-UKRD.domain1.systemhost.net> Date: Tue, 6 Mar 2012 11:44:07 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C9_01CCFB8E.70FC6A20" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <619CDADDCCD2B44380834BE8BF6F71414069146000@EMV62-UKRD.domain1.systemhost.net> Thread-Index: Acz7r7czsJW4r5ouRdyl+vO7M9pCcAABpOzw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 06 Mar 2012 16:44:08.0778 (UTC) FILETIME=[59E732A0:01CCFBB8] Cc: paws@ietf.org Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 16:44:19 -0000 ------=_NextPart_000_00C9_01CCFB8E.70FC6A20 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Andy, Looking at your suggestions below, it seems that there is a need to define more precisely what a "slave" device is relative to its "master". In my view, a slave can only use the same transmission channel as that used by the master to which it is associated (otherwise, master and slaves would not be able to talk to each other). As a consequence, the slave does not have to indicate to the master the channel on which it is operating since the master knows it and can provided it to the database e. Similarly, modern bidirectional communication systems between a master and a slave device assumes that there will be a transmit power control (TPC) loop between the two devices to minimize the required transmit power in various propagation environments. The driving device in this closed-loop process will be the master and as a result, the EIRP transmitted by the slave device will be known to the master as long as there is a known factor linking the power specification sent by the master to the slave and the actual EIRP transmitted by the slave. Such factor which is a constant for each device can be provided from the slave to the master once at association. As a result, the slave does not need to inform the master of its current (and provably continuously varying) EIRP since the master will have this information from its TPC process and can provide it to the database on behalf of the slave device. Gerald _____ From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of andy.sago@bt.com Sent: Tuesday, 06 March, 2012 10:42 To: paws@ietf.org; Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting All Comparing the draft with the Ofcom requirements at http://www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-regulatory- requirements-for-white-space-devices-in-the-UHF-TV-band, I believe the WG draft is deficient in the area of reporting frequencies and powers actually used by masters and slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom intends to collect this data to assesses the impact of aggregate interference into other services. It would also provide usage information (frequency in use) that would inform the operation of a kill switch capability. I suggest this deficiency can be remedied with the following changes: New P requirements (probably best placed following P.12): P.12bis: The protocol MUST support a channel usage message from the slave device to the master device. The channel usage message MUST include parameters as required by local regulatory requirement. These parameters MAY include device ID, manufacturer's serial number, channel usage and power level information. P.12ter: The protocol MUST support a channel usage message from the master device to the database. The channel usage message MUST include parameters as required by local regulatory requirement for the master and its associated slaves. These parameters MAY include device ID, manufacturer's serial number, channel usage and power level information. P.12qua: The protocol MUST support a channel usage message acknowledgement. New O requirements (probably best placed following O13): O.13bis: According to local regulatory policy, after connecting to a master device's radio network a slave device MAY inform the master device of the actual channel usage. The slave MUST include parameters required by local regulatory policy, e.g. device ID, manufacturer's serial number, channel usage and power level information. O.13ter: According to local regulatory policy, a master device MAY inform the database of the actual channel usage of the master and its slaves. The master MUST include parameters required by local regulatory policy, e.g. device ID, manufacturer's serial number, channel usage and power level information of the master and its slaves. New steps could be introduced into one or more use cases to cover these Ofcom requirements, e.g. new steps 6bis and 9bis in the hotspot use case at 4.2.1: 6bis. Prior to initiating transmission, if required by local regulation, the master/AP informs the database of the channel and power level it has chosen. This is repeated for each slave that associated with the master. 9bis. Prior to initiating transmission, if required by local regulation, the slave informs the master/AP of the channel and power level it has chosen, and the master/AP relays this information to the database. - end of new text - For information, for those not accessing the url in the first paragraph of this email, the full Ofcom requirements leading to this new PAWS text are as follows: 3.18 After receiving instructions from a WSDB in relation to the maximum permitted EIRPs over the DTT channels, and prior to initiating transmissions within the UHF TV band, a master WSD must communicate to the WSDB the following information: 3.18.1 The lower and upper frequency boundaries13 of the in-block emissions of the master WSD, and those of the in-block emissions of its associated slaves. A lower frequency will be specified as (470 + 8k + 0.2n) MHz, with the corresponding upper frequency specified as (470 + 8k + 0.2m) MHz, where 0 ? k ? 39, 0 ? n ? 39, 1 ? m ? 40, and n < m. 3.18.2 The maximum in-block EIRP spectral densities (in dBm/(0.2 MHz)) that the master WSD, and its associated slaves, actually radiate between each reported lower frequency boundary and its corresponding upper frequency boundary. Footnote 13 states: The use of upper and lower frequency boundaries (defined over a 200 kHz raster) allows a WSDB to collect more granular information with regards to the usage of the frequency resource by narrowband WSD technologies. The upper and lower frequencies of a boundary pair do not straddle a DTT channel boundary. Note that a WSD may transmit over multiple, non-contiguous, whole DTT channels or fractions of DTT channels. 3.19 A master WSD must be able to receive the following information14 from a WSDB: 3.19.8 [An acknowledgement from the WSDB, in the context of 3.18, that the reported information on the DTT channels and EIRP spectral densities actually used by the master and slave WSDs were received successfully by the WSDB18]. Footnote 14 states: 14 While the communication of some of this information from a WSDB to a master WSD is optional, master WSDs must be able to receive and interpret these. Footnote 18 states: 18 This forms part of a handshake protocol and may be an area where industry could harmonise without the need for an explicit requirement in the regulations. Regards Andy From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com Sent: 05 March 2012 19:46 To: paws@ietf.org Subject: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03 The authors of the use cases and requirements draft have just posted a new version of the draft and indicated that there are no unresolved comments/issues they are aware of. Therefore, I'd like to initiate a WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rq mts-03.txt Please review the draft and send your comments to the list by March 20th, 2012. If you review the draft and have no comments, send a note to the list that the draft is good as it is, we need these notes as much as we need the actual comments. Thanks, Gabor ------=_NextPart_000_00C9_01CCFB8E.70FC6A20 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable

Andy,

 

Looking at your suggestions below, = it seems that there is a need to define more precisely what a “slave” = device is relative to its “master”.

 

In my view, a slave can only use = the same transmission channel as that used by the master to which it is = associated (otherwise, master and slaves would not be able to talk to each other). As a = consequence, the slave does not have to indicate to the master the channel on which = it is operating since the master knows it and can provided it to the database = e.

 

Similarly, modern bidirectional communication systems between a master and a slave device assumes that = there will be a transmit power control (TPC) loop between the two devices to = minimize the required transmit power in various propagation environments. The = driving device in this closed-loop process will be the master and as a result, = the EIRP transmitted by the slave device will be known to the master as long as = there is a known factor linking the power specification sent by the master to the = slave and the actual EIRP transmitted by the slave. =9ASuch factor which is a = constant for each device can be provided from the slave to the master once at association. =9AAs a result, the slave does not need to inform the = master of its current (and provably continuously varying) EIRP since the master will = have this information from its TPC process and can provide it to the database = on behalf of the slave device.

 

Gerald

 

From: = paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On = Behalf Of andy.sago@bt.com
Sent: Tuesday, 06 March, = 2012 10:42
To: paws@ietf.org; Gabor.Bajko@nokia.com
Subject: Re: [paws] WGLC = for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel = reporting

 

All

=

 <= /p>

Comparing the draft with the = Ofcom requirements at http:= //www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-regulatory-re= quirements-for-white-space-devices-in-the-UHF-TV-band, I believe the WG draft is deficient in the area of reporting frequencies = and powers actually used by masters and slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom intends to collect this data to assesses the impact of = aggregate interference into other services. It would also provide usage = information (frequency in use) that would inform the operation of a kill switch = capability. I suggest this deficiency can be remedied with the following = changes:

 <= /p>

New P requirements (probably = best placed following P.12):

 <= /p>

P.12bis: The protocol MUST support a channel usage message from the slave device = to the master device.  The channel usage message MUST include parameters = as required by local regulatory requirement.  These parameters MAY = include device ID, manufacturer's serial number, channel usage and power level information.

 <= /p>

P.12ter: The protocol MUST support a channel usage message from the master device = to the database.  The channel usage message MUST include parameters as = required by local regulatory requirement for the master and its associated = slaves.  These parameters MAY include device ID, manufacturer's serial number, = channel usage and power level information.

 <= /p>

P.12qua: The protocol MUST support a channel usage message = acknowledgement.

 <= /p>

New O requirements (probably = best placed following O13):

 <= /p>

O.13bis:  According to local regulatory policy, after connecting to a master = device's radio network a slave device MAY inform the master device of the actual = channel usage. The slave MUST include parameters required by local regulatory = policy, e.g. device ID, manufacturer's serial number, channel usage and power = level information.

 <= /p>

O.13ter:  According to local regulatory policy, a master device MAY inform the = database of the actual channel usage of the master and its slaves. The master = MUST include parameters required by local regulatory policy, e.g. device ID, manufacturer's serial number, channel usage and power level information = of the master and its slaves.

 <= /p>

New steps could be introduced = into one or more use cases to cover these Ofcom requirements, e.g. new steps 6bis = and 9bis in the hotspot use case at 4.2.1:

 <= /p>

6bis. Prior to initiating transmission, if required by local regulation, the master/AP informs the database of the channel and power level it has = chosen. This is repeated for each slave that associated with the = master.

 <= /p>

9bis. Prior to initiating transmission, if required by local regulation, the = slave informs the master/AP of the channel and power level it has chosen, and = the master/AP relays this information to the database. =

 <= /p>

- end of new text = -

 <= /p>

For information, for those not = accessing the url in the first paragraph of this email, the full Ofcom = requirements leading to this new PAWS text are as = follows:

 <= /p>

3.18 After receiving = instructions from a WSDB in relation to the maximum permitted EIRPs over the DTT channels, = and prior to initiating transmissions within the UHF TV band, a master WSD = must communicate to the WSDB the following = information:

3.18.1 The lower and upper frequency boundaries13 of the in-block = emissions of the master WSD, and those of the in-block emissions of its associated = slaves. A lower frequency will be specified as (470 + 8k + 0.2n) MHz, with the corresponding upper frequency specified as (470 + 8k + 0.2m) MHz, where = 0 =98 k =98 39, 0 =98 n =98 39, 1 =98 m =98 40, and n < = m.

3.18.2 The maximum in-block EIRP spectral densities (in dBm/(0.2 MHz)) that the = master WSD, and its associated slaves, actually radiate between each reported = lower frequency boundary and its corresponding upper frequency = boundary.

 <= /p>

Footnote 13 = states:

The use of upper and lower = frequency boundaries (defined over a 200 kHz raster) allows a WSDB to collect more granular information with regards to the usage of the frequency resource = by narrowband WSD technologies. The upper and lower frequencies of a = boundary pair do not straddle a DTT channel boundary. Note that a WSD may transmit = over multiple, non-contiguous, whole DTT channels or fractions of DTT = channels.

 <= /p>

3.19 A master WSD must be able = to receive the following information14 from a = WSDB:

<snip>

3.19.8     [An acknowledgement from the WSDB, in the context of 3.18, that the = reported information on the DTT channels and EIRP spectral densities actually = used by the master and slave WSDs were received successfully by the = WSDB18].

 <= /p>

Footnote 14 = states:

14 While the communication of = some of this information from a WSDB to a master WSD is optional, master WSDs = must be able to receive and interpret these.

 <= /p>

Footnote 18 = states:

18 This forms part of a = handshake protocol and may be an area where industry could harmonise without the = need for an explicit requirement in the regulations.

 <= /p>

Regards=

 <= /p>

Andy

 <= /p>

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com
Sent: 05 March 2012 = 19:46
To: paws@ietf.org
Subject: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03

 

The authors of the use cases and requirements draft have just posted a new = version of the draft and indicated that there are no unresolved comments/issues = they are aware of.

 

Therefore, I'd like to initiate a = WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paw= s-problem-stmt-usecases-rqmts-03.txt

 

Please review the draft and send = your comments to the list by March 20th, 2012.

 

If you review the draft and have = no comments, send a note to the list that the draft is good as it is, we = need these notes as much as we need the actual = comments.

 

Thanks, = Gabor

 

------=_NextPart_000_00C9_01CCFB8E.70FC6A20-- From scott.probasco@nokia.com Tue Mar 6 08:48:21 2012 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 ABE4421F8700 for ; Tue, 6 Mar 2012 08:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.306 X-Spam-Level: X-Spam-Status: No, score=-4.306 tagged_above=-999 required=5 tests=[AWL=1.466, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4, 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 0zLu46Zo5uy1 for ; Tue, 6 Mar 2012 08:48:20 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id A93DF21F86EF for ; Tue, 6 Mar 2012 08:48:13 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q26Gm93g003371; Tue, 6 Mar 2012 18:48:09 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Mar 2012 18:48:08 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.129]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0355.003; Tue, 6 Mar 2012 17:48:08 +0100 From: To: , Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting Thread-Index: Acz7r7czsJW4r5ouRdyl+vO7M9pCcP//8kEAgAACwQD//6DIAIAAZtWA//+gYwA= Date: Tue, 6 Mar 2012 16:48:07 +0000 Message-ID: In-Reply-To: <4F563B97.407@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.241.48.30] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Mar 2012 16:48:08.0898 (UTC) FILETIME=[E9069A20:01CCFBB8] X-Nokia-AV: Clean Cc: paws@ietf.org, johnny.dixon@bt.com, chris.cheeseman@bt.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 16:48:21 -0000 Hi, There is a similarity here with device ID. In context of PAWS we are not concerned with why a device ID is required by a regulator, we accept it is a requirement from a regulator and include it to the protocol. Ofcom identifies in 3.18 & 3.19 that channel usage information is required and thus we need to include this information. Since the master must provide this information prior to transmitting, PAWS will not function in the UK without this information and thus I believe channel usage information is integral to the channel request & response messaging. Kind Regards, Scott On 3/6/12 10:30 AM, "ext Joel M. Halpern" wrote: >I would draw a distinction. Ofcom regulations about whitespace requests >are very much relevant. >Ofcom regulations about notification of dynamic behavior (which spectrum >is being used) are not in scope as I understand the earlier discussions, >particularly the chartering discussions. > >Yours, >Joel > >On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: >> >> The ofcom requirements are very much relevant to the scope of the PAWS >>WG. >> The only other regulatory requirements that we have today is the FCC. >> Ofcom requirements are a good addition to the set. >> >> -Raj >> >> On 3/6/12 10:03 AM, "ext andy.sago@bt.com" wrote: >> >>> Hi Joel >>> >>> There's no language I can find in the charter that explicitly puts this >>> out of scope. On the other hand, the charter says that the group will >>> "consider input from regulatory entities", and this is one of the >>> requirements from Ofcom that they have just published. The protocol >>>will >>> be worthless for the UK if it omits some requirements. >>> >>> Regards >>> >>> Andy >>> >>> -----Original Message----- >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>> Sent: 06 March 2012 15:53 >>> To: Sago,AJ,Andy,COD R >>> Cc: paws@ietf.org; Gabor.Bajko@nokia.com >>> Subject: Re: [paws] WGLC for >>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting >>> >>> As I understand, the information you are asking for is explicitly out >>>of >>> scope for the working group. >>> Yours, >>> Joel >>> >>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >>>> All >>>> >>>> Comparing the draft with the Ofcom requirements at >>>> http://www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-regul >>>> atory-requirements-for-white-space-devices-in-the-UHF-TV-band, >>>> I believe the WG draft is deficient in the area of reporting >>>> frequencies and powers actually used by masters and slaves (Ofcom >>>> requirements 3.18 and 3.19.8). Ofcom intends to collect this data to >>>> assesses the impact of aggregate interference into other services. It >>>> would also provide usage information (frequency in use) that would >>>> inform the operation of a kill switch capability. I suggest this >>>> deficiency can be remedied with the following changes: >>>> >>>> New P requirements (probably best placed following P.12): >>>> >>>> P.12bis: The protocol MUST support a channel usage message from the >>>> slave device to the master device. The channel usage message MUST >>>> include parameters as required by local regulatory requirement. These >>>> parameters MAY include device ID, manufacturer's serial number, >>>> channel usage and power level information. >>>> >>>> P.12ter: The protocol MUST support a channel usage message from the >>>> master device to the database. The channel usage message MUST include >>>> parameters as required by local regulatory requirement for the master >>>> and its associated slaves. These parameters MAY include device ID, >>>> manufacturer's serial number, channel usage and power level >>>>information. >>>> >>>> P.12qua: The protocol MUST support a channel usage message >>>> acknowledgement. >>>> >>>> New O requirements (probably best placed following O13): >>>> >>>> O.13bis: According to local regulatory policy, after connecting to a >>>> master device's radio network a slave device MAY inform the master >>>> device of the actual channel usage. The slave MUST include parameters >>>> required by local regulatory policy, e.g. device ID, manufacturer's >>>> serial number, channel usage and power level information. >>>> >>>> O.13ter: According to local regulatory policy, a master device MAY >>>> inform the database of the actual channel usage of the master and its >>>> slaves. The master MUST include parameters required by local >>>> regulatory policy, e.g. device ID, manufacturer's serial number, >>>> channel usage and power level information of the master and its >>>>slaves. >>>> >>>> New steps could be introduced into one or more use cases to cover >>>> these Ofcom requirements, e.g. new steps 6bis and 9bis in the hotspot >>>> use case at 4.2.1: >>>> >>>> 6bis. Prior to initiating transmission, if required by local >>>> regulation, the master/AP informs the database of the channel and >>>> power level it has chosen. This is repeated for each slave that >>>> associated with the master. >>>> >>>> 9bis. Prior to initiating transmission, if required by local >>>> regulation, the slave informs the master/AP of the channel and power >>>> level it has chosen, and the master/AP relays this information to the >>>> database. >>>> >>>> - end of new text - >>>> >>>> For information, for those not accessing the url in the first >>>> paragraph of this email, the full Ofcom requirements leading to this >>>> new PAWS text are as follows: >>>> >>>> 3.18 After receiving instructions from a WSDB in relation to the >>>> maximum permitted EIRPs over the DTT channels, and prior to initiating >>>> transmissions within the UHF TV band, a master WSD must communicate to >>>> the WSDB the following information: >>>> >>>> 3.18.1 The lower and upper frequency boundaries^13 of the in-block >>>> emissions of the master WSD, and those of the in-block emissions of >>>> its associated slaves. A lower frequency will be specified as (470 + >>>> 8k + >>>> 0.2n) MHz, with the corresponding upper frequency specified as (470 + >>>> 8k >>>> + 0.2m) MHz, where 0 3=8E4 k 3=8E4 39, 0 3=8E4 n 3=8E4 39, 1 3=8E4 m 3= =8E4 40, and n< m. >>>> >>>> 3.18.2 The maximum in-block EIRP spectral densities (in dBm/(0.2 MHz)) >>>> that the master WSD, and its associated slaves, actually radiate >>>> between each reported lower frequency boundary and its corresponding >>>> upper frequency boundary. >>>> >>>> Footnote 13 states: >>>> >>>> The use of upper and lower frequency boundaries (defined over a 200 >>>> kHz >>>> raster) allows a WSDB to collect more granular information with >>>> regards to the usage of the frequency resource by narrowband WSD >>>> technologies. >>>> The upper and lower frequencies of a boundary pair do not straddle a >>>> DTT channel boundary. Note that a WSD may transmit over multiple, >>>> non-contiguous, whole DTT channels or fractions of DTT channels. >>>> >>>> 3.19 A master WSD must be able to receive the following information^14 >>>> from a WSDB: >>>> >>>> >>>> >>>> 3.19.8 [An acknowledgement from the WSDB, in the context of 3.18, >>>> that the reported information on the DTT channels and EIRP spectral >>>> densities actually used by the master and slave WSDs were received >>>> successfully by the WSDB^18 ]. >>>> >>>> Footnote 14 states: >>>> >>>> 14 While the communication of some of this information from a WSDB to >>>> a master WSD is optional, master WSDs must be able to receive and >>>> interpret these. >>>> >>>> Footnote 18 states: >>>> >>>> 18 This forms part of a handshake protocol and may be an area where >>>> industry could harmonise without the need for an explicit requirement >>>> in the regulations. >>>> >>>> Regards >>>> >>>> Andy >>>> >>>> *From:*paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf >>>> Of *Gabor.Bajko@nokia.com >>>> *Sent:* 05 March 2012 19:46 >>>> *To:* paws@ietf.org >>>> *Subject:* [paws] WGLC for >>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >>>> >>>> The authors of the use cases and requirements draft have just posted a >>>> new version of the draft and indicated that there are no unresolved >>>> comments/issues they are aware of. >>>> >>>> Therefore, I'd like to initiate a WG Last Call for comments on >>>> http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-useca >>>> ses-rqmts-03.txt >>>> >>>> >>>> Please review the draft and send your comments to the list by March >>>> 20th, 2012. >>>> >>>> If you review the draft and have no comments, send a note to the list >>>> that the draft is good as it is, we need these notes as much as we >>>> need the actual comments. >>>> >>>> Thanks, Gabor >>>> >>>> >>>> >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> >> >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From scott.probasco@nokia.com Tue Mar 6 08:59:45 2012 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 496D921F84D1 for ; Tue, 6 Mar 2012 08:59:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.559, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, 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 nUPV0nQ3aL2p for ; Tue, 6 Mar 2012 08:59:43 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6532E21F8478 for ; Tue, 6 Mar 2012 08:59:43 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q26GxRFQ012292; Tue, 6 Mar 2012 18:59:38 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.25]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Mar 2012 18:59:35 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.129]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.01.0355.003; Tue, 6 Mar 2012 17:59:34 +0100 From: To: , Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting Thread-Index: AQHM+7qBJZkKE/OsEE6WAJSH4Dz7Pg== Date: Tue, 6 Mar 2012 16:59:34 +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.14.0.111121 x-originating-ip: [10.241.48.30] Content-Type: multipart/alternative; boundary="_000_CB7B9C411390Ascottprobasconokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 06 Mar 2012 16:59:35.0260 (UTC) FILETIME=[822121C0:01CCFBBA] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 16:59:45 -0000 --_000_CB7B9C411390Ascottprobasconokiacom_ Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGkgR2VyYWxkLA0KDQpBdCBsZWFzdCBhY2NvcmRpbmcgdG8gdGhlIEZDQywgYSBzbGF2ZSAoTW9k ZSBJKSBkZXZpY2UgbWF5IHV0aWxpemUgY2hhbm5lbHMgdGhhdCB0aGUgbWFzdGVyIChmaXhlZCBk ZXZpY2UpIGNhbm5vdCB1c2UsIHNlZSCh1zE1LjcwNyBhbmQgMTUuNzEyLiBUaHVzIHRoZXJlIGFy ZSBwb3RlbnRpYWwgc2l0dWF0aW9ucyB3aGVyZSB0aGUgbWFzdGVyIGNhbm5vdCBiZSBhc3N1bWVk IHRvIGtub3cgd2hhdCBjaGFubmVsIHRoZSBzbGF2ZSBpcyB1c2luZy4gQWx0aG91Z2ggdGhpcyBp cyBhIGJpdCBlc290ZXJpYyBhcyB0aGUgRkNDIGlzIHNpbGVudCBhYm91dCB3aGF0IHRoZSBzbGF2 ZSBtaWdodCBkbyBvbiB0aG9zZSBjaGFubmVscywgaXQgaXMgbm9uZXRoZWxlc3MgaW5jbHVkZWQg aW4gdGhlIEZDQyByZWd1bGF0aW9ucy4NCg0KU28gSSBzdWdnZXN0IHdlIGhhdmUgbm8gcmVhc29u IHRvIG92ZXJydWxlIE9mY29tIHJlcXVpcmVtZW50cyBmb3IgY2hhbm5lbCB1c2FnZSBpbmZvcm1h dGlvbi4gQWxzbyBBbmR5J3MgY2hvaWNlIG9mIHdvcmRzIGRvZXMgZW5zdXJlIHRoYXQgdGhpcyBp bmZvcm1hdGlvbiBpcyBub3QgcmVxdWlyZWQgdG8gYmUgdXNlZCBpbiBldmVyeSBvcGVyYXRpb25h bCBzY2VuYXJpby4NCg0KS2luZCBSZWdhcmRzLA0KU2NvdHQNCg0KDQoNCkZyb206IGV4dCBDaG91 aW5hcmQgPGdlcmFsZC5jaG91aW5hcmRAc3ltcGF0aWNvLmNhPG1haWx0bzpnZXJhbGQuY2hvdWlu YXJkQHN5bXBhdGljby5jYT4+DQpEYXRlOiBUdWUsIDYgTWFyIDIwMTIgMTE6NDQ6MDcgLTA1MDAN ClRvOiBleHQgY29tIDxhbmR5LnNhZ29AYnQuY29tPG1haWx0bzphbmR5LnNhZ29AYnQuY29tPj4N CkNjOiAicGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4iIDxwYXdzQGlldGYub3Jn PG1haWx0bzpwYXdzQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbcGF3c10gV0dMQyBmb3IgZHJh ZnQtaWV0Zi1wYXdzLXByb2JsZW0tc3RtdC11c2VjYXNlcy1ycW10cy0wMzogY2hhbm5lbCByZXBv cnRpbmcNCg0KQW5keSwNCg0KTG9va2luZyBhdCB5b3VyIHN1Z2dlc3Rpb25zIGJlbG93LCBpdCBz ZWVtcyB0aGF0IHRoZXJlIGlzIGEgbmVlZCB0byBkZWZpbmUgbW9yZSBwcmVjaXNlbHkgd2hhdCBh IKGwc2xhdmWhsSBkZXZpY2UgaXMgcmVsYXRpdmUgdG8gaXRzIKGwbWFzdGVyobEuDQoNCkluIG15 IHZpZXcsIGEgc2xhdmUgY2FuIG9ubHkgdXNlIHRoZSBzYW1lIHRyYW5zbWlzc2lvbiBjaGFubmVs IGFzIHRoYXQgdXNlZCBieSB0aGUgbWFzdGVyIHRvIHdoaWNoIGl0IGlzIGFzc29jaWF0ZWQgKG90 aGVyd2lzZSwgbWFzdGVyIGFuZCBzbGF2ZXMgd291bGQgbm90IGJlIGFibGUgdG8gdGFsayB0byBl YWNoIG90aGVyKS4gQXMgYSBjb25zZXF1ZW5jZSwgdGhlIHNsYXZlIGRvZXMgbm90IGhhdmUgdG8g aW5kaWNhdGUgdG8gdGhlIG1hc3RlciB0aGUgY2hhbm5lbCBvbiB3aGljaCBpdCBpcyBvcGVyYXRp bmcgc2luY2UgdGhlIG1hc3RlciBrbm93cyBpdCBhbmQgY2FuIHByb3ZpZGVkIGl0IHRvIHRoZSBk YXRhYmFzZSBlLg0KDQpTaW1pbGFybHksIG1vZGVybiBiaWRpcmVjdGlvbmFsIGNvbW11bmljYXRp b24gc3lzdGVtcyBiZXR3ZWVuIGEgbWFzdGVyIGFuZCBhIHNsYXZlIGRldmljZSBhc3N1bWVzIHRo YXQgdGhlcmUgd2lsbCBiZSBhIHRyYW5zbWl0IHBvd2VyIGNvbnRyb2wgKFRQQykgbG9vcCBiZXR3 ZWVuIHRoZSB0d28gZGV2aWNlcyB0byBtaW5pbWl6ZSB0aGUgcmVxdWlyZWQgdHJhbnNtaXQgcG93 ZXIgaW4gdmFyaW91cyBwcm9wYWdhdGlvbiBlbnZpcm9ubWVudHMuIFRoZSBkcml2aW5nIGRldmlj ZSBpbiB0aGlzIGNsb3NlZC1sb29wIHByb2Nlc3Mgd2lsbCBiZSB0aGUgbWFzdGVyIGFuZCBhcyBh IHJlc3VsdCwgdGhlIEVJUlAgdHJhbnNtaXR0ZWQgYnkgdGhlIHNsYXZlIGRldmljZSB3aWxsIGJl IGtub3duIHRvIHRoZSBtYXN0ZXIgYXMgbG9uZyBhcyB0aGVyZSBpcyBhIGtub3duIGZhY3RvciBs aW5raW5nIHRoZSBwb3dlciBzcGVjaWZpY2F0aW9uIHNlbnQgYnkgdGhlIG1hc3RlciB0byB0aGUg c2xhdmUgYW5kIHRoZSBhY3R1YWwgRUlSUCB0cmFuc21pdHRlZCBieSB0aGUgc2xhdmUuICBTdWNo IGZhY3RvciB3aGljaCBpcyBhIGNvbnN0YW50IGZvciBlYWNoIGRldmljZSBjYW4gYmUgcHJvdmlk ZWQgZnJvbSB0aGUgc2xhdmUgdG8gdGhlIG1hc3RlciBvbmNlIGF0IGFzc29jaWF0aW9uLiAgQXMg YSByZXN1bHQsIHRoZSBzbGF2ZSBkb2VzIG5vdCBuZWVkIHRvIGluZm9ybSB0aGUgbWFzdGVyIG9m IGl0cyBjdXJyZW50IChhbmQgcHJvdmFibHkgY29udGludW91c2x5IHZhcnlpbmcpIEVJUlAgc2lu Y2UgdGhlIG1hc3RlciB3aWxsIGhhdmV0aGlzIGluZm9ybWF0aW9uIGZyb20gaXRzIFRQQyBwcm9j ZXNzIGFuZCBjYW4gcHJvdmlkZSBpdCB0byB0aGUgZGF0YWJhc2Ugb25iZWhhbGYgb2YgdGhlIHNs YXZlIGRldmljZS4NCg0KR2VyYWxkDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpGcm9tOiBwYXdzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9y Zz4gW21haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBhbmR5LnNhZ29A YnQuY29tPG1haWx0bzphbmR5LnNhZ29AYnQuY29tPg0KU2VudDogVHVlc2RheSwgMDYgTWFyY2gs IDIwMTIgMTA6NDINClRvOiBwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPjsgR2Fi b3IuQmFqa29Abm9raWEuY29tPG1haWx0bzpHYWJvci5CYWprb0Bub2tpYS5jb20+DQpTdWJqZWN0 OiBSZTogW3Bhd3NdIFdHTEMgZm9yIGRyYWZ0LWlldGYtcGF3cy1wcm9ibGVtLXN0bXQtdXNlY2Fz ZXMtcnFtdHMtMDM6IGNoYW5uZWwgcmVwb3J0aW5nDQoNCkFsbA0KDQpDb21wYXJpbmcgdGhlIGRy YWZ0IHdpdGggdGhlIE9mY29tIHJlcXVpcmVtZW50cyBhdCBodHRwOi8vd3d3LmNlcHQub3JnL0Rv Y3VtZW50cy9zZS00My80MTYxL1NFNDMoMTIpSW5mbzAzX0RyYWZ0LVVLLXJlZ3VsYXRvcnktcmVx dWlyZW1lbnRzLWZvci13aGl0ZS1zcGFjZS1kZXZpY2VzLWluLXRoZS1VSEYtVFYtYmFuZCwgSSBi ZWxpZXZlIHRoZSBXRyBkcmFmdCBpcyBkZWZpY2llbnQgaW4gdGhlIGFyZWEgb2YgcmVwb3J0aW5n IGZyZXF1ZW5jaWVzIGFuZCBwb3dlcnMgYWN0dWFsbHkgdXNlZCBieSBtYXN0ZXJzIGFuZCBzbGF2 ZXMgKE9mY29tIHJlcXVpcmVtZW50cyAzLjE4IGFuZCAzLjE5LjgpLiBPZmNvbSBpbnRlbmRzIHRv IGNvbGxlY3QgdGhpcyBkYXRhIHRvIGFzc2Vzc2VzIHRoZSBpbXBhY3Qgb2YgYWdncmVnYXRlIGlu dGVyZmVyZW5jZSBpbnRvIG90aGVyIHNlcnZpY2VzLiBJdCB3b3VsZCBhbHNvIHByb3ZpZGUgdXNh Z2UgaW5mb3JtYXRpb24gKGZyZXF1ZW5jeSBpbiB1c2UpIHRoYXQgd291bGQgaW5mb3JtIHRoZSBv cGVyYXRpb24gb2YgYSBraWxsIHN3aXRjaCBjYXBhYmlsaXR5LiBJIHN1Z2dlc3QgdGhpcyBkZWZp Y2llbmN5IGNhbiBiZSByZW1lZGllZCB3aXRoIHRoZSBmb2xsb3dpbmcgY2hhbmdlczoNCg0KTmV3 IFAgcmVxdWlyZW1lbnRzIChwcm9iYWJseSBiZXN0IHBsYWNlZCBmb2xsb3dpbmcgUC4xMik6DQoN ClAuMTJiaXM6IFRoZSBwcm90b2NvbCBNVVNUIHN1cHBvcnQgYSBjaGFubmVsIHVzYWdlIG1lc3Nh Z2UgZnJvbSB0aGUgc2xhdmUgZGV2aWNlIHRvIHRoZSBtYXN0ZXIgZGV2aWNlLiAgVGhlIGNoYW5u ZWwgdXNhZ2UgbWVzc2FnZSBNVVNUIGluY2x1ZGUgcGFyYW1ldGVycyBhcyByZXF1aXJlZCBieSBs b2NhbCByZWd1bGF0b3J5IHJlcXVpcmVtZW50LiAgVGhlc2UgcGFyYW1ldGVycyBNQVkgaW5jbHVk ZSBkZXZpY2UgSUQsIG1hbnVmYWN0dXJlcidzIHNlcmlhbCBudW1iZXIsIGNoYW5uZWwgdXNhZ2Ug YW5kIHBvd2VyIGxldmVsIGluZm9ybWF0aW9uLg0KDQpQLjEydGVyOiBUaGUgcHJvdG9jb2wgTVVT VCBzdXBwb3J0IGEgY2hhbm5lbCB1c2FnZSBtZXNzYWdlIGZyb20gdGhlIG1hc3RlciBkZXZpY2Ug dG8gdGhlIGRhdGFiYXNlLiAgVGhlIGNoYW5uZWwgdXNhZ2UgbWVzc2FnZSBNVVNUIGluY2x1ZGUg cGFyYW1ldGVycyBhcyByZXF1aXJlZCBieSBsb2NhbCByZWd1bGF0b3J5IHJlcXVpcmVtZW50IGZv ciB0aGUgbWFzdGVyIGFuZCBpdHMgYXNzb2NpYXRlZCBzbGF2ZXMuICBUaGVzZSBwYXJhbWV0ZXJz IE1BWSBpbmNsdWRlIGRldmljZSBJRCwgbWFudWZhY3R1cmVyJ3Mgc2VyaWFsIG51bWJlciwgY2hh bm5lbCB1c2FnZSBhbmQgcG93ZXIgbGV2ZWwgaW5mb3JtYXRpb24uDQoNClAuMTJxdWE6IFRoZSBw cm90b2NvbCBNVVNUIHN1cHBvcnQgYSBjaGFubmVsIHVzYWdlIG1lc3NhZ2UgYWNrbm93bGVkZ2Vt ZW50Lg0KDQpOZXcgTyByZXF1aXJlbWVudHMgKHByb2JhYmx5IGJlc3QgcGxhY2VkIGZvbGxvd2lu ZyBPMTMpOg0KDQpPLjEzYmlzOiAgQWNjb3JkaW5nIHRvIGxvY2FsIHJlZ3VsYXRvcnkgcG9saWN5 LCBhZnRlciBjb25uZWN0aW5nIHRvIGEgbWFzdGVyIGRldmljZSdzcmFkaW8gbmV0d29yayBhIHNs YXZlIGRldmljZSBNQVkgaW5mb3JtIHRoZSBtYXN0ZXIgZGV2aWNlIG9mIHRoZSBhY3R1YWwgY2hh bm5lbCB1c2FnZS4gVGhlIHNsYXZlIE1VU1QgaW5jbHVkZSBwYXJhbWV0ZXJzIHJlcXVpcmVkIGJ5 IGxvY2FsIHJlZ3VsYXRvcnkgcG9saWN5LCBlLmcuIGRldmljZSBJRCwgbWFudWZhY3R1cmVyJ3Mg c2VyaWFsIG51bWJlciwgY2hhbm5lbCB1c2FnZSBhbmQgcG93ZXIgbGV2ZWxpbmZvcm1hdGlvbi4N Cg0KTy4xM3RlcjogIEFjY29yZGluZyB0byBsb2NhbCByZWd1bGF0b3J5IHBvbGljeSwgYSBtYXN0 ZXIgZGV2aWNlIE1BWSBpbmZvcm0gdGhlIGRhdGFiYXNlIG9mIHRoZSBhY3R1YWwgY2hhbm5lbCB1 c2FnZSBvZiB0aGUgbWFzdGVyIGFuZCBpdHMgc2xhdmVzLiBUaGUgbWFzdGVyIE1VU1QgaW5jbHVk ZSBwYXJhbWV0ZXJzIHJlcXVpcmVkIGJ5IGxvY2FsIHJlZ3VsYXRvcnkgcG9saWN5LCBlLmcuIGRl dmljZSBJRCwgbWFudWZhY3R1cmVyJ3Mgc2VyaWFsIG51bWJlciwgY2hhbm5lbCB1c2FnZSBhbmQg cG93ZXIgbGV2ZWwgaW5mb3JtYXRpb24gb2YgdGhlIG1hc3RlciBhbmQgaXRzIHNsYXZlcy4NCg0K TmV3IHN0ZXBzIGNvdWxkIGJlIGludHJvZHVjZWQgaW50byBvbmUgb3IgbW9yZSB1c2UgY2FzZXMg dG8gY292ZXIgdGhlc2UgT2Zjb20gcmVxdWlyZW1lbnRzLCBlLmcuIG5ldyBzdGVwcyA2YmlzIGFu ZCA5YmlzIGluIHRoZSBob3RzcG90IHVzZSBjYXNlIGF0IDQuMi4xOg0KDQo2YmlzLiBQcmlvciB0 byBpbml0aWF0aW5nIHRyYW5zbWlzc2lvbiwgaWYgcmVxdWlyZWQgYnkgbG9jYWwgcmVndWxhdGlv biwgdGhlIG1hc3Rlci9BUCBpbmZvcm1zIHRoZSBkYXRhYmFzZSBvZiB0aGUgY2hhbm5lbCBhbmQg cG93ZXIgbGV2ZWwgaXQgaGFzIGNob3Nlbi4gVGhpcyBpcyByZXBlYXRlZCBmb3IgZWFjaCBzbGF2 ZSB0aGF0IGFzc29jaWF0ZWQgd2l0aCB0aGUgbWFzdGVyLg0KDQo5YmlzLiBQcmlvciB0byBpbml0 aWF0aW5nIHRyYW5zbWlzc2lvbiwgaWYgcmVxdWlyZWQgYnkgbG9jYWwgcmVndWxhdGlvbiwgdGhl IHNsYXZlIGluZm9ybXMgdGhlIG1hc3Rlci9BUCBvZiB0aGUgY2hhbm5lbCBhbmQgcG93ZXIgbGV2 ZWwgaXQgaGFzIGNob3NlbiwgYW5kIHRoZW1hc3Rlci9BUCByZWxheXMgdGhpcyBpbmZvcm1hdGlv biB0byB0aGUgZGF0YWJhc2UuDQoNCi0gZW5kIG9mIG5ldyB0ZXh0IC0NCg0KRm9yIGluZm9ybWF0 aW9uLCBmb3IgdGhvc2Ugbm90IGFjY2Vzc2luZyB0aGUgdXJsIGluIHRoZSBmaXJzdCBwYXJhZ3Jh cGggb2YgdGhpcyBlbWFpbCwgdGhlIGZ1bGwgT2Zjb20gcmVxdWlyZW1lbnRzIGxlYWRpbmcgdG8g dGhpcyBuZXcgUEFXUyB0ZXh0IGFyZSBhcyBmb2xsb3dzOg0KDQozLjE4IEFmdGVyIHJlY2Vpdmlu ZyBpbnN0cnVjdGlvbnMgZnJvbSBhIFdTREIgaW4gcmVsYXRpb24gdG8gdGhlIG1heGltdW0gcGVy bWl0dGVkIEVJUlBzIG92ZXIgdGhlIERUVCBjaGFubmVscywgYW5kIHByaW9yIHRvIGluaXRpYXRp bmcgdHJhbnNtaXNzaW9ucyB3aXRoaW4gdGhlIFVIRiBUViBiYW5kLCBhIG1hc3RlciBXU0QgbXVz dGNvbW11bmljYXRlIHRvIHRoZSBXU0RCIHRoZSBmb2xsb3dpbmcgaW5mb3JtYXRpb246DQozLjE4 LjEgVGhlIGxvd2VyIGFuZCB1cHBlciBmcmVxdWVuY3kgYm91bmRhcmllczEzIG9mIHRoZSBpbi1i bG9jayBlbWlzc2lvbnMgb2YgdGhlIG1hc3RlciBXU0QsIGFuZCB0aG9zZSBvZiB0aGUgaW4tYmxv Y2sgZW1pc3Npb25zIG9mIGl0cyBhc3NvY2lhdGVkIHNsYXZlcy4gQSBsb3dlciBmcmVxdWVuY3kg d2lsbCBiZSBzcGVjaWZpZWQgYXMgKDQ3MCArIDhrICsgMC4ybikgTUh6LCB3aXRoIHRoZSBjb3Jy ZXNwb25kaW5nIHVwcGVyIGZyZXF1ZW5jeSBzcGVjaWZpZWQgYXMgKDQ3MCArIDhrICsgMC4ybSkg TUh6LCB3aGVyZSAwIKHCIGsgocIgMzksIDAgocIgbiChwiAzOSwgMSChwiBtIKHCIDQwLCBhbmQg biA8IG0uDQozLjE4LjIgVGhlIG1heGltdW0gaW4tYmxvY2sgRUlSUCBzcGVjdHJhbCBkZW5zaXRp ZXMgKGluIGRCbS8oMC4yIE1IeikpIHRoYXQgdGhlIG1hc3RlcldTRCwgYW5kIGl0cyBhc3NvY2lh dGVkIHNsYXZlcywgYWN0dWFsbHkgcmFkaWF0ZSBiZXR3ZWVuIGVhY2ggcmVwb3J0ZWQgbG93ZXIg ZnJlcXVlbmN5IGJvdW5kYXJ5IGFuZCBpdHMgY29ycmVzcG9uZGluZyB1cHBlciBmcmVxdWVuY3kg Ym91bmRhcnkuDQoNCkZvb3Rub3RlIDEzIHN0YXRlczoNClRoZSB1c2Ugb2YgdXBwZXIgYW5kIGxv d2VyIGZyZXF1ZW5jeSBib3VuZGFyaWVzIChkZWZpbmVkIG92ZXIgYSAyMDAga0h6IHJhc3Rlcikg YWxsb3dzIGEgV1NEQiB0byBjb2xsZWN0IG1vcmUgZ3JhbnVsYXIgaW5mb3JtYXRpb24gd2l0aCBy ZWdhcmRzIHRvIHRoZSB1c2FnZSBvZiB0aGUgZnJlcXVlbmN5IHJlc291cmNlIGJ5bmFycm93YmFu ZCBXU0QgdGVjaG5vbG9naWVzLiBUaGUgdXBwZXIgYW5kIGxvd2VyIGZyZXF1ZW5jaWVzIG9mIGEg Ym91bmRhcnkgcGFpciBkbyBub3Qgc3RyYWRkbGUgYSBEVFQgY2hhbm5lbCBib3VuZGFyeS4gTm90 ZSB0aGF0IGEgV1NEIG1heSB0cmFuc21pdCBvdmVyIG11bHRpcGxlLCBub24tY29udGlndW91cywg d2hvbGUgRFRUIGNoYW5uZWxzIG9yIGZyYWN0aW9ucyBvZiBEVFQgY2hhbm5lbHMuDQoNCjMuMTkg QSBtYXN0ZXIgV1NEIG11c3QgYmUgYWJsZSB0byByZWNlaXZlIHRoZSBmb2xsb3dpbmcgaW5mb3Jt YXRpb24xNCBmcm9tIGEgV1NEQjoNCjxzbmlwPg0KMy4xOS44ICAgICBbQW4gYWNrbm93bGVkZ2Vt ZW50IGZyb20gdGhlIFdTREIsIGluIHRoZSBjb250ZXh0IG9mIDMuMTgsIHRoYXQgdGhlIHJlcG9y dGVkIGluZm9ybWF0aW9uIG9uIHRoZSBEVFQgY2hhbm5lbHMgYW5kIEVJUlAgc3BlY3RyYWwgZGVu c2l0aWVzIGFjdHVhbGx5IHVzZWQgYnkgdGhlIG1hc3RlciBhbmQgc2xhdmUgV1NEcyB3ZXJlIHJl Y2VpdmVkIHN1Y2Nlc3NmdWxseSBieSB0aGUgV1NEQjE4XS4NCg0KRm9vdG5vdGUgMTQgc3RhdGVz Og0KMTQgV2hpbGUgdGhlIGNvbW11bmljYXRpb24gb2Ygc29tZSBvZiB0aGlzIGluZm9ybWF0aW9u IGZyb20gYSBXU0RCIHRvIGEgbWFzdGVyIFdTRCBpcyBvcHRpb25hbCwgbWFzdGVyIFdTRHMgbXVz dCBiZSBhYmxlIHRvIHJlY2VpdmUgYW5kIGludGVycHJldCB0aGVzZS4NCg0KRm9vdG5vdGUgMTgg c3RhdGVzOg0KMTggVGhpcyBmb3JtcyBwYXJ0IG9mIGEgaGFuZHNoYWtlIHByb3RvY29sIGFuZCBt YXkgYmUgYW4gYXJlYSB3aGVyZSBpbmR1c3RyeSBjb3VsZCBoYXJtb25pc2Ugd2l0aG91dCB0aGUg bmVlZCBmb3IgYW4gZXhwbGljaXQgcmVxdWlyZW1lbnQgaW4gdGhlIHJlZ3VsYXRpb25zLg0KDQpS ZWdhcmRzDQoNCkFuZHkNCg0KRnJvbTogcGF3cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpwYXdz LWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgR2Fib3IuQmFqa29Abm9raWEuY29tPG1haWx0bzpHYWJvci5CYWprb0Bub2tpYS5jb20+ DQpTZW50OiAwNSBNYXJjaCAyMDEyIDE5OjQ2DQpUbzogcGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3 c0BpZXRmLm9yZz4NClN1YmplY3Q6IFtwYXdzXSBXR0xDIGZvciBkcmFmdC1pZXRmLXBhd3MtcHJv YmxlbS1zdG10LXVzZWNhc2VzLXJxbXRzLTAzDQoNCg0KVGhlIGF1dGhvcnMgb2YgdGhlIHVzZSBj YXNlcyBhbmQgcmVxdWlyZW1lbnRzIGRyYWZ0IGhhdmUganVzdCBwb3N0ZWQgYSBuZXcgdmVyc2lv biBvZiB0aGUgZHJhZnQgYW5kIGluZGljYXRlZCB0aGF0IHRoZXJlIGFyZSBubyB1bnJlc29sdmVk IGNvbW1lbnRzL2lzc3VlcyB0aGV5IGFyZSBhd2FyZSBvZi4NCg0KDQoNClRoZXJlZm9yZSwgSSdk IGxpa2UgdG8gaW5pdGlhdGUgYSBXRyBMYXN0IENhbGwgZm9yIGNvbW1lbnRzIG9uIGh0dHA6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtcGF3cy1wcm9ibGVtLXN0bXQt dXNlY2FzZXMtcnFtdHMtMDMudHh0DQoNCg0KDQpQbGVhc2UgcmV2aWV3IHRoZSBkcmFmdCBhbmQg c2VuZCB5b3VyY29tbWVudHMgdG8gdGhlIGxpc3QgYnkgTWFyY2ggMjB0aCwgMjAxMi4NCg0KDQoN CklmIHlvdSByZXZpZXcgdGhlIGRyYWZ0IGFuZCBoYXZlIG5vIGNvbW1lbnRzLCBzZW5kIGEgbm90 ZSB0byB0aGUgbGlzdCB0aGF0IHRoZSBkcmFmdCBpcyBnb29kIGFzIGl0IGlzLCB3ZSBuZWVkIHRo ZXNlIG5vdGVzIGFzIG11Y2ggYXMgd2UgbmVlZCB0aGUgYWN0dWFsIGNvbW1lbnRzLg0KDQoNCg0K VGhhbmtzLCBHYWJvcg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXyBwYXdzIG1haWxpbmcgbGlzdCBwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYu b3JnPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCg== --_000_CB7B9C411390Ascottprobasconokiacom_ Content-Type: text/html; charset="ks_c_5601-1987" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Gerald,

At least according to the FCC, a slave (Mode I) device may utilize cha= nnels that the master (fixed device) cannot use, see =A1=D715.707 and 15.71= 2. Thus there are potential situations where the master cannot be assumed t= o know what channel the slave is using. Although this is a bit esoteric as the FCC is silent about what the slave = might do on those channels, it is nonetheless included in the FCC regulatio= ns.

So I suggest we have no reason to overrule Ofcom requirements for chan= nel usage information. Also Andy's choice of words does ensure that this in= formation is not required to be used in every operational scenario.

Kind Regards,
Scott



From: ext Chouinard <gerald.chouinard@sympatico.ca>=
Date: Tue, 6 Mar 2012 11:44:07 -050= 0
To: ext com <andy.sago@bt.com>
Cc: "paws@ietf.org" <paws@i= etf.org>
Subject: Re: [paws] WGLC for draft-= ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting

Andy,

 

Looking at your suggestions below, it = seems that there is a need to define more precisely what a =A1=B0slave=A1= =B1 device is relative to its =A1=B0master=A1=B1.<= /p>

 

In my view, a slave can only use the s= ame transmission channel as that used by the master to which it is associat= ed (otherwise, master and slaves would not be able to talk to each other). As a consequence, the= slave does not have to indicate to the master the channel on which it is o= perating since the master knows it and can provided it to the database e.

 

Similarly, modern bidirectional commun= ication systems between a master and a slave device assumes that there will= be a transmit power control (TPC) loop between the two devices to minimize the required transm= it power in various propagation environments. The driving device in this cl= osed-loop process will be the master and as a result, the EIRP transmitted = by the slave device will be known to the master as long as there is a known factor linking the power specifi= cation sent by the master to the slave and the actual EIRP transmitted by t= he slave.  Such factor which is a constant for each device can be prov= ided from the slave to the master once at association.  As a result, the slave does not need to inform the m= aster of its current (and provably continuously varying) EIRP since the mas= ter will havethis information from its TPC process and can provide it to th= e database onbehalf of the slave device.

 

Gerald

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of andy.sago@bt.com
Sent: Tuesday, 06 March, 201= 2 10:42
To: paws@ietf.org; Gabor.Bajko@nokia.com
Subject: Re: [paws] WGLC for= draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting

 

= All

=  

= Comparing the= draft with the Ofcom requirements at http://www.cept.org/Documents/se-43/4161/SE43(= 12)Info03_Draft-UK-regulatory-requirements-for-white-space-devices-in-the-U= HF-TV-band, I believe the WG draft is deficient in the area of reporting frequencies a= nd powers actually used by masters and slaves (Ofcom requirements 3.18 and = 3.19.8). Ofcom intends to collect this data to assesses the impact of aggre= gate interference into other services. It would also provide usage information (frequency in use) that would info= rm the operation of a kill switch capability. I suggest this deficiency can= be remedied with the following changes:

=  

= New P require= ments (probably best placed following P.12):

=  

P.12bis: The protocol MUST support a channel usage message= from the slave device to the master device.  The channel usage message MUST include parameters as required by local regulat= ory requirement.  These parameters MAY include device ID, manufacturer= 's serial number, channel usage and power level information.

 

P.12ter: The protocol MUST support a channel usage message= from the master device to the database.  The channel usage message MUST include parameters as required by local regulatory requ= irement for the master and its associated slaves.  These parameters MA= Y include device ID, manufacturer's serial number, channel usage and power = level information.

 

P.12qua: The protocol MUST support a channel usage message= acknowledgement.

=  

= New O require= ments (probably best placed following O13):

=  

O.13bis:  According to local regulatory policy, after= connecting to a master device'sradio network a slave device MAY inform the master device of the actual channel usage. The slave= MUST include parameters required by local regulatory policy, e.g. device I= D, manufacturer's serial number, channel usage and power levelinformation.<= o:p>

 

O.13ter:  According to local regulatory policy, a mas= ter device MAY inform the database of the actual channel usage of the master and its slaves. The master MUST include parameters req= uired by local regulatory policy, e.g. device ID, manufacturer's serial num= ber, channel usage and power level information of the master and its slaves= .

=  

= New steps cou= ld be introduced into one or more use cases to cover these Ofcom requiremen= ts, e.g. new steps 6bis and 9bis in the hotspot use case at 4.2.1:

=  

6bis. Prior to initiating transmission, if required by loc= al regulation, the master/AP informs the database of the channel and power level it has chosen. This is repeated for each sl= ave that associated with the master.

 

9bis. Prior to initiating transmission, if required by loc= al regulation, the slave informs the master/AP of the channel and power level it has chosen, and themaster/AP relays this= information to the database.

=  

= - end of new = text -

=  

= For informati= on, for those not accessing the url in the first paragraph of this email, t= he full Ofcom requirements leading to this new PAWS text are as follows:

=  

= 3.18 After re= ceiving instructions from a WSDB in relation to the maximum permitted EIRPs= over the DTT channels, and prior to initiating transmissions within the UHF TV band, a master WSD mustcommunicate to the = WSDB the following information:

3.18.1 The lower and upper frequency boundaries13 of the in-block emissions of the master WSD, and those of the in-block emissions of its associated slaves. A lower freq= uency will be specified as (470 + 8k + 0.2n) MHz, with the correspo= nding upper frequency specified as (470 + 8k + 0.2m) MHz, where 0 = =A1=C2 k =A1=C2 39, 0 =A1=C2 n =A1=C2 39, 1 =A1=C2 m =A1=C2 40, and n < = m.

3.18.2 The maximum in-block EIRP spectral densities (in dB= m/(0.2 MHz)) that the masterWSD, and its associated slaves, actually radiate between each reported lower frequency boundary an= d its corresponding upper frequency boundary.

=  

= Footnote 13 s= tates:

= The use of up= per and lower frequency boundaries (defined over a 200 kHz raster) allows a= WSDB to collect more granular information with regards to the usage of the frequency resource bynarrowband WSD technologi= es. The upper and lower frequencies of a boundary pair do not straddle a DT= T channel boundary. Note that a WSD may transmit over multiple, non-contigu= ous, whole DTT channels or fractions of DTT channels.

=  

= 3.19 A master= WSD must be able to receive the following information14 from a = WSDB:

= <snip><= o:p>

3.19.8     [An acknowledgement from th= e WSDB, in the context of 3.18, that the reported information on the DTT channels and EIRP spectral densities actually used by the master and s= lave WSDs were received successfully by the WSDB18].<= /span>

=  

= Footnote 14 s= tates:

= 14 While the = communication of some of this information from a WSDB to a master WSD is op= tional, master WSDs must be able to receive and interpret these.

=  

= Footnote 18 s= tates:

= 18 This forms= part of a handshake protocol and may be an area where industry could harmo= nise without the need for an explicit requirement in the regulations.

=  

= Regards<= /o:p>

=  

= Andy

=  

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabo= r.Bajko@nokia.com
Sent: 05 March 2012 19:46 To: paws@ietf.org
Subject: [paws] WGLC for dra= ft-ietf-paws-problem-stmt-usecases-rqmts-03

 

The authors of the use cases and requirements draft have = just posted a new version of the draft and indicated that there are no unre= solved comments/issues they are aware of.

 

Therefore, I'd like to initia= te a WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-r= qmts-03.txt

 

Please review the draft and s= end yourcomments to the list by March 20th, 2012.<= /p>

 

If you review the draft and h= ave no comments, send a note to the list that the draft is good as it is, w= e need these notes as much as we need the actual comments.

 

Thanks, Gabor

 

_______________________________________________ paws mailing list paws@ietf.org ht= tps://www.ietf.org/mailman/listinfo/paws --_000_CB7B9C411390Ascottprobasconokiacom_-- From jmh@joelhalpern.com Tue Mar 6 09:04:49 2012 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 9596121F86BD for ; Tue, 6 Mar 2012 09:04:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.414 X-Spam-Level: X-Spam-Status: No, score=-101.414 tagged_above=-999 required=5 tests=[AWL=-0.576, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, 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 J4j8koBTnNqo for ; Tue, 6 Mar 2012 09:04:48 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9A321F8624 for ; Tue, 6 Mar 2012 09:04:47 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id F1AFDCD121 for ; Tue, 6 Mar 2012 09:04:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id C770E1C28D1; Tue, 6 Mar 2012 09:04:46 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.100] (pool-71-161-51-182.clppva.btas.verizon.net [71.161.51.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 813971C28CE; Tue, 6 Mar 2012 09:04:44 -0800 (PST) Message-ID: <4F5643A8.7000706@joelhalpern.com> Date: Tue, 06 Mar 2012 12:04:40 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: scott.probasco@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: paws@ietf.org, chris.cheeseman@bt.com, johnny.dixon@bt.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 17:04:49 -0000 Ahh. I think I see where the request and my understanding divurge. If the idea here is that the master must provide, in the request, an indication of what channels it expects to use, I can at least understand that. I will return to technical concerns in a moment. However, when you say "provide channel usage information, in order to evaluate interference", what that says to me is providing, during operation, information as to what channels are being used, and at what power levels. That is what would be needed to analyze actual interference effects. And that is out of scope as I understand our scope. I do see a technical difficulty with having the master provide, as part of either registering or requesting spectrum information, what channels it intends to use. It doesn;t know what channels it intends to use. It intends to use some number of available channels. It will figure out which ones when it is told what is available. How can it send that information in the request? Yours, Joel On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: > Hi, > > There is a similarity here with device ID. In context of PAWS we are not > concerned with why a device ID is required by a regulator, we accept it is > a requirement from a regulator and include it to the protocol. Ofcom > identifies in 3.18& 3.19 that channel usage information is required and > thus we need to include this information. Since the master must provide > this information prior to transmitting, PAWS will not function in the UK > without this information and thus I believe channel usage information is > integral to the channel request& response messaging. > > Kind Regards, > Scott > > > On 3/6/12 10:30 AM, "ext Joel M. Halpern" wrote: > >> I would draw a distinction. Ofcom regulations about whitespace requests >> are very much relevant. >> Ofcom regulations about notification of dynamic behavior (which spectrum >> is being used) are not in scope as I understand the earlier discussions, >> particularly the chartering discussions. >> >> Yours, >> Joel >> >> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: >>> >>> The ofcom requirements are very much relevant to the scope of the PAWS >>> WG. >>> The only other regulatory requirements that we have today is the FCC. >>> Ofcom requirements are a good addition to the set. >>> >>> -Raj >>> >>> On 3/6/12 10:03 AM, "ext andy.sago@bt.com" wrote: >>> >>>> Hi Joel >>>> >>>> There's no language I can find in the charter that explicitly puts this >>>> out of scope. On the other hand, the charter says that the group will >>>> "consider input from regulatory entities", and this is one of the >>>> requirements from Ofcom that they have just published. The protocol >>>> will >>>> be worthless for the UK if it omits some requirements. >>>> >>>> Regards >>>> >>>> Andy >>>> >>>> -----Original Message----- >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>> Sent: 06 March 2012 15:53 >>>> To: Sago,AJ,Andy,COD R >>>> Cc: paws@ietf.org; Gabor.Bajko@nokia.com >>>> Subject: Re: [paws] WGLC for >>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting >>>> >>>> As I understand, the information you are asking for is explicitly out >>>> of >>>> scope for the working group. >>>> Yours, >>>> Joel >>>> >>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >>>>> All >>>>> >>>>> Comparing the draft with the Ofcom requirements at >>>>> http://www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-regul >>>>> atory-requirements-for-white-space-devices-in-the-UHF-TV-band, >>>>> I believe the WG draft is deficient in the area of reporting >>>>> frequencies and powers actually used by masters and slaves (Ofcom >>>>> requirements 3.18 and 3.19.8). Ofcom intends to collect this data to >>>>> assesses the impact of aggregate interference into other services. It >>>>> would also provide usage information (frequency in use) that would >>>>> inform the operation of a kill switch capability. I suggest this >>>>> deficiency can be remedied with the following changes: >>>>> >>>>> New P requirements (probably best placed following P.12): >>>>> >>>>> P.12bis: The protocol MUST support a channel usage message from the >>>>> slave device to the master device. The channel usage message MUST >>>>> include parameters as required by local regulatory requirement. These >>>>> parameters MAY include device ID, manufacturer's serial number, >>>>> channel usage and power level information. >>>>> >>>>> P.12ter: The protocol MUST support a channel usage message from the >>>>> master device to the database. The channel usage message MUST include >>>>> parameters as required by local regulatory requirement for the master >>>>> and its associated slaves. These parameters MAY include device ID, >>>>> manufacturer's serial number, channel usage and power level >>>>> information. >>>>> >>>>> P.12qua: The protocol MUST support a channel usage message >>>>> acknowledgement. >>>>> >>>>> New O requirements (probably best placed following O13): >>>>> >>>>> O.13bis: According to local regulatory policy, after connecting to a >>>>> master device's radio network a slave device MAY inform the master >>>>> device of the actual channel usage. The slave MUST include parameters >>>>> required by local regulatory policy, e.g. device ID, manufacturer's >>>>> serial number, channel usage and power level information. >>>>> >>>>> O.13ter: According to local regulatory policy, a master device MAY >>>>> inform the database of the actual channel usage of the master and its >>>>> slaves. The master MUST include parameters required by local >>>>> regulatory policy, e.g. device ID, manufacturer's serial number, >>>>> channel usage and power level information of the master and its >>>>> slaves. >>>>> >>>>> New steps could be introduced into one or more use cases to cover >>>>> these Ofcom requirements, e.g. new steps 6bis and 9bis in the hotspot >>>>> use case at 4.2.1: >>>>> >>>>> 6bis. Prior to initiating transmission, if required by local >>>>> regulation, the master/AP informs the database of the channel and >>>>> power level it has chosen. This is repeated for each slave that >>>>> associated with the master. >>>>> >>>>> 9bis. Prior to initiating transmission, if required by local >>>>> regulation, the slave informs the master/AP of the channel and power >>>>> level it has chosen, and the master/AP relays this information to the >>>>> database. >>>>> >>>>> - end of new text - >>>>> >>>>> For information, for those not accessing the url in the first >>>>> paragraph of this email, the full Ofcom requirements leading to this >>>>> new PAWS text are as follows: >>>>> >>>>> 3.18 After receiving instructions from a WSDB in relation to the >>>>> maximum permitted EIRPs over the DTT channels, and prior to initiating >>>>> transmissions within the UHF TV band, a master WSD must communicate to >>>>> the WSDB the following information: >>>>> >>>>> 3.18.1 The lower and upper frequency boundaries^13 of the in-block >>>>> emissions of the master WSD, and those of the in-block emissions of >>>>> its associated slaves. A lower frequency will be specified as (470 + >>>>> 8k + >>>>> 0.2n) MHz, with the corresponding upper frequency specified as (470 + >>>>> 8k >>>>> + 0.2m) MHz, where 0 3Ž4 k 3Ž4 39, 0 3Ž4 n 3Ž4 39, 1 3Ž4 m 3Ž4 40, and n< m. >>>>> >>>>> 3.18.2 The maximum in-block EIRP spectral densities (in dBm/(0.2 MHz)) >>>>> that the master WSD, and its associated slaves, actually radiate >>>>> between each reported lower frequency boundary and its corresponding >>>>> upper frequency boundary. >>>>> >>>>> Footnote 13 states: >>>>> >>>>> The use of upper and lower frequency boundaries (defined over a 200 >>>>> kHz >>>>> raster) allows a WSDB to collect more granular information with >>>>> regards to the usage of the frequency resource by narrowband WSD >>>>> technologies. >>>>> The upper and lower frequencies of a boundary pair do not straddle a >>>>> DTT channel boundary. Note that a WSD may transmit over multiple, >>>>> non-contiguous, whole DTT channels or fractions of DTT channels. >>>>> >>>>> 3.19 A master WSD must be able to receive the following information^14 >>>>> from a WSDB: >>>>> >>>>> >>>>> >>>>> 3.19.8 [An acknowledgement from the WSDB, in the context of 3.18, >>>>> that the reported information on the DTT channels and EIRP spectral >>>>> densities actually used by the master and slave WSDs were received >>>>> successfully by the WSDB^18 ]. >>>>> >>>>> Footnote 14 states: >>>>> >>>>> 14 While the communication of some of this information from a WSDB to >>>>> a master WSD is optional, master WSDs must be able to receive and >>>>> interpret these. >>>>> >>>>> Footnote 18 states: >>>>> >>>>> 18 This forms part of a handshake protocol and may be an area where >>>>> industry could harmonise without the need for an explicit requirement >>>>> in the regulations. >>>>> >>>>> Regards >>>>> >>>>> Andy >>>>> >>>>> *From:*paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf >>>>> Of *Gabor.Bajko@nokia.com >>>>> *Sent:* 05 March 2012 19:46 >>>>> *To:* paws@ietf.org >>>>> *Subject:* [paws] WGLC for >>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >>>>> >>>>> The authors of the use cases and requirements draft have just posted a >>>>> new version of the draft and indicated that there are no unresolved >>>>> comments/issues they are aware of. >>>>> >>>>> Therefore, I'd like to initiate a WG Last Call for comments on >>>>> http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-useca >>>>> ses-rqmts-03.txt >>>>> >>>>> >>>>> Please review the draft and send your comments to the list by March >>>>> 20th, 2012. >>>>> >>>>> If you review the draft and have no comments, send a note to the list >>>>> that the draft is good as it is, we need these notes as much as we >>>>> need the actual comments. >>>>> >>>>> Thanks, Gabor >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>> >>> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws > > From andy.sago@bt.com Tue Mar 6 09:10:07 2012 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 7516921E8098 for ; Tue, 6 Mar 2012 09:10:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.555 X-Spam-Level: X-Spam-Status: No, score=-1.555 tagged_above=-999 required=5 tests=[AWL=-1.137, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_66=0.6, MIME_BASE64_TEXT=1.753, 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 0IwaJ7W0wgAZ for ; Tue, 6 Mar 2012 09:10:05 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id AF32A21E808C for ; Tue, 6 Mar 2012 09:10:04 -0800 (PST) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 6 Mar 2012 17:10:02 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.196]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Tue, 6 Mar 2012 17:10:02 +0000 From: To: , Date: Tue, 6 Mar 2012 17:10:02 +0000 Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting Thread-Index: AQHM+7qBJZkKE/OsEE6WAJSH4Dz7PpZdfuvQ Message-ID: <619CDADDCCD2B44380834BE8BF6F714140691460FA@EMV62-UKRD.domain1.systemhost.net> References: 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_619CDADDCCD2B44380834BE8BF6F714140691460FAEMV62UKRDdoma_" MIME-Version: 1.0 Cc: paws@ietf.org Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 17:10:07 -0000 --_000_619CDADDCCD2B44380834BE8BF6F714140691460FAEMV62UKRDdoma_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 VGhhbmtzIFNjb3R0IGFuZCBHZXJhbGQNCg0KSSBhZ3JlZSB3aXRoIEdlcmFsZCB0aGF0IEkgY2Fu IHRoaW5rIG9mIHRlY2hub2xvZ2llcyB3aGVyZSB0aGUgbWFzdGVyIHdpbGwgaGF2ZSBhbiBleGNl bGxlbnQgdmlldyBvZiB0aGUgc2xhdmUgZnJlcXVlbmNpZXMgYW5kIHBvd2VyIGxldmVscywgYW5k IGNhbiBpbmRpY2F0ZSBmcmVxdWVuY2llcyBhbmQgKHBlcmhhcHMgbWF4KSBwb3dlciBsZXZlbHMg YmFjayB0byB0aGUgZGF0YWJhc2UsIHdpdGhvdXQgdGhlIG5lZWQgZm9yIHRoZSBzbGF2ZXMgdG8g c2VuZCBhIG1lc3NhZ2UgZnJvbSBzbGF2ZSB0byBtYXN0ZXIuIEluIHRob3NlIG5ldHdvcmtzLCB0 aGUgcHJvcG9zZWQgUDEyLmJpcyB3b3VsZCBub3QgYmUgcmVxdWlyZWQuICBCdXQgSSB3b3VsZG6h r3QgbGlrZSB0byBhbnRpY2lwYXRlIHdoYXQgdGVjaG5vbG9naWVzIHdpbGwgYmUgdXNlZCBpbiBU VldTLCBzbyBJIGluY2x1ZGVkIHRoaXMgbWVzc2FnZS4gSXQgd2lsbCBoYXZlIHZlcnkgc2ltaWxh ciBzdHJ1Y3R1cmUgdG8gdGhlIG1hc3Rlci10by1kYXRhYmFzZSBtZXNzYWdlIHNvIHdpbGwgY2F1 c2UgbGl0dGxlIG92ZXJoZWFkIGluIHByb3RvY29sIGRldmVsb3BtZW50Lg0KDQpSZWdhcmRzDQoN CkFuZHkNCg0KRnJvbTogc2NvdHQucHJvYmFzY29Abm9raWEuY29tIFttYWlsdG86c2NvdHQucHJv YmFzY29Abm9raWEuY29tXQ0KU2VudDogMDYgTWFyY2ggMjAxMiAxNzowMA0KVG86IGdlcmFsZC5j aG91aW5hcmRAc3ltcGF0aWNvLmNhOyBTYWdvLEFKLEFuZHksQ09EIFINCkNjOiBwYXdzQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW3Bhd3NdIFdHTEMgZm9yIGRyYWZ0LWlldGYtcGF3cy1wcm9ibGVt LXN0bXQtdXNlY2FzZXMtcnFtdHMtMDM6IGNoYW5uZWwgcmVwb3J0aW5nDQoNCkhpIEdlcmFsZCwN Cg0KQXQgbGVhc3QgYWNjb3JkaW5nIHRvIHRoZSBGQ0MsIGEgc2xhdmUgKE1vZGUgSSkgZGV2aWNl IG1heSB1dGlsaXplIGNoYW5uZWxzIHRoYXQgdGhlIG1hc3RlciAoZml4ZWQgZGV2aWNlKSBjYW5u b3QgdXNlLCBzZWUgoewxNS43MDcgYW5kIDE1LjcxMi4gVGh1cyB0aGVyZSBhcmUgcG90ZW50aWFs IHNpdHVhdGlvbnMgd2hlcmUgdGhlIG1hc3RlciBjYW5ub3QgYmUgYXNzdW1lZCB0byBrbm93IHdo YXQgY2hhbm5lbCB0aGUgc2xhdmUgaXMgdXNpbmcuIEFsdGhvdWdoIHRoaXMgaXMgYSBiaXQgZXNv dGVyaWMgYXMgdGhlIEZDQyBpcyBzaWxlbnQgYWJvdXQgd2hhdCB0aGUgc2xhdmUgbWlnaHQgZG8g b24gdGhvc2UgY2hhbm5lbHMsIGl0IGlzIG5vbmV0aGVsZXNzIGluY2x1ZGVkIGluIHRoZSBGQ0Mg cmVndWxhdGlvbnMuDQoNClNvIEkgc3VnZ2VzdCB3ZSBoYXZlIG5vIHJlYXNvbiB0byBvdmVycnVs ZSBPZmNvbSByZXF1aXJlbWVudHMgZm9yIGNoYW5uZWwgdXNhZ2UgaW5mb3JtYXRpb24uIEFsc28g QW5keSdzIGNob2ljZSBvZiB3b3JkcyBkb2VzIGVuc3VyZSB0aGF0IHRoaXMgaW5mb3JtYXRpb24g aXMgbm90IHJlcXVpcmVkIHRvIGJlIHVzZWQgaW4gZXZlcnkgb3BlcmF0aW9uYWwgc2NlbmFyaW8u DQoNCktpbmQgUmVnYXJkcywNClNjb3R0DQoNCg0KDQpGcm9tOiBleHQgQ2hvdWluYXJkIDxnZXJh bGQuY2hvdWluYXJkQHN5bXBhdGljby5jYTxtYWlsdG86Z2VyYWxkLmNob3VpbmFyZEBzeW1wYXRp Y28uY2E+Pg0KRGF0ZTogVHVlLCA2IE1hciAyMDEyIDExOjQ0OjA3IC0wNTAwDQpUbzogZXh0IGNv bSA8YW5keS5zYWdvQGJ0LmNvbTxtYWlsdG86YW5keS5zYWdvQGJ0LmNvbT4+DQpDYzogInBhd3NA aWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+IiA8cGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3 c0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3Bhd3NdIFdHTEMgZm9yIGRyYWZ0LWlldGYtcGF3 cy1wcm9ibGVtLXN0bXQtdXNlY2FzZXMtcnFtdHMtMDM6IGNoYW5uZWwgcmVwb3J0aW5nDQoNCkFu ZHksDQoNCkxvb2tpbmcgYXQgeW91ciBzdWdnZXN0aW9ucyBiZWxvdywgaXQgc2VlbXMgdGhhdCB0 aGVyZSBpcyBhIG5lZWQgdG8gZGVmaW5lIG1vcmUgcHJlY2lzZWx5IHdoYXQgYSChsHNsYXZlobEg ZGV2aWNlIGlzIHJlbGF0aXZlIHRvIGl0cyChsG1hc3RlcqGxLg0KDQpJbiBteSB2aWV3LCBhIHNs YXZlIGNhbiBvbmx5IHVzZSB0aGUgc2FtZSB0cmFuc21pc3Npb24gY2hhbm5lbCBhcyB0aGF0IHVz ZWQgYnkgdGhlIG1hc3RlciB0byB3aGljaCBpdCBpcyBhc3NvY2lhdGVkIChvdGhlcndpc2UsIG1h c3RlciBhbmQgc2xhdmVzIHdvdWxkIG5vdCBiZSBhYmxlIHRvIHRhbGsgdG8gZWFjaCBvdGhlciku IEFzIGEgY29uc2VxdWVuY2UsIHRoZSBzbGF2ZSBkb2VzIG5vdCBoYXZlIHRvIGluZGljYXRlIHRv IHRoZSBtYXN0ZXIgdGhlIGNoYW5uZWwgb24gd2hpY2ggaXQgaXMgb3BlcmF0aW5nIHNpbmNlIHRo ZSBtYXN0ZXIga25vd3MgaXQgYW5kIGNhbiBwcm92aWRlZCBpdCB0byB0aGUgZGF0YWJhc2UgZS4N Cg0KU2ltaWxhcmx5LCBtb2Rlcm4gYmlkaXJlY3Rpb25hbCBjb21tdW5pY2F0aW9uIHN5c3RlbXMg YmV0d2VlbiBhIG1hc3RlciBhbmQgYSBzbGF2ZSBkZXZpY2UgYXNzdW1lcyB0aGF0IHRoZXJlIHdp bGwgYmUgYSB0cmFuc21pdCBwb3dlciBjb250cm9sIChUUEMpIGxvb3AgYmV0d2VlbiB0aGUgdHdv IGRldmljZXMgdG8gbWluaW1pemUgdGhlIHJlcXVpcmVkIHRyYW5zbWl0IHBvd2VyIGluIHZhcmlv dXMgcHJvcGFnYXRpb24gZW52aXJvbm1lbnRzLiBUaGUgZHJpdmluZyBkZXZpY2UgaW4gdGhpcyBj bG9zZWQtbG9vcCBwcm9jZXNzIHdpbGwgYmUgdGhlIG1hc3RlciBhbmQgYXMgYSByZXN1bHQsIHRo ZSBFSVJQIHRyYW5zbWl0dGVkIGJ5IHRoZSBzbGF2ZSBkZXZpY2Ugd2lsbCBiZSBrbm93biB0byB0 aGUgbWFzdGVyIGFzIGxvbmcgYXMgdGhlcmUgaXMgYSBrbm93biBmYWN0b3IgbGlua2luZyB0aGUg cG93ZXIgc3BlY2lmaWNhdGlvbiBzZW50IGJ5IHRoZSBtYXN0ZXIgdG8gdGhlIHNsYXZlIGFuZCB0 aGUgYWN0dWFsIEVJUlAgdHJhbnNtaXR0ZWQgYnkgdGhlIHNsYXZlLiAgU3VjaCBmYWN0b3Igd2hp Y2ggaXMgYSBjb25zdGFudCBmb3IgZWFjaCBkZXZpY2UgY2FuIGJlIHByb3ZpZGVkIGZyb20gdGhl IHNsYXZlIHRvIHRoZSBtYXN0ZXIgb25jZSBhdCBhc3NvY2lhdGlvbi4gIEFzIGEgcmVzdWx0LCB0 aGUgc2xhdmUgZG9lcyBub3QgbmVlZCB0byBpbmZvcm0gdGhlIG1hc3RlciBvZiBpdHMgY3VycmVu dCAoYW5kIHByb3ZhYmx5IGNvbnRpbnVvdXNseSB2YXJ5aW5nKSBFSVJQIHNpbmNlIHRoZSBtYXN0 ZXIgd2lsbCBoYXZldGhpcyBpbmZvcm1hdGlvbiBmcm9tIGl0cyBUUEMgcHJvY2VzcyBhbmQgY2Fu IHByb3ZpZGUgaXQgdG8gdGhlIGRhdGFiYXNlIG9uYmVoYWxmIG9mIHRoZSBzbGF2ZSBkZXZpY2Uu DQoNCkdlcmFsZA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogcGF3 cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86 cGF3cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgYW5keS5zYWdvQGJ0LmNvbTxtYWls dG86YW5keS5zYWdvQGJ0LmNvbT4NClNlbnQ6IFR1ZXNkYXksIDA2IE1hcmNoLCAyMDEyIDEwOjQy DQpUbzogcGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz47IEdhYm9yLkJhamtvQG5v a2lhLmNvbTxtYWlsdG86R2Fib3IuQmFqa29Abm9raWEuY29tPg0KU3ViamVjdDogUmU6IFtwYXdz XSBXR0xDIGZvciBkcmFmdC1pZXRmLXBhd3MtcHJvYmxlbS1zdG10LXVzZWNhc2VzLXJxbXRzLTAz OiBjaGFubmVsIHJlcG9ydGluZw0KDQpBbGwNCg0KQ29tcGFyaW5nIHRoZSBkcmFmdCB3aXRoIHRo ZSBPZmNvbSByZXF1aXJlbWVudHMgYXQgaHR0cDovL3d3dy5jZXB0Lm9yZy9Eb2N1bWVudHMvc2Ut NDMvNDE2MS9TRTQzKDEyKUluZm8wM19EcmFmdC1VSy1yZWd1bGF0b3J5LXJlcXVpcmVtZW50cy1m b3Itd2hpdGUtc3BhY2UtZGV2aWNlcy1pbi10aGUtVUhGLVRWLWJhbmQsIEkgYmVsaWV2ZSB0aGUg V0cgZHJhZnQgaXMgZGVmaWNpZW50IGluIHRoZSBhcmVhIG9mIHJlcG9ydGluZyBmcmVxdWVuY2ll cyBhbmQgcG93ZXJzIGFjdHVhbGx5IHVzZWQgYnkgbWFzdGVycyBhbmQgc2xhdmVzIChPZmNvbSBy ZXF1aXJlbWVudHMgMy4xOCBhbmQgMy4xOS44KS4gT2Zjb20gaW50ZW5kcyB0byBjb2xsZWN0IHRo aXMgZGF0YSB0byBhc3Nlc3NlcyB0aGUgaW1wYWN0IG9mIGFnZ3JlZ2F0ZSBpbnRlcmZlcmVuY2Ug aW50byBvdGhlciBzZXJ2aWNlcy4gSXQgd291bGQgYWxzbyBwcm92aWRlIHVzYWdlIGluZm9ybWF0 aW9uIChmcmVxdWVuY3kgaW4gdXNlKSB0aGF0IHdvdWxkIGluZm9ybSB0aGUgb3BlcmF0aW9uIG9m IGEga2lsbCBzd2l0Y2ggY2FwYWJpbGl0eS4gSSBzdWdnZXN0IHRoaXMgZGVmaWNpZW5jeSBjYW4g YmUgcmVtZWRpZWQgd2l0aCB0aGUgZm9sbG93aW5nIGNoYW5nZXM6DQoNCk5ldyBQIHJlcXVpcmVt ZW50cyAocHJvYmFibHkgYmVzdCBwbGFjZWQgZm9sbG93aW5nIFAuMTIpOg0KDQpQLjEyYmlzOiBU aGUgcHJvdG9jb2wgTVVTVCBzdXBwb3J0IGEgY2hhbm5lbCB1c2FnZSBtZXNzYWdlIGZyb20gdGhl IHNsYXZlIGRldmljZSB0byB0aGUgbWFzdGVyIGRldmljZS4gIFRoZSBjaGFubmVsIHVzYWdlIG1l c3NhZ2UgTVVTVCBpbmNsdWRlIHBhcmFtZXRlcnMgYXMgcmVxdWlyZWQgYnkgbG9jYWwgcmVndWxh dG9yeSByZXF1aXJlbWVudC4gIFRoZXNlIHBhcmFtZXRlcnMgTUFZIGluY2x1ZGUgZGV2aWNlIElE LCBtYW51ZmFjdHVyZXIncyBzZXJpYWwgbnVtYmVyLCBjaGFubmVsIHVzYWdlIGFuZCBwb3dlciBs ZXZlbCBpbmZvcm1hdGlvbi4NCg0KUC4xMnRlcjogVGhlIHByb3RvY29sIE1VU1Qgc3VwcG9ydCBh IGNoYW5uZWwgdXNhZ2UgbWVzc2FnZSBmcm9tIHRoZSBtYXN0ZXIgZGV2aWNlIHRvIHRoZSBkYXRh YmFzZS4gIFRoZSBjaGFubmVsIHVzYWdlIG1lc3NhZ2UgTVVTVCBpbmNsdWRlIHBhcmFtZXRlcnMg YXMgcmVxdWlyZWQgYnkgbG9jYWwgcmVndWxhdG9yeSByZXF1aXJlbWVudCBmb3IgdGhlIG1hc3Rl ciBhbmQgaXRzIGFzc29jaWF0ZWQgc2xhdmVzLiAgVGhlc2UgcGFyYW1ldGVycyBNQVkgaW5jbHVk ZSBkZXZpY2UgSUQsIG1hbnVmYWN0dXJlcidzIHNlcmlhbCBudW1iZXIsIGNoYW5uZWwgdXNhZ2Ug YW5kIHBvd2VyIGxldmVsIGluZm9ybWF0aW9uLg0KDQpQLjEycXVhOiBUaGUgcHJvdG9jb2wgTVVT VCBzdXBwb3J0IGEgY2hhbm5lbCB1c2FnZSBtZXNzYWdlIGFja25vd2xlZGdlbWVudC4NCg0KTmV3 IE8gcmVxdWlyZW1lbnRzIChwcm9iYWJseSBiZXN0IHBsYWNlZCBmb2xsb3dpbmcgTzEzKToNCg0K Ty4xM2JpczogIEFjY29yZGluZyB0byBsb2NhbCByZWd1bGF0b3J5IHBvbGljeSwgYWZ0ZXIgY29u bmVjdGluZyB0byBhIG1hc3RlciBkZXZpY2Unc3JhZGlvIG5ldHdvcmsgYSBzbGF2ZSBkZXZpY2Ug TUFZIGluZm9ybSB0aGUgbWFzdGVyIGRldmljZSBvZiB0aGUgYWN0dWFsIGNoYW5uZWwgdXNhZ2Uu IFRoZSBzbGF2ZSBNVVNUIGluY2x1ZGUgcGFyYW1ldGVycyByZXF1aXJlZCBieSBsb2NhbCByZWd1 bGF0b3J5IHBvbGljeSwgZS5nLiBkZXZpY2UgSUQsIG1hbnVmYWN0dXJlcidzIHNlcmlhbCBudW1i ZXIsIGNoYW5uZWwgdXNhZ2UgYW5kIHBvd2VyIGxldmVsaW5mb3JtYXRpb24uDQoNCk8uMTN0ZXI6 ICBBY2NvcmRpbmcgdG8gbG9jYWwgcmVndWxhdG9yeSBwb2xpY3ksIGEgbWFzdGVyIGRldmljZSBN QVkgaW5mb3JtIHRoZSBkYXRhYmFzZSBvZiB0aGUgYWN0dWFsIGNoYW5uZWwgdXNhZ2Ugb2YgdGhl IG1hc3RlciBhbmQgaXRzIHNsYXZlcy4gVGhlIG1hc3RlciBNVVNUIGluY2x1ZGUgcGFyYW1ldGVy cyByZXF1aXJlZCBieSBsb2NhbCByZWd1bGF0b3J5IHBvbGljeSwgZS5nLiBkZXZpY2UgSUQsIG1h bnVmYWN0dXJlcidzIHNlcmlhbCBudW1iZXIsIGNoYW5uZWwgdXNhZ2UgYW5kIHBvd2VyIGxldmVs IGluZm9ybWF0aW9uIG9mIHRoZSBtYXN0ZXIgYW5kIGl0cyBzbGF2ZXMuDQoNCk5ldyBzdGVwcyBj b3VsZCBiZSBpbnRyb2R1Y2VkIGludG8gb25lIG9yIG1vcmUgdXNlIGNhc2VzIHRvIGNvdmVyIHRo ZXNlIE9mY29tIHJlcXVpcmVtZW50cywgZS5nLiBuZXcgc3RlcHMgNmJpcyBhbmQgOWJpcyBpbiB0 aGUgaG90c3BvdCB1c2UgY2FzZSBhdCA0LjIuMToNCg0KNmJpcy4gUHJpb3IgdG8gaW5pdGlhdGlu ZyB0cmFuc21pc3Npb24sIGlmIHJlcXVpcmVkIGJ5IGxvY2FsIHJlZ3VsYXRpb24sIHRoZSBtYXN0 ZXIvQVAgaW5mb3JtcyB0aGUgZGF0YWJhc2Ugb2YgdGhlIGNoYW5uZWwgYW5kIHBvd2VyIGxldmVs IGl0IGhhcyBjaG9zZW4uIFRoaXMgaXMgcmVwZWF0ZWQgZm9yIGVhY2ggc2xhdmUgdGhhdCBhc3Nv Y2lhdGVkIHdpdGggdGhlIG1hc3Rlci4NCg0KOWJpcy4gUHJpb3IgdG8gaW5pdGlhdGluZyB0cmFu c21pc3Npb24sIGlmIHJlcXVpcmVkIGJ5IGxvY2FsIHJlZ3VsYXRpb24sIHRoZSBzbGF2ZSBpbmZv cm1zIHRoZSBtYXN0ZXIvQVAgb2YgdGhlIGNoYW5uZWwgYW5kIHBvd2VyIGxldmVsIGl0IGhhcyBj aG9zZW4sIGFuZCB0aGVtYXN0ZXIvQVAgcmVsYXlzIHRoaXMgaW5mb3JtYXRpb24gdG8gdGhlIGRh dGFiYXNlLg0KDQotIGVuZCBvZiBuZXcgdGV4dCAtDQoNCkZvciBpbmZvcm1hdGlvbiwgZm9yIHRo b3NlIG5vdCBhY2Nlc3NpbmcgdGhlIHVybCBpbiB0aGUgZmlyc3QgcGFyYWdyYXBoIG9mIHRoaXMg ZW1haWwsIHRoZSBmdWxsIE9mY29tIHJlcXVpcmVtZW50cyBsZWFkaW5nIHRvIHRoaXMgbmV3IFBB V1MgdGV4dCBhcmUgYXMgZm9sbG93czoNCg0KMy4xOCBBZnRlciByZWNlaXZpbmcgaW5zdHJ1Y3Rp b25zIGZyb20gYSBXU0RCIGluIHJlbGF0aW9uIHRvIHRoZSBtYXhpbXVtIHBlcm1pdHRlZCBFSVJQ cyBvdmVyIHRoZSBEVFQgY2hhbm5lbHMsIGFuZCBwcmlvciB0byBpbml0aWF0aW5nIHRyYW5zbWlz c2lvbnMgd2l0aGluIHRoZSBVSEYgVFYgYmFuZCwgYSBtYXN0ZXIgV1NEIG11c3Rjb21tdW5pY2F0 ZSB0byB0aGUgV1NEQiB0aGUgZm9sbG93aW5nIGluZm9ybWF0aW9uOg0KMy4xOC4xIFRoZSBsb3dl ciBhbmQgdXBwZXIgZnJlcXVlbmN5IGJvdW5kYXJpZXMxMyBvZiB0aGUgaW4tYmxvY2sgZW1pc3Np b25zIG9mIHRoZSBtYXN0ZXIgV1NELCBhbmQgdGhvc2Ugb2YgdGhlIGluLWJsb2NrIGVtaXNzaW9u cyBvZiBpdHMgYXNzb2NpYXRlZCBzbGF2ZXMuIEEgbG93ZXIgZnJlcXVlbmN5IHdpbGwgYmUgc3Bl Y2lmaWVkIGFzICg0NzAgKyA4ayArIDAuMm4pIE1Ieiwgd2l0aCB0aGUgY29ycmVzcG9uZGluZyB1 cHBlciBmcmVxdWVuY3kgc3BlY2lmaWVkIGFzICg0NzAgKyA4ayArIDAuMm0pIE1Ieiwgd2hlcmUg MCCh3CBrIKHcIDM5LCAwIKHcIG4godwgMzksIDEgodwgbSCh3CA0MCwgYW5kIG4gPCBtLg0KMy4x OC4yIFRoZSBtYXhpbXVtIGluLWJsb2NrIEVJUlAgc3BlY3RyYWwgZGVuc2l0aWVzIChpbiBkQm0v KDAuMiBNSHopKSB0aGF0IHRoZSBtYXN0ZXJXU0QsIGFuZCBpdHMgYXNzb2NpYXRlZCBzbGF2ZXMs IGFjdHVhbGx5IHJhZGlhdGUgYmV0d2VlbiBlYWNoIHJlcG9ydGVkIGxvd2VyIGZyZXF1ZW5jeSBi b3VuZGFyeSBhbmQgaXRzIGNvcnJlc3BvbmRpbmcgdXBwZXIgZnJlcXVlbmN5IGJvdW5kYXJ5Lg0K DQpGb290bm90ZSAxMyBzdGF0ZXM6DQpUaGUgdXNlIG9mIHVwcGVyIGFuZCBsb3dlciBmcmVxdWVu Y3kgYm91bmRhcmllcyAoZGVmaW5lZCBvdmVyIGEgMjAwIGtIeiByYXN0ZXIpIGFsbG93cyBhIFdT REIgdG8gY29sbGVjdCBtb3JlIGdyYW51bGFyIGluZm9ybWF0aW9uIHdpdGggcmVnYXJkcyB0byB0 aGUgdXNhZ2Ugb2YgdGhlIGZyZXF1ZW5jeSByZXNvdXJjZSBieW5hcnJvd2JhbmQgV1NEIHRlY2hu b2xvZ2llcy4gVGhlIHVwcGVyIGFuZCBsb3dlciBmcmVxdWVuY2llcyBvZiBhIGJvdW5kYXJ5IHBh aXIgZG8gbm90IHN0cmFkZGxlIGEgRFRUIGNoYW5uZWwgYm91bmRhcnkuIE5vdGUgdGhhdCBhIFdT RCBtYXkgdHJhbnNtaXQgb3ZlciBtdWx0aXBsZSwgbm9uLWNvbnRpZ3VvdXMsIHdob2xlIERUVCBj aGFubmVscyBvciBmcmFjdGlvbnMgb2YgRFRUIGNoYW5uZWxzLg0KDQozLjE5IEEgbWFzdGVyIFdT RCBtdXN0IGJlIGFibGUgdG8gcmVjZWl2ZSB0aGUgZm9sbG93aW5nIGluZm9ybWF0aW9uMTQgZnJv bSBhIFdTREI6DQo8c25pcD4NCjMuMTkuOCAgICAgW0FuIGFja25vd2xlZGdlbWVudCBmcm9tIHRo ZSBXU0RCLCBpbiB0aGUgY29udGV4dCBvZiAzLjE4LCB0aGF0IHRoZSByZXBvcnRlZCBpbmZvcm1h dGlvbiBvbiB0aGUgRFRUIGNoYW5uZWxzIGFuZCBFSVJQIHNwZWN0cmFsIGRlbnNpdGllcyBhY3R1 YWxseSB1c2VkIGJ5IHRoZSBtYXN0ZXIgYW5kIHNsYXZlIFdTRHMgd2VyZSByZWNlaXZlZCBzdWNj ZXNzZnVsbHkgYnkgdGhlIFdTREIxOF0uDQoNCkZvb3Rub3RlIDE0IHN0YXRlczoNCjE0IFdoaWxl IHRoZSBjb21tdW5pY2F0aW9uIG9mIHNvbWUgb2YgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIGEgV1NE QiB0byBhIG1hc3RlciBXU0QgaXMgb3B0aW9uYWwsIG1hc3RlciBXU0RzIG11c3QgYmUgYWJsZSB0 byByZWNlaXZlIGFuZCBpbnRlcnByZXQgdGhlc2UuDQoNCkZvb3Rub3RlIDE4IHN0YXRlczoNCjE4 IFRoaXMgZm9ybXMgcGFydCBvZiBhIGhhbmRzaGFrZSBwcm90b2NvbCBhbmQgbWF5IGJlIGFuIGFy ZWEgd2hlcmUgaW5kdXN0cnkgY291bGQgaGFybW9uaXNlIHdpdGhvdXQgdGhlIG5lZWQgZm9yIGFu IGV4cGxpY2l0IHJlcXVpcmVtZW50IGluIHRoZSByZWd1bGF0aW9ucy4NCg0KUmVnYXJkcw0KDQpB bmR5DQoNCkZyb206IHBhd3MtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cGF3cy1ib3VuY2VzQGll dGYub3JnPiBbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdhYm9y LkJhamtvQG5va2lhLmNvbTxtYWlsdG86R2Fib3IuQmFqa29Abm9raWEuY29tPg0KU2VudDogMDUg TWFyY2ggMjAxMiAxOTo0Ng0KVG86IHBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBbcGF3c10gV0dMQyBmb3IgZHJhZnQtaWV0Zi1wYXdzLXByb2JsZW0tc3RtdC11 c2VjYXNlcy1ycW10cy0wMw0KDQoNClRoZSBhdXRob3JzIG9mIHRoZSB1c2UgY2FzZXMgYW5kIHJl cXVpcmVtZW50cyBkcmFmdCBoYXZlIGp1c3QgcG9zdGVkIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRy YWZ0IGFuZCBpbmRpY2F0ZWQgdGhhdCB0aGVyZSBhcmUgbm8gdW5yZXNvbHZlZCBjb21tZW50cy9p c3N1ZXMgdGhleSBhcmUgYXdhcmUgb2YuDQoNCg0KDQpUaGVyZWZvcmUsIEknZCBsaWtlIHRvIGlu aXRpYXRlIGEgV0cgTGFzdCBDYWxsIGZvciBjb21tZW50cyBvbiBodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXBhd3MtcHJvYmxlbS1zdG10LXVzZWNhc2VzLXJx bXRzLTAzLnR4dA0KDQoNCg0KUGxlYXNlIHJldmlldyB0aGUgZHJhZnQgYW5kIHNlbmQgeW91cmNv bW1lbnRzIHRvIHRoZSBsaXN0IGJ5IE1hcmNoIDIwdGgsIDIwMTIuDQoNCg0KDQpJZiB5b3UgcmV2 aWV3IHRoZSBkcmFmdCBhbmQgaGF2ZSBubyBjb21tZW50cywgc2VuZCBhIG5vdGUgdG8gdGhlIGxp c3QgdGhhdCB0aGUgZHJhZnQgaXMgZ29vZCBhcyBpdCBpcywgd2UgbmVlZCB0aGVzZSBub3RlcyBh cyBtdWNoIGFzIHdlIG5lZWQgdGhlIGFjdHVhbCBjb21tZW50cy4NCg0KDQoNClRoYW5rcywgR2Fi b3INCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gcGF3 cyBtYWlsaW5nIGxpc3QgcGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo= --_000_619CDADDCCD2B44380834BE8BF6F714140691460FAEMV62UKRDdoma_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Thanks Scott and Gerald

&= nbsp;

I agree with Gerald that I can think of technologies where t= he master will have an excellent view of the slave frequencies and power le= vels, and can indicate frequencies and (perhaps max) power levels back to t= he database, without the need for the slaves to send a message from slave t= o master. In those networks, the proposed P12.bis would not be required. &n= bsp;But I wouldn=A1=AFt like to anticipate what technologies will be used i= n TVWS, so I included this message. It will have very similar structure to = the master-to-database message so will cause little overhead in protocol de= velopment.

 

<= span style=3D'font-size:12.0pt;color:#1F497D'>Regards

=

&n= bsp;

Andy

 

=

From: scott.probasco@nokia.com= [mailto:scott.probasco@nokia.com]
Sent: 06 March 2012 17:00
= To: gerald.chouinard@sympatico.ca; Sago,AJ,Andy,COD R
Cc: = paws@ietf.org
Subject: Re: [paws] WGLC for draft-ietf-paws-proble= m-stmt-usecases-rqmts-03: channel reporting

 

Hi Gerald,

<= o:p> 

At least according to the FCC, a slave (Mode I= ) device may utilize channels that the master (fixed device) cannot use, se= e =A1=EC15.707 and 15.712. Thus there are potential situations where the ma= ster cannot be assumed to know what channel the slave is using. Although th= is is a bit esoteric as the FCC is silent about what the slave might do on = those channels, it is nonetheless included in the FCC regulations.

 

= So I suggest we have no reason= to overrule Ofcom requirements for channel usage information. Also Andy's = choice of words does ensure that this information is not required to be use= d in every operational scenario.

 =

Kind Regards,

Scott

 

 

 =

From: ext Chouinard <gerald.chouinard@sympatico.ca= >
Date: Tue, 6 Mar 2012 11:44:07 -0500
To: ext c= om <andy.sago@bt.com>
C= c: "paws@ietf.org" <<= a href=3D"mailto:paws@ietf.org">paws@ietf.org>
Subject: Re= : [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel r= eporting

 

Andy,

=  

Looking at your suggestions below, it = seems that there is a need to define more precisely what a =A1=B0slave=A1= =B1 device is relative to its =A1=B0master=A1=B1.

 

In my view, a slave can only use = the same transmission channel as that used by the master to which it is ass= ociated (otherwise, master and slaves would not be able to talk to each oth= er). As a consequence, the slave does not have to indicate to the master th= e channel on which it is operating since the master knows it and can provid= ed it to the database e.

 

Similarly, modern bidirectional communication systems betw= een a master and a slave device assumes that there will be a transmit power= control (TPC) loop between the two devices to minimize the required transm= it power in various propagation environments. The driving device in this cl= osed-loop process will be the master and as a result, the EIRP transmitted = by the slave device will be known to the master as long as there is a known= factor linking the power specification sent by the master to the slave and= the actual EIRP transmitted by the slave.  Such factor which is a con= stant for each device can be provided from the slave to the master once at = association.  As a result, the slave does not need to inform the maste= r of its current (and provably continuously varying) EIRP since the master = will havethis information from its TPC process and can provide it to the da= tabase onbehalf of the slave device.

 

Gerald

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of andy.sago@bt.com
Sent:= Tuesday, 06 March, 2012 10:42
To: paws@ietf.org; Gabor.Ba= jko@nokia.com
Subject: Re: [paws] WGLC for draft-ietf-paws-pr= oblem-stmt-usecases-rqmts-03: channel reporting

 

All

=  

Comparing the draft with the Ofcom= requirements at http://www.cept.org/Documents= /se-43/4161/SE43(12)Info03_Draft-UK-regulatory-requirements-for-white-space= -devices-in-the-UHF-TV-band, I believe the WG draft is deficient in the area of reporting fr= equencies and powers actually used by masters and slaves (Ofcom requirement= s 3.18 and 3.19.8). Ofcom intends to collect this data to assesses the impa= ct of aggregate interference into other services. It would also provide usa= ge information (frequency in use) that would inform the operation of a kill= switch capability. I suggest this deficiency can be remedied with the foll= owing changes:

 <= /p>

New = P requirements (probably best placed following P.12):

 

P.12bis: Th= e protocol MUST support a channel usage message from the slave device to th= e master device.  The channel usage message MUST include parameters as= required by local regulatory requirement.  These parameters MAY inclu= de device ID, manufacturer's serial number, channel usage and power level i= nformation.

 

P.12ter: The protocol MU= ST support a channel usage message from the master device to the database.&= nbsp; The channel usage message MUST include parameters as required by loca= l regulatory requirement for the master and its associated slaves.  Th= ese parameters MAY include device ID, manufacturer's serial number, channel= usage and power level information.

 

= P.12qua: The protocol MUST support a channel usage message acknowledgement.=

 

New O requirements= (probably best placed following O13):

 

O.13bis:  According t= o local regulatory policy, after connecting to a master device'sradio netwo= rk a slave device MAY inform the master device of the actual channel usage.= The slave MUST include parameters required by local regulatory policy, e.g= . device ID, manufacturer's serial number, channel usage and power levelinf= ormation.=

 

O.13ter:  According t= o local regulatory policy, a master device MAY inform the database of the a= ctual channel usage of the master and its slaves. The master MUST include p= arameters required by local regulatory policy, e.g. device ID, manufacturer= 's serial number, channel usage and power level information of the master a= nd its slaves.

 <= /p>

New = steps could be introduced into one or more use cases to cover these Ofcom r= equirements, e.g. new steps 6bis and 9bis in the hotspot use case at 4.2.1:=

 

6bis. Prior to initiating transmission, if required by local reg= ulation, the master/AP informs the database of the channel and power level = it has chosen. This is repeated for each slave that associated with the mas= ter.

<= p class=3DMsoNormal style=3D'margin-left:36.0pt'> =

9bis. Prior to initiating trans= mission, if required by local regulation, the slave informs the master/AP o= f the channel and power level it has chosen, and themaster/AP relays this i= nformation to the database.

 =

- end of new text -

 

For information, for those not accessing the url in the first pa= ragraph of this email, the full Ofcom requirements leading to this new PAWS= text are as follows:<= /o:p>

 <= /span>

3.18 After receiving instructions from a WSDB in relation to the maximum= permitted EIRPs over the DTT channels, and prior to initiating transmissio= ns within the UHF TV band, a master WSD mustcommunicate to the WSDB the fol= lowing information:

3.18.1 The lower and upper frequency bo= undaries13 of the in-block emissions of the master WSD, and thos= e of the in-block emissions of its associated slaves. A lower frequency wil= l be specified as (470 + 8k + 0.2n) MHz, with the corresponding upper frequ= ency specified as (470 + 8k + 0.2m) MHz, where 0 =A1=DC k =A1=DC 39, 0 =A1= =DC n =A1=DC 39, 1 =A1=DC m =A1=DC 40, and n < m.

3.18= .2 The maximum in-block EIRP spectral densities (in dBm/(0.2 MHz)) that the= masterWSD, and its associated slaves, actually radiate between each report= ed lower frequency boundary and its corresponding upper frequency boundary.=

 

Footnote 13 states= :

The use of = upper and lower frequency boundaries (defined over a 200 kHz raster) allows= a WSDB to collect more granular information with regards to the usage of t= he frequency resource bynarrowband WSD technologies. The upper and lower fr= equencies of a boundary pair do not straddle a DTT channel boundary. Note t= hat a WSD may transmit over multiple, non-contiguous, whole DTT channels or= fractions of DTT channels.=

 <= /o:p>

3.19 A master WSD must be able to receive the following informatio= n14 from a WSDB:=

<snip>=

3.19.8     = [An acknowledgement from the WSDB, in the context of 3.18, that the reporte= d information on the DTT channels and EIRP spectral densities actually used= by the master and slave WSDs were received successfully by the WSDB18= ].<= /p>

&nbs= p;

Footnote 1= 4 states:=

14 = While the communication of some of this information from a WSDB to a master= WSD is optional, master WSDs must be able to receive and interpret these.<= /span>

 =

Footnote 18 states:=

18 This form= s part of a handshake protocol and may be an area where industry could harm= onise without the need for an explicit requirement in the regulations.

 

Regards

 

Andy

 

<= b>From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com
Sent:= 05 March 2012 19:46
To: paws@ie= tf.org
Subject: [paws] WGLC for draft-ietf-paws-problem-stmt-= usecases-rqmts-03

&n= bsp;

<= p class=3DMsoPlainText>The authors= of the use cases and requirements draft have just posted a new version of = the draft and indicated that there are no unresolved comments/issues they a= re aware of.

 

Therefore, I'd like to initiate a= WG Last Call for comments on http://www.ietf.org/i= nternet-drafts/draft-ietf-paws-problem-stmt-usecases-rqmts-03.txt<= /o:p>

 

Please review the draft and send yourcomments to th= e list by March 20th, 2012.

 

If you review the = draft and have no comments, send a note to the list that the draft is good = as it is, we need these notes as much as we need the actual comments.<= /o:p>

 

Thanks, Gabor

 

<= /div>

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

= --_000_619CDADDCCD2B44380834BE8BF6F714140691460FAEMV62UKRDdoma_-- From gerald.chouinard@sympatico.ca Tue Mar 6 09:13:11 2012 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 5C00C21E807F for ; Tue, 6 Mar 2012 09:13:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.214 X-Spam-Level: X-Spam-Status: No, score=0.214 tagged_above=-999 required=5 tests=[AWL=1.182, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, MSGID_FROM_MTA_HEADER=0.803, 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 bGbC8olkHKNN for ; Tue, 6 Mar 2012 09:13:09 -0800 (PST) Received: from blu0-omc3-s2.blu0.hotmail.com (blu0-omc3-s2.blu0.hotmail.com [65.55.116.77]) by ietfa.amsl.com (Postfix) with ESMTP id 63DC521E8087 for ; Tue, 6 Mar 2012 09:13:09 -0800 (PST) Received: from BLU0-SMTP75 ([65.55.116.74]) by blu0-omc3-s2.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Mar 2012 09:13:08 -0800 X-Originating-IP: [174.95.242.231] X-Originating-Email: [gerald.chouinard@sympatico.ca] Message-ID: Received: from Gerald2 ([174.95.242.231]) by BLU0-SMTP75.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Mar 2012 09:13:07 -0800 From: Gerald Chouinard To: References: Date: Tue, 6 Mar 2012 12:13:05 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D9_01CCFB92.7D38E760" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AQHM+7qBJZkKE/OsEE6WAJSH4Dz7PpZdfy+A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 06 Mar 2012 17:13:07.0829 (UTC) FILETIME=[66755250:01CCFBBC] Cc: paws@ietf.org Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 17:13:11 -0000 ------=_NextPart_000_00D9_01CCFB92.7D38E760 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Scott, =20 I am fine with your approach as long as the text says something as = follows: =A1=B0the operating channel of the slave needs to be provided to the = database=A1=B1 rather than: =A1=B0the slave needs to provide the database with its = operating channel=A1=B1. This way, this information can be provided by either the = slave or the master, not making it mandatory that the =A1=B0slave=A1=B1 has to = do it if the master knows the information. =20 The text proposed by Andy: =A1=B0The protocol MUST support a channel = usage message from the slave device to the master device.=A1=B1 Implies that = the protocol to be developed needs to apply on the connection between the = slave and the master. Such connection should be implementation dependant. = What is required is that the information be available to the master for it to transmit it to the database, never mind the format that is used between = the slave and the master to carry this information. =20 Gerald =20 _____ =20 From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com]=20 Sent: Tuesday, 06 March, 2012 12:00 To: gerald.chouinard@sympatico.ca; andy.sago@bt.com Cc: paws@ietf.org Subject: Re: [paws] WGLC for = draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting =20 Hi Gerald, =20 At least according to the FCC, a slave (Mode I) device may utilize = channels that the master (fixed device) cannot use, see =A1=EC15.707 and 15.712. = Thus there are potential situations where the master cannot be assumed to = know what channel the slave is using. Although this is a bit esoteric as the = FCC is silent about what the slave might do on those channels, it is = nonetheless included in the FCC regulations. =20 So I suggest we have no reason to overrule Ofcom requirements for = channel usage information. Also Andy's choice of words does ensure that this information is not required to be used in every operational scenario. =20 Kind Regards, Scott =20 =20 =20 From: ext Chouinard Date: Tue, 6 Mar 2012 11:44:07 -0500 To: ext com Cc: "paws@ietf.org" Subject: Re: [paws] WGLC for = draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting =20 Andy, =20 Looking at your suggestions below, it seems that there is a need to = define more precisely what a =A1=B0slave=A1=B1 device is relative to its = =A1=B0master=A1=B1. =20 In my view, a slave can only use the same transmission channel as that = used by the master to which it is associated (otherwise, master and slaves = would not be able to talk to each other). As a consequence, the slave does not have to indicate to the master the channel on which it is operating = since the master knows it and can provided it to the database e. =20 Similarly, modern bidirectional communication systems between a master = and a slave device assumes that there will be a transmit power control (TPC) = loop between the two devices to minimize the required transmit power in = various propagation environments. The driving device in this closed-loop process will be the master and as a result, the EIRP transmitted by the slave = device will be known to the master as long as there is a known factor linking = the power specification sent by the master to the slave and the actual EIRP transmitted by the slave. Such factor which is a constant for each = device can be provided from the slave to the master once at association. As a result, the slave does not need to inform the master of its current (and provably continuously varying) EIRP since the master will havethis information from its TPC process and can provide it to the database = onbehalf of the slave device. =20 Gerald =20 _____ =20 From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of andy.sago@bt.com Sent: Tuesday, 06 March, 2012 10:42 To: paws@ietf.org; Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for = draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting =20 All =20 Comparing the draft with the Ofcom requirements at http://www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-regulato= ry- requirements-for-white-space-devices-in-the-UHF-TV-band, I believe the = WG draft is deficient in the area of reporting frequencies and powers = actually used by masters and slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom intends to collect this data to assesses the impact of aggregate interference into other services. It would also provide usage = information (frequency in use) that would inform the operation of a kill switch capability. I suggest this deficiency can be remedied with the following changes: =20 New P requirements (probably best placed following P.12): =20 P.12bis: The protocol MUST support a channel usage message from the = slave device to the master device. The channel usage message MUST include parameters as required by local regulatory requirement. These = parameters MAY include device ID, manufacturer's serial number, channel usage and = power level information. =20 P.12ter: The protocol MUST support a channel usage message from the = master device to the database. The channel usage message MUST include = parameters as required by local regulatory requirement for the master and its associated slaves. These parameters MAY include device ID, = manufacturer's serial number, channel usage and power level information. =20 P.12qua: The protocol MUST support a channel usage message = acknowledgement. =20 New O requirements (probably best placed following O13): =20 O.13bis: According to local regulatory policy, after connecting to a = master device'sradio network a slave device MAY inform the master device of the actual channel usage. The slave MUST include parameters required by = local regulatory policy, e.g. device ID, manufacturer's serial number, channel usage and power levelinformation. =20 O.13ter: According to local regulatory policy, a master device MAY = inform the database of the actual channel usage of the master and its slaves. = The master MUST include parameters required by local regulatory policy, e.g. device ID, manufacturer's serial number, channel usage and power level information of the master and its slaves. =20 New steps could be introduced into one or more use cases to cover these Ofcom requirements, e.g. new steps 6bis and 9bis in the hotspot use case = at 4.2.1: =20 6bis. Prior to initiating transmission, if required by local regulation, = the master/AP informs the database of the channel and power level it has = chosen. This is repeated for each slave that associated with the master. =20 9bis. Prior to initiating transmission, if required by local regulation, = the slave informs the master/AP of the channel and power level it has = chosen, and themaster/AP relays this information to the database.=20 =20 - end of new text - =20 For information, for those not accessing the url in the first paragraph = of this email, the full Ofcom requirements leading to this new PAWS text = are as follows: =20 3.18 After receiving instructions from a WSDB in relation to the maximum permitted EIRPs over the DTT channels, and prior to initiating = transmissions within the UHF TV band, a master WSD mustcommunicate to the WSDB the following information: 3.18.1 The lower and upper frequency boundaries13 of the in-block = emissions of the master WSD, and those of the in-block emissions of its associated slaves. A lower frequency will be specified as (470 + 8k + 0.2n) MHz, = with the corresponding upper frequency specified as (470 + 8k + 0.2m) MHz, = where 0 =A1=DC k =A1=DC 39, 0 =A1=DC n =A1=DC 39, 1 =A1=DC m =A1=DC 40, and n = < m. 3.18.2 The maximum in-block EIRP spectral densities (in dBm/(0.2 MHz)) = that the masterWSD, and its associated slaves, actually radiate between each reported lower frequency boundary and its corresponding upper frequency boundary. =20 Footnote 13 states: The use of upper and lower frequency boundaries (defined over a 200 kHz raster) allows a WSDB to collect more granular information with regards = to the usage of the frequency resource bynarrowband WSD technologies. The = upper and lower frequencies of a boundary pair do not straddle a DTT channel boundary. Note that a WSD may transmit over multiple, non-contiguous, = whole DTT channels or fractions of DTT channels. =20 3.19 A master WSD must be able to receive the following information14 = from a WSDB: 3.19.8 [An acknowledgement from the WSDB, in the context of 3.18, = that the reported information on the DTT channels and EIRP spectral densities actually used by the master and slave WSDs were received successfully by = the WSDB18]. =20 Footnote 14 states: 14 While the communication of some of this information from a WSDB to a master WSD is optional, master WSDs must be able to receive and = interpret these. =20 Footnote 18 states: 18 This forms part of a handshake protocol and may be an area where = industry could harmonise without the need for an explicit requirement in the regulations. =20 Regards =20 Andy =20 From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com Sent: 05 March 2012 19:46 To: paws@ietf.org Subject: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03 =20 The authors of the use cases and requirements draft have just posted a = new version of the draft and indicated that there are no unresolved comments/issues they are aware of. =20 Therefore, I'd like to initiate a WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases= -rq mts-03.txt =20 Please review the draft and send yourcomments to the list by March 20th, 2012. =20 If you review the draft and have no comments, send a note to the list = that the draft is good as it is, we need these notes as much as we need the actual comments. =20 Thanks, Gabor =20 _______________________________________________ paws mailing list = paws@ietf. org https://www.ietf.org/mailman/listinfo/paws=20 ------=_NextPart_000_00D9_01CCFB92.7D38E760 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Scott,

 

I am fine with your approach as = long as the text says something as follows: =A1=B0the operating channel of the = slave needs to be provided to the database=A1=B1 rather than: =A1=B0the slave needs = to provide the database with its operating channel=A1=B1.  This way, this = information can be provided by either the slave or the master, not making it mandatory that = the =A1=B0slave=A1=B1 has to do it if the master knows the = information.

 

The text proposed by Andy: = =A1=B0The protocol MUST support a channel usage message from the slave device to = the master device.=A1=B1 Implies that the protocol to be developed needs to = apply on the connection between the slave and the master. Such connection should be = implementation dependant.  What is required is that the information be available = to the master for it to transmit it to the database, never mind the format that = is used between the slave and the master to carry this = information.

 

Gerald

 

From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com]
Sent: Tuesday, 06 March, = 2012 12:00
To: gerald.chouinard@sympatico.ca; andy.sago@bt.com
Cc: paws@ietf.org
Subject: Re: [paws] WGLC = for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel = reporting

 

Hi = Gerald,

 

At least according to the FCC, a = slave (Mode I) device may utilize channels that the master (fixed device) = cannot use, see =A1=EC15.707 and 15.712. Thus there are potential situations where = the master cannot be assumed to know what channel the slave is using. Although this = is a bit esoteric as the FCC is silent about what the slave might do on those channels, it is nonetheless included in the FCC = regulations.

 

So I suggest we have no reason to = overrule Ofcom requirements for channel usage information. Also Andy's choice of = words does ensure that this information is not required to be used in every operational scenario.

 

Kind = Regards,

Scott

=

 

 

 

From: ext Chouinard <gerald.chouinard@sympatico.= ca>
Date: Tue, 6 Mar 2012 = 11:44:07 -0500
To: ext com <andy.sago@bt.com>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] WGLC = for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel = reporting

 

Andy,

 

Looking at your suggestions below, = it seems that there is a need to define more precisely what a = =A1=B0slave=A1=B1 device is relative to its =A1=B0master=A1=B1.

 

In my view, a slave can only use = the same transmission channel as that used by the master to which it is = associated (otherwise, master and slaves would not be able to talk to each other). = As a consequence, the slave does not have to indicate to the master the = channel on which it is operating since the master knows it and can provided it to = the database e.

 

Similarly, modern bidirectional communication systems between a master and a slave device assumes that = there will be a transmit power control (TPC) loop between the two devices to = minimize the required transmit power in various propagation environments. The = driving device in this closed-loop process will be the master and as a result, = the EIRP transmitted by the slave device will be known to the master as long as = there is a known factor linking the power specification sent by the master to the = slave and the actual EIRP transmitted by the slave.  Such factor which is = a constant for each device can be provided from the slave to the master = once at association.  As a result, the slave does not need to inform the = master of its current (and provably continuously varying) EIRP since the master = will havethis information from its TPC process and can provide it to the = database onbehalf of the slave device.

 

Gerald

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] = On Behalf Of andy.sago@bt.com
Sent: Tuesday, 06 March, = 2012 10:42
To: paws@ietf.org; Gabor.Bajko@nokia.com
Subject: Re: [paws] WGLC = for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel = reporting

 

All

 

Comparing the draft with the = Ofcom requirements at http:= //www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-regulatory-re= quirements-for-white-space-devices-in-the-UHF-TV-band, I believe the WG draft is deficient in the area of reporting frequencies = and powers actually used by masters and slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom intends to collect this data to assesses the impact of = aggregate interference into other services. It would also provide usage = information (frequency in use) that would inform the operation of a kill switch = capability. I suggest this deficiency can be remedied with the following = changes:

 

New P requirements (probably = best placed following P.12):

 

P.12bis: The protocol MUST support a channel usage message from the slave device = to the master device.  The channel usage message MUST include parameters = as required by local regulatory requirement.  These parameters MAY = include device ID, manufacturer's serial number, channel usage and power level information.

 

P.12ter: The protocol MUST support a channel usage message from the master device = to the database.  The channel usage message MUST include parameters as = required by local regulatory requirement for the master and its associated = slaves.  These parameters MAY include device ID, manufacturer's serial number, = channel usage and power level information.

 

P.12qua: The protocol MUST support a channel usage message = acknowledgement.

 

New O requirements (probably = best placed following O13):

 

O.13bis:  According to local regulatory policy, after connecting to a master device'sradio network a slave device MAY inform the master device of the = actual channel usage. The slave MUST include parameters required by local = regulatory policy, e.g. device ID, manufacturer's serial number, channel usage and = power levelinformation.

 

O.13ter:  According to local regulatory policy, a master device MAY inform the = database of the actual channel usage of the master and its slaves. The master = MUST include parameters required by local regulatory policy, e.g. device ID, manufacturer's serial number, channel usage and power level information = of the master and its slaves.

 

New steps could be introduced = into one or more use cases to cover these Ofcom requirements, e.g. new steps 6bis = and 9bis in the hotspot use case at 4.2.1:

 

6bis. Prior to initiating transmission, if required by local regulation, the master/AP informs the database of the channel and power level it has = chosen. This is repeated for each slave that associated with the = master.

 

9bis. Prior to initiating transmission, if required by local regulation, the = slave informs the master/AP of the channel and power level it has chosen, and themaster/AP relays this information to the database. =

 

- end of new text = -

 

For information, for those not = accessing the url in the first paragraph of this email, the full Ofcom = requirements leading to this new PAWS text are as follows:

 

3.18 After receiving = instructions from a WSDB in relation to the maximum permitted EIRPs over the DTT channels, = and prior to initiating transmissions within the UHF TV band, a master WSD mustcommunicate to the WSDB the following = information:

3.18.1 The lower and upper frequency boundaries13 of the in-block = emissions of the master WSD, and those of the in-block emissions of its associated = slaves. A lower frequency will be specified as (470 + 8k + 0.2n) MHz, with the corresponding upper frequency specified as (470 + 8k + 0.2m) MHz, where = 0 =A1=DC k =A1=DC 39, 0 =A1=DC n =A1=DC 39, 1 =A1=DC m =A1=DC 40, and n < = m.

3.18.2 The maximum in-block EIRP spectral densities (in dBm/(0.2 MHz)) that the = masterWSD, and its associated slaves, actually radiate between each reported lower frequency boundary and its corresponding upper frequency = boundary.

 

Footnote 13 = states:

The use of upper and lower = frequency boundaries (defined over a 200 kHz raster) allows a WSDB to collect more granular information with regards to the usage of the frequency resource bynarrowband WSD technologies. The upper and lower frequencies of a = boundary pair do not straddle a DTT channel boundary. Note that a WSD may = transmit over multiple, non-contiguous, whole DTT channels or fractions of DTT = channels.

 

3.19 A master WSD must be able = to receive the following information14 from a = WSDB:

<snip>=

3.19.8     [An acknowledgement from the WSDB, in the context of 3.18, that the = reported information on the DTT channels and EIRP spectral densities actually = used by the master and slave WSDs were received successfully by the = WSDB18].

 

Footnote 14 = states:

14 While the communication of = some of this information from a WSDB to a master WSD is optional, master WSDs = must be able to receive and interpret these.

 

Footnote 18 = states:

18 This forms part of a = handshake protocol and may be an area where industry could harmonise without the = need for an explicit requirement in the = regulations.

 

Regards

 

Andy<= font color=3Dblack>

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] = On Behalf Of Gabor.Bajko@nokia.com
Sent: 05 March 2012 = 19:46
To: paws@ietf.org
Subject: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03=

 

The authors of the use cases and requirements draft have just posted a new version of the draft and = indicated that there are no unresolved comments/issues they are aware = of.

 

Therefore, I'd like to initiate a = WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paw= s-problem-stmt-usecases-rqmts-03.txt

 

Please review the draft and send yourcomments to the list by March 20th, = 2012.

 

If you review the draft and have = no comments, send a note to the list that the draft is good as it is, we = need these notes as much as we need the actual = comments.

 

Thanks, = Gabor

 

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

------=_NextPart_000_00D9_01CCFB92.7D38E760-- From andy.sago@bt.com Tue Mar 6 09:29:01 2012 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 ED80921F88DA for ; Tue, 6 Mar 2012 09:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[AWL=-0.820, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, 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 wojSpFF-nGgA for ; Tue, 6 Mar 2012 09:29:00 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0E521F88CA for ; Tue, 6 Mar 2012 09:29:00 -0800 (PST) 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.213.0; Tue, 6 Mar 2012 17:28:59 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.196]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Tue, 6 Mar 2012 17:28:59 +0000 From: To: , Date: Tue, 6 Mar 2012 17:28:59 +0000 Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting Thread-Index: Acz7uz96mRV3vyADQue+Shqk6WG+lwAAM19w Message-ID: <619CDADDCCD2B44380834BE8BF6F71414069146126@EMV62-UKRD.domain1.systemhost.net> References: <4F5643A8.7000706@joelhalpern.com> In-Reply-To: <4F5643A8.7000706@joelhalpern.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="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: paws@ietf.org, johnny.dixon@bt.com, chris.cheeseman@bt.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 17:29:02 -0000 Joel Indeed, the regulator has not described the process or provided a flow diag= ram, so there may be some wrinkles, but we need to provide for their intent= . To answer your question, the channels that the master will use are sent i= n a separate message (described in P.12 ter), that occurs after the master = receives the response to its channel request, but before the master can tra= nsmit. At this point, it knows what channels are available, and which one i= t will use. As far as the slaves are concerned, as they associate, the mast= er will need to gather their details and send further channel usage message= s to the database on their behalf.=20 Regards Andy -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Joe= l M. Halpern Sent: 06 March 2012 17:05 To: scott.probasco@nokia.com Cc: paws@ietf.org; Cheeseman,CJ,Chris,COD R; Dixon,JS,Johnny,COD R Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03= : channel reporting Ahh. I think I see where the request and my understanding divurge. If the idea here is that the master must provide, in the request, an indica= tion of what channels it expects to use, I can at least understand that. I= will return to technical concerns in a moment. However, when you say "provide channel usage information, in order to evalu= ate interference", what that says to me is providing, during operation, inf= ormation as to what channels are being used, and at what power levels. Tha= t is what would be needed to analyze actual interference effects. And that is out of scope as I understand our scope. I do see a technical difficulty with having the master provide, as part of = either registering or requesting spectrum information, what channels it int= ends to use. It doesn;t know what channels it intends to use. It intends = to use some number of available channels. It will figure out which ones wh= en it is told what is available. How can it send that information in the r= equest? Yours, Joel On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: > Hi, > > There is a similarity here with device ID. In context of PAWS we are=20 > not concerned with why a device ID is required by a regulator, we=20 > accept it is a requirement from a regulator and include it to the=20 > protocol. Ofcom identifies in 3.18& 3.19 that channel usage=20 > information is required and thus we need to include this information.=20 > Since the master must provide this information prior to transmitting,=20 > PAWS will not function in the UK without this information and thus I=20 > believe channel usage information is integral to the channel request& re= sponse messaging. > > Kind Regards, > Scott > > > On 3/6/12 10:30 AM, "ext Joel M. Halpern" wrote: > >> I would draw a distinction. Ofcom regulations about whitespace=20 >> requests are very much relevant. >> Ofcom regulations about notification of dynamic behavior (which=20 >> spectrum is being used) are not in scope as I understand the earlier=20 >> discussions, particularly the chartering discussions. >> >> Yours, >> Joel >> >> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: >>> >>> The ofcom requirements are very much relevant to the scope of the=20 >>> PAWS WG. >>> The only other regulatory requirements that we have today is the FCC. >>> Ofcom requirements are a good addition to the set. >>> >>> -Raj >>> >>> On 3/6/12 10:03 AM, "ext andy.sago@bt.com" wrote: >>> >>>> Hi Joel >>>> >>>> There's no language I can find in the charter that explicitly puts=20 >>>> this out of scope. On the other hand, the charter says that the=20 >>>> group will "consider input from regulatory entities", and this is=20 >>>> one of the requirements from Ofcom that they have just published.=20 >>>> The protocol will be worthless for the UK if it omits some=20 >>>> requirements. >>>> >>>> Regards >>>> >>>> Andy >>>> >>>> -----Original Message----- >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>> Sent: 06 March 2012 15:53 >>>> To: Sago,AJ,Andy,COD R >>>> Cc: paws@ietf.org; Gabor.Bajko@nokia.com >>>> Subject: Re: [paws] WGLC for >>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting >>>> >>>> As I understand, the information you are asking for is explicitly=20 >>>> out of scope for the working group. >>>> Yours, >>>> Joel >>>> >>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >>>>> All >>>>> >>>>> Comparing the draft with the Ofcom requirements at=20 >>>>> http://www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-r >>>>> egul=20 >>>>> atory-requirements-for-white-space-devices-in-the-UHF-TV-band, >>>>> I believe the WG draft is deficient in the area of reporting=20 >>>>> frequencies and powers actually used by masters and slaves (Ofcom=20 >>>>> requirements 3.18 and 3.19.8). Ofcom intends to collect this data=20 >>>>> to assesses the impact of aggregate interference into other=20 >>>>> services. It would also provide usage information (frequency in=20 >>>>> use) that would inform the operation of a kill switch capability.=20 >>>>> I suggest this deficiency can be remedied with the following changes: >>>>> >>>>> New P requirements (probably best placed following P.12): >>>>> >>>>> P.12bis: The protocol MUST support a channel usage message from=20 >>>>> the slave device to the master device. The channel usage message=20 >>>>> MUST include parameters as required by local regulatory=20 >>>>> requirement. These parameters MAY include device ID,=20 >>>>> manufacturer's serial number, channel usage and power level informati= on. >>>>> >>>>> P.12ter: The protocol MUST support a channel usage message from=20 >>>>> the master device to the database. The channel usage message MUST=20 >>>>> include parameters as required by local regulatory requirement for=20 >>>>> the master and its associated slaves. These parameters MAY=20 >>>>> include device ID, manufacturer's serial number, channel usage and=20 >>>>> power level information. >>>>> >>>>> P.12qua: The protocol MUST support a channel usage message=20 >>>>> acknowledgement. >>>>> >>>>> New O requirements (probably best placed following O13): >>>>> >>>>> O.13bis: According to local regulatory policy, after connecting=20 >>>>> to a master device's radio network a slave device MAY inform the=20 >>>>> master device of the actual channel usage. The slave MUST include=20 >>>>> parameters required by local regulatory policy, e.g. device ID,=20 >>>>> manufacturer's serial number, channel usage and power level informati= on. >>>>> >>>>> O.13ter: According to local regulatory policy, a master device=20 >>>>> MAY inform the database of the actual channel usage of the master=20 >>>>> and its slaves. The master MUST include parameters required by=20 >>>>> local regulatory policy, e.g. device ID, manufacturer's serial=20 >>>>> number, channel usage and power level information of the master=20 >>>>> and its slaves. >>>>> >>>>> New steps could be introduced into one or more use cases to cover=20 >>>>> these Ofcom requirements, e.g. new steps 6bis and 9bis in the=20 >>>>> hotspot use case at 4.2.1: >>>>> >>>>> 6bis. Prior to initiating transmission, if required by local=20 >>>>> regulation, the master/AP informs the database of the channel and=20 >>>>> power level it has chosen. This is repeated for each slave that=20 >>>>> associated with the master. >>>>> >>>>> 9bis. Prior to initiating transmission, if required by local=20 >>>>> regulation, the slave informs the master/AP of the channel and=20 >>>>> power level it has chosen, and the master/AP relays this=20 >>>>> information to the database. >>>>> >>>>> - end of new text - >>>>> >>>>> For information, for those not accessing the url in the first=20 >>>>> paragraph of this email, the full Ofcom requirements leading to=20 >>>>> this new PAWS text are as follows: >>>>> >>>>> 3.18 After receiving instructions from a WSDB in relation to the=20 >>>>> maximum permitted EIRPs over the DTT channels, and prior to=20 >>>>> initiating transmissions within the UHF TV band, a master WSD must=20 >>>>> communicate to the WSDB the following information: >>>>> >>>>> 3.18.1 The lower and upper frequency boundaries^13 of the in-block=20 >>>>> emissions of the master WSD, and those of the in-block emissions=20 >>>>> of its associated slaves. A lower frequency will be specified as=20 >>>>> (470 + 8k + >>>>> 0.2n) MHz, with the corresponding upper frequency specified as=20 >>>>> (470 + 8k >>>>> + 0.2m) MHz, where 0 3=AE4 k 3=AE4 39, 0 3=AE4 n 3=AE4 39, 1 3=AE4 m = 3=AE4 40, and n< m. >>>>> >>>>> 3.18.2 The maximum in-block EIRP spectral densities (in dBm/(0.2=20 >>>>> MHz)) that the master WSD, and its associated slaves, actually=20 >>>>> radiate between each reported lower frequency boundary and its=20 >>>>> corresponding upper frequency boundary. >>>>> >>>>> Footnote 13 states: >>>>> >>>>> The use of upper and lower frequency boundaries (defined over a=20 >>>>> 200 kHz >>>>> raster) allows a WSDB to collect more granular information with=20 >>>>> regards to the usage of the frequency resource by narrowband WSD=20 >>>>> technologies. >>>>> The upper and lower frequencies of a boundary pair do not straddle=20 >>>>> a DTT channel boundary. Note that a WSD may transmit over=20 >>>>> multiple, non-contiguous, whole DTT channels or fractions of DTT chan= nels. >>>>> >>>>> 3.19 A master WSD must be able to receive the following=20 >>>>> information^14 from a WSDB: >>>>> >>>>> >>>>> >>>>> 3.19.8 [An acknowledgement from the WSDB, in the context of 3.18, >>>>> that the reported information on the DTT channels and EIRP=20 >>>>> spectral densities actually used by the master and slave WSDs were=20 >>>>> received successfully by the WSDB^18 ]. >>>>> >>>>> Footnote 14 states: >>>>> >>>>> 14 While the communication of some of this information from a WSDB=20 >>>>> to a master WSD is optional, master WSDs must be able to receive=20 >>>>> and interpret these. >>>>> >>>>> Footnote 18 states: >>>>> >>>>> 18 This forms part of a handshake protocol and may be an area=20 >>>>> where industry could harmonise without the need for an explicit=20 >>>>> requirement in the regulations. >>>>> >>>>> Regards >>>>> >>>>> Andy >>>>> >>>>> *From:*paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On=20 >>>>> Behalf Of *Gabor.Bajko@nokia.com >>>>> *Sent:* 05 March 2012 19:46 >>>>> *To:* paws@ietf.org >>>>> *Subject:* [paws] WGLC for >>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >>>>> >>>>> The authors of the use cases and requirements draft have just=20 >>>>> posted a new version of the draft and indicated that there are no=20 >>>>> unresolved comments/issues they are aware of. >>>>> >>>>> Therefore, I'd like to initiate a WG Last Call for comments on=20 >>>>> http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-u >>>>> seca >>>>> ses-rqmts-03.txt >>>>> >>>>> >>>>> Please review the draft and send your comments to the list by=20 >>>>> March 20th, 2012. >>>>> >>>>> If you review the draft and have no comments, send a note to the=20 >>>>> list that the draft is good as it is, we need these notes as much=20 >>>>> as we need the actual comments. >>>>> >>>>> Thanks, Gabor >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>> >>> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws > > _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From scott.probasco@Nokia.com Tue Mar 6 09:32:29 2012 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 3CD4821F866B for ; Tue, 6 Mar 2012 09:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.548, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, 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 mHkztPUClMJj for ; Tue, 6 Mar 2012 09:32:27 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id E7DDB21F865A for ; Tue, 6 Mar 2012 09:32:26 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q26HWMPK014515; Tue, 6 Mar 2012 19:32:25 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Mar 2012 19:32:23 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.129]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0355.003; Tue, 6 Mar 2012 18:32:22 +0100 From: To: Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting Thread-Index: AQHM+7qBJZkKE/OsEE6WAJSH4Dz7PpZdfy+A//+SKwA= Date: Tue, 6 Mar 2012 17:32:22 +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.14.0.111121 x-originating-ip: [10.241.48.30] Content-Type: multipart/alternative; boundary="_000_CB7BA2DC1392Ascottprobasconokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 06 Mar 2012 17:32:23.0763 (UTC) FILETIME=[1772DA30:01CCFBBF] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 17:32:29 -0000 --_000_CB7BA2DC1392Ascottprobasconokiacom_ Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGkgR2VyYWxkLA0KDQpJIGJlbGlldmUgQW5keSdzIHByb3Bvc2FsIGFncmVlcyB3aXRoIHlvdXIg c3VnZ2VzdGlvbiBiZWxvdy4gTG9va2luZyBhdCBPLjEzYmlzLCB0aGUgc2xhdmUgTUFZIHNlbmQg dGhlIGNoYW5uZWwgdXNhZ2UgaW5mb3JtYXRpb24gYW5kIGlmIGl0IGRvZXMgc28sIGl0IE1VU1Qg aW5jbHVkZSB0aGUgZm9sbG93aW5nIHZhcmlhYmxlcy4gSSB0aGluayBQLjEyYmlzIGlzIGFwcHJv cHJpYXRlIHNpbmNlIHRoZSBtZXNzYWdlIE1VU1QgYmUgZGVmaW5lZCBieSB0aGUgcHJvdG9jb2wg aW4gb3JkZXIgdG8gaGF2ZSB0aGUgT1BUSU9OIG9mIHNlbmRpbmcgaXQuIFdoZW4gdGhlc2UgdHdv IHJlcXVpcmVtZW50cyBhcmUgY29uc2lkZXJlZCBqb2ludGx5IGRvZXMgdGhpcyBwcm92aWRlIHRo ZSBpbXBsZW1lbnRhdGlvbiBmbGV4aWJpbGl0eSB5b3UgYXJlIHRoaW5raW5nIG9mPw0KDQpLaW5k IFJlZ2FyZHMsDQpTY290dA0KDQpGcm9tOiBleHQgQ2hvdWluYXJkIDxnZXJhbGQuY2hvdWluYXJk QHN5bXBhdGljby5jYTxtYWlsdG86Z2VyYWxkLmNob3VpbmFyZEBzeW1wYXRpY28uY2E+Pg0KRGF0 ZTogVHVlLCA2IE1hciAyMDEyIDEyOjEzOjA1IC0wNTAwDQpUbzogU2NvdHQgUHJvYmFzY28gPHNj b3R0LnByb2Jhc2NvQG5va2lhLmNvbTxtYWlsdG86c2NvdHQucHJvYmFzY29Abm9raWEuY29tPj4N CkNjOiAicGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4iIDxwYXdzQGlldGYub3Jn PG1haWx0bzpwYXdzQGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBbcGF3c10gV0dMQyBmb3IgZHJh ZnQtaWV0Zi1wYXdzLXByb2JsZW0tc3RtdC11c2VjYXNlcy1ycW10cy0wMzogY2hhbm5lbCByZXBv cnRpbmcNCg0KU2NvdHQsDQoNCkkgYW0gZmluZSB3aXRoIHlvdXIgYXBwcm9hY2ggYXMgbG9uZyBh cyB0aGUgdGV4dCBzYXlzIHNvbWV0aGluZyBhcyBmb2xsb3dzOiChsHRoZSBvcGVyYXRpbmcgY2hh bm5lbCBvZiB0aGUgc2xhdmUgbmVlZHMgdG8gYmUgcHJvdmlkZWQgdG8gdGhlIGRhdGFiYXNlobEg cmF0aGVyIHRoYW46IKGwdGhlIHNsYXZlIG5lZWRzIHRvIHByb3ZpZGUgdGhlIGRhdGFiYXNlIHdp dGggaXRzIG9wZXJhdGluZyBjaGFubmVsobEuICBUaGlzIHdheSwgdGhpcyBpbmZvcm1hdGlvbiBj YW4gYmUgcHJvdmlkZWQgYnkgZWl0aGVyIHRoZSBzbGF2ZSBvciB0aGUgbWFzdGVyLCBub3QgbWFr aW5nIGl0IG1hbmRhdG9yeSB0aGF0IHRoZSChsHNsYXZlobEgaGFzIHRvIGRvIGl0IGlmIHRoZSBt YXN0ZXIga25vd3MgdGhlIGluZm9ybWF0aW9uLg0KDQpUaGUgdGV4dCBwcm9wb3NlZCBieSBBbmR5 OiChsFRoZSBwcm90b2NvbCBNVVNUIHN1cHBvcnQgYSBjaGFubmVsIHVzYWdlIG1lc3NhZ2UgZnJv bSB0aGUgc2xhdmUgZGV2aWNlIHRvIHRoZSBtYXN0ZXIgZGV2aWNlLqGxIEltcGxpZXMgdGhhdCB0 aGUgcHJvdG9jb2wgdG8gYmUgZGV2ZWxvcGVkIG5lZWRzIHRvIGFwcGx5IG9uIHRoZSBjb25uZWN0 aW9uIGJldHdlZW4gdGhlIHNsYXZlIGFuZCB0aGUgbWFzdGVyLiBTdWNoIGNvbm5lY3Rpb24gc2hv dWxkIGJlIGltcGxlbWVudGF0aW9uIGRlcGVuZGFudC4gIFdoYXQgaXMgcmVxdWlyZWQgaXMgdGhh dCB0aGUgaW5mb3JtYXRpb24gYmUgYXZhaWxhYmxlIHRvIHRoZSBtYXN0ZXIgZm9yIGl0IHRvIHRy YW5zbWl0IGl0IHRvIHRoZSBkYXRhYmFzZSwgbmV2ZXIgbWluZCB0aGUgZm9ybWF0IHRoYXQgaXN1 c2VkIGJldHdlZW4gdGhlIHNsYXZlIGFuZCB0aGUgbWFzdGVyIHRvIGNhcnJ5IHRoaXMgaW5mb3Jt YXRpb24uDQoNCkdlcmFsZA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJv bTogc2NvdHQucHJvYmFzY29Abm9raWEuY29tPG1haWx0bzpzY290dC5wcm9iYXNjb0Bub2tpYS5j b20+IFttYWlsdG86c2NvdHQucHJvYmFzY29Abm9raWEuY29tXQ0KU2VudDogVHVlc2RheSwgMDYg TWFyY2gsIDIwMTIgMTI6MDANClRvOiBnZXJhbGQuY2hvdWluYXJkQHN5bXBhdGljby5jYTxtYWls dG86Z2VyYWxkLmNob3VpbmFyZEBzeW1wYXRpY28uY2E+OyBhbmR5LnNhZ29AYnQuY29tPG1haWx0 bzphbmR5LnNhZ29AYnQuY29tPg0KQ2M6IHBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW3Bhd3NdIFdHTEMgZm9yIGRyYWZ0LWlldGYtcGF3cy1wcm9ibGVt LXN0bXQtdXNlY2FzZXMtcnFtdHMtMDM6IGNoYW5uZWwgcmVwb3J0aW5nDQoNCkhpIEdlcmFsZCwN Cg0KQXQgbGVhc3QgYWNjb3JkaW5nIHRvIHRoZSBGQ0MsIGEgc2xhdmUgKE1vZGUgSSkgZGV2aWNl IG1heSB1dGlsaXplIGNoYW5uZWxzIHRoYXQgdGhlIG1hc3RlciAoZml4ZWQgZGV2aWNlKSBjYW5u b3QgdXNlLCBzZWUgodcxNS43MDcgYW5kIDE1LjcxMi4gVGh1cyB0aGVyZSBhcmUgcG90ZW50aWFs IHNpdHVhdGlvbnMgd2hlcmUgdGhlIG1hc3RlciBjYW5ub3QgYmUgYXNzdW1lZCB0byBrbm93IHdo YXQgY2hhbm5lbCB0aGUgc2xhdmUgaXMgdXNpbmcuIEFsdGhvdWdoIHRoaXMgaXMgYSBiaXQgZXNv dGVyaWMgYXMgdGhlIEZDQyBpcyBzaWxlbnQgYWJvdXQgd2hhdCB0aGUgc2xhdmUgbWlnaHQgZG8g b24gdGhvc2UgY2hhbm5lbHMsIGl0IGlzIG5vbmV0aGVsZXNzIGluY2x1ZGVkIGluIHRoZSBGQ0Mg cmVndWxhdGlvbnMuDQoNClNvIEkgc3VnZ2VzdCB3ZSBoYXZlIG5vIHJlYXNvbiB0byBvdmVycnVs ZSBPZmNvbSByZXF1aXJlbWVudHMgZm9yIGNoYW5uZWwgdXNhZ2UgaW5mb3JtYXRpb24uIEFsc28g QW5keSdzIGNob2ljZSBvZiB3b3JkcyBkb2VzIGVuc3VyZSB0aGF0IHRoaXMgaW5mb3JtYXRpb24g aXMgbm90IHJlcXVpcmVkIHRvIGJlIHVzZWQgaW4gZXZlcnkgb3BlcmF0aW9uYWwgc2NlbmFyaW8u DQoNCktpbmQgUmVnYXJkcywNClNjb3R0DQoNCg0KDQpGcm9tOiBleHQgQ2hvdWluYXJkIDxnZXJh bGQuY2hvdWluYXJkQHN5bXBhdGljby5jYTxtYWlsdG86Z2VyYWxkLmNob3VpbmFyZEBzeW1wYXRp Y28uY2E+Pg0KRGF0ZTogVHVlLCA2IE1hciAyMDEyIDExOjQ0OjA3IC0wNTAwDQpUbzogZXh0IGNv bSA8YW5keS5zYWdvQGJ0LmNvbTxtYWlsdG86YW5keS5zYWdvQGJ0LmNvbT4+DQpDYzogInBhd3NA aWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+IiA8cGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3 c0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3Bhd3NdIFdHTEMgZm9yIGRyYWZ0LWlldGYtcGF3 cy1wcm9ibGVtLXN0bXQtdXNlY2FzZXMtcnFtdHMtMDM6IGNoYW5uZWwgcmVwb3J0aW5nDQoNCkFu ZHksDQoNCkxvb2tpbmcgYXQgeW91ciBzdWdnZXN0aW9ucyBiZWxvdywgaXQgc2VlbXMgdGhhdCB0 aGVyZSBpcyBhIG5lZWQgdG8gZGVmaW5lIG1vcmUgcHJlY2lzZWx5IHdoYXQgYSChsHNsYXZlobEg ZGV2aWNlIGlzIHJlbGF0aXZlIHRvIGl0cyChsG1hc3RlcqGxLg0KDQpJbiBteSB2aWV3LCBhIHNs YXZlIGNhbiBvbmx5IHVzZSB0aGUgc2FtZSB0cmFuc21pc3Npb24gY2hhbm5lbCBhcyB0aGF0IHVz ZWQgYnkgdGhlIG1hc3RlciB0byB3aGljaCBpdCBpcyBhc3NvY2lhdGVkIChvdGhlcndpc2UsIG1h c3RlciBhbmQgc2xhdmVzIHdvdWxkIG5vdCBiZSBhYmxlIHRvIHRhbGsgdG8gZWFjaCBvdGhlciku IEFzIGEgY29uc2VxdWVuY2UsIHRoZSBzbGF2ZSBkb2VzIG5vdCBoYXZlIHRvIGluZGljYXRlIHRv IHRoZSBtYXN0ZXIgdGhlIGNoYW5uZWwgb24gd2hpY2ggaXQgaXMgb3BlcmF0aW5nIHNpbmNlIHRo ZSBtYXN0ZXIga25vd3MgaXQgYW5kIGNhbiBwcm92aWRlZCBpdCB0byB0aGUgZGF0YWJhc2UgZS4N Cg0KU2ltaWxhcmx5LCBtb2Rlcm4gYmlkaXJlY3Rpb25hbCBjb21tdW5pY2F0aW9uIHN5c3RlbXMg YmV0d2VlbiBhIG1hc3RlciBhbmQgYSBzbGF2ZSBkZXZpY2UgYXNzdW1lcyB0aGF0IHRoZXJlIHdp bGwgYmUgYSB0cmFuc21pdCBwb3dlciBjb250cm9sIChUUEMpIGxvb3AgYmV0d2VlbiB0aGUgdHdv IGRldmljZXMgdG8gbWluaW1pemUgdGhlIHJlcXVpcmVkIHRyYW5zbWl0IHBvd2VyIGluIHZhcmlv dXMgcHJvcGFnYXRpb24gZW52aXJvbm1lbnRzLiBUaGUgZHJpdmluZyBkZXZpY2UgaW4gdGhpcyBj bG9zZWQtbG9vcCBwcm9jZXNzIHdpbGwgYmUgdGhlIG1hc3RlciBhbmQgYXMgYSByZXN1bHQsIHRo ZSBFSVJQIHRyYW5zbWl0dGVkIGJ5IHRoZSBzbGF2ZSBkZXZpY2Ugd2lsbCBiZSBrbm93biB0byB0 aGUgbWFzdGVyIGFzIGxvbmcgYXMgdGhlcmUgaXMgYSBrbm93biBmYWN0b3IgbGlua2luZyB0aGUg cG93ZXIgc3BlY2lmaWNhdGlvbiBzZW50IGJ5IHRoZSBtYXN0ZXIgdG8gdGhlIHNsYXZlIGFuZCB0 aGUgYWN0dWFsIEVJUlAgdHJhbnNtaXR0ZWQgYnkgdGhlIHNsYXZlLiAgU3VjaCBmYWN0b3Igd2hp Y2ggaXMgYSBjb25zdGFudCBmb3IgZWFjaCBkZXZpY2UgY2FuIGJlIHByb3ZpZGVkIGZyb20gdGhl IHNsYXZlIHRvIHRoZSBtYXN0ZXIgb25jZSBhdCBhc3NvY2lhdGlvbi4gIEFzIGEgcmVzdWx0LCB0 aGUgc2xhdmUgZG9lcyBub3QgbmVlZCB0byBpbmZvcm0gdGhlIG1hc3RlciBvZiBpdHMgY3VycmVu dCAoYW5kIHByb3ZhYmx5IGNvbnRpbnVvdXNseSB2YXJ5aW5nKSBFSVJQIHNpbmNlIHRoZSBtYXN0 ZXIgd2lsbCBoYXZldGhpcyBpbmZvcm1hdGlvbiBmcm9tIGl0cyBUUEMgcHJvY2VzcyBhbmQgY2Fu IHByb3ZpZGUgaXQgdG8gdGhlIGRhdGFiYXNlIG9uYmVoYWxmIG9mIHRoZSBzbGF2ZSBkZXZpY2Uu DQoNCkdlcmFsZA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogcGF3 cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86 cGF3cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgYW5keS5zYWdvQGJ0LmNvbTxtYWls dG86YW5keS5zYWdvQGJ0LmNvbT4NClNlbnQ6IFR1ZXNkYXksIDA2IE1hcmNoLCAyMDEyIDEwOjQy DQpUbzogcGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz47IEdhYm9yLkJhamtvQG5v a2lhLmNvbTxtYWlsdG86R2Fib3IuQmFqa29Abm9raWEuY29tPg0KU3ViamVjdDogUmU6IFtwYXdz XSBXR0xDIGZvciBkcmFmdC1pZXRmLXBhd3MtcHJvYmxlbS1zdG10LXVzZWNhc2VzLXJxbXRzLTAz OiBjaGFubmVsIHJlcG9ydGluZw0KDQpBbGwNCg0KQ29tcGFyaW5nIHRoZSBkcmFmdCB3aXRoIHRo ZSBPZmNvbSByZXF1aXJlbWVudHMgYXQgaHR0cDovL3d3dy5jZXB0Lm9yZy9Eb2N1bWVudHMvc2Ut NDMvNDE2MS9TRTQzKDEyKUluZm8wM19EcmFmdC1VSy1yZWd1bGF0b3J5LXJlcXVpcmVtZW50cy1m b3Itd2hpdGUtc3BhY2UtZGV2aWNlcy1pbi10aGUtVUhGLVRWLWJhbmQsIEkgYmVsaWV2ZSB0aGUg V0cgZHJhZnQgaXMgZGVmaWNpZW50IGluIHRoZSBhcmVhIG9mIHJlcG9ydGluZyBmcmVxdWVuY2ll cyBhbmQgcG93ZXJzIGFjdHVhbGx5IHVzZWQgYnkgbWFzdGVycyBhbmQgc2xhdmVzIChPZmNvbSBy ZXF1aXJlbWVudHMgMy4xOCBhbmQgMy4xOS44KS4gT2Zjb20gaW50ZW5kcyB0byBjb2xsZWN0IHRo aXMgZGF0YSB0byBhc3Nlc3NlcyB0aGUgaW1wYWN0IG9mIGFnZ3JlZ2F0ZSBpbnRlcmZlcmVuY2Ug aW50byBvdGhlciBzZXJ2aWNlcy4gSXQgd291bGQgYWxzbyBwcm92aWRlIHVzYWdlIGluZm9ybWF0 aW9uIChmcmVxdWVuY3kgaW4gdXNlKSB0aGF0IHdvdWxkIGluZm9ybSB0aGUgb3BlcmF0aW9uIG9m IGEga2lsbCBzd2l0Y2ggY2FwYWJpbGl0eS4gSSBzdWdnZXN0IHRoaXMgZGVmaWNpZW5jeSBjYW4g YmUgcmVtZWRpZWQgd2l0aCB0aGUgZm9sbG93aW5nIGNoYW5nZXM6DQoNCk5ldyBQIHJlcXVpcmVt ZW50cyAocHJvYmFibHkgYmVzdCBwbGFjZWQgZm9sbG93aW5nIFAuMTIpOg0KDQpQLjEyYmlzOiBU aGUgcHJvdG9jb2wgTVVTVCBzdXBwb3J0IGEgY2hhbm5lbCB1c2FnZSBtZXNzYWdlIGZyb20gdGhl IHNsYXZlIGRldmljZSB0byB0aGUgbWFzdGVyIGRldmljZS4gIFRoZSBjaGFubmVsIHVzYWdlIG1l c3NhZ2UgTVVTVCBpbmNsdWRlIHBhcmFtZXRlcnMgYXMgcmVxdWlyZWQgYnkgbG9jYWwgcmVndWxh dG9yeSByZXF1aXJlbWVudC4gIFRoZXNlIHBhcmFtZXRlcnMgTUFZIGluY2x1ZGUgZGV2aWNlIElE LCBtYW51ZmFjdHVyZXIncyBzZXJpYWwgbnVtYmVyLCBjaGFubmVsIHVzYWdlIGFuZCBwb3dlciBs ZXZlbCBpbmZvcm1hdGlvbi4NCg0KUC4xMnRlcjogVGhlIHByb3RvY29sIE1VU1Qgc3VwcG9ydCBh IGNoYW5uZWwgdXNhZ2UgbWVzc2FnZSBmcm9tIHRoZSBtYXN0ZXIgZGV2aWNlIHRvIHRoZSBkYXRh YmFzZS4gIFRoZSBjaGFubmVsIHVzYWdlIG1lc3NhZ2UgTVVTVCBpbmNsdWRlIHBhcmFtZXRlcnMg YXMgcmVxdWlyZWQgYnkgbG9jYWwgcmVndWxhdG9yeSByZXF1aXJlbWVudCBmb3IgdGhlIG1hc3Rl ciBhbmQgaXRzIGFzc29jaWF0ZWQgc2xhdmVzLiAgVGhlc2UgcGFyYW1ldGVycyBNQVkgaW5jbHVk ZSBkZXZpY2UgSUQsIG1hbnVmYWN0dXJlcidzIHNlcmlhbCBudW1iZXIsIGNoYW5uZWwgdXNhZ2Ug YW5kIHBvd2VyIGxldmVsIGluZm9ybWF0aW9uLg0KDQpQLjEycXVhOiBUaGUgcHJvdG9jb2wgTVVT VCBzdXBwb3J0IGEgY2hhbm5lbCB1c2FnZSBtZXNzYWdlIGFja25vd2xlZGdlbWVudC4NCg0KTmV3 IE8gcmVxdWlyZW1lbnRzIChwcm9iYWJseSBiZXN0IHBsYWNlZCBmb2xsb3dpbmcgTzEzKToNCg0K Ty4xM2JpczogIEFjY29yZGluZyB0byBsb2NhbCByZWd1bGF0b3J5IHBvbGljeSwgYWZ0ZXIgY29u bmVjdGluZyB0byBhIG1hc3RlciBkZXZpY2Unc3JhZGlvIG5ldHdvcmsgYSBzbGF2ZSBkZXZpY2Ug TUFZIGluZm9ybSB0aGUgbWFzdGVyIGRldmljZSBvZiB0aGUgYWN0dWFsIGNoYW5uZWwgdXNhZ2Uu IFRoZSBzbGF2ZSBNVVNUIGluY2x1ZGUgcGFyYW1ldGVycyByZXF1aXJlZCBieSBsb2NhbCByZWd1 bGF0b3J5IHBvbGljeSwgZS5nLiBkZXZpY2UgSUQsIG1hbnVmYWN0dXJlcidzIHNlcmlhbCBudW1i ZXIsIGNoYW5uZWwgdXNhZ2UgYW5kIHBvd2VyIGxldmVsaW5mb3JtYXRpb24uDQoNCk8uMTN0ZXI6 ICBBY2NvcmRpbmcgdG8gbG9jYWwgcmVndWxhdG9yeSBwb2xpY3ksIGEgbWFzdGVyIGRldmljZSBN QVkgaW5mb3JtIHRoZSBkYXRhYmFzZSBvZiB0aGUgYWN0dWFsIGNoYW5uZWwgdXNhZ2Ugb2YgdGhl IG1hc3RlciBhbmQgaXRzIHNsYXZlcy4gVGhlIG1hc3RlciBNVVNUIGluY2x1ZGUgcGFyYW1ldGVy cyByZXF1aXJlZCBieSBsb2NhbCByZWd1bGF0b3J5IHBvbGljeSwgZS5nLiBkZXZpY2UgSUQsIG1h bnVmYWN0dXJlcidzIHNlcmlhbCBudW1iZXIsIGNoYW5uZWwgdXNhZ2UgYW5kIHBvd2VyIGxldmVs IGluZm9ybWF0aW9uIG9mIHRoZSBtYXN0ZXIgYW5kIGl0cyBzbGF2ZXMuDQoNCk5ldyBzdGVwcyBj b3VsZCBiZSBpbnRyb2R1Y2VkIGludG8gb25lIG9yIG1vcmUgdXNlIGNhc2VzIHRvIGNvdmVyIHRo ZXNlIE9mY29tIHJlcXVpcmVtZW50cywgZS5nLiBuZXcgc3RlcHMgNmJpcyBhbmQgOWJpcyBpbiB0 aGUgaG90c3BvdCB1c2UgY2FzZSBhdCA0LjIuMToNCg0KNmJpcy4gUHJpb3IgdG8gaW5pdGlhdGlu ZyB0cmFuc21pc3Npb24sIGlmIHJlcXVpcmVkIGJ5IGxvY2FsIHJlZ3VsYXRpb24sIHRoZSBtYXN0 ZXIvQVAgaW5mb3JtcyB0aGUgZGF0YWJhc2Ugb2YgdGhlIGNoYW5uZWwgYW5kIHBvd2VyIGxldmVs IGl0IGhhcyBjaG9zZW4uIFRoaXMgaXMgcmVwZWF0ZWQgZm9yIGVhY2ggc2xhdmUgdGhhdCBhc3Nv Y2lhdGVkIHdpdGggdGhlIG1hc3Rlci4NCg0KOWJpcy4gUHJpb3IgdG8gaW5pdGlhdGluZyB0cmFu c21pc3Npb24sIGlmIHJlcXVpcmVkIGJ5IGxvY2FsIHJlZ3VsYXRpb24sIHRoZSBzbGF2ZSBpbmZv cm1zIHRoZSBtYXN0ZXIvQVAgb2YgdGhlIGNoYW5uZWwgYW5kIHBvd2VyIGxldmVsIGl0IGhhcyBj aG9zZW4sIGFuZCB0aGVtYXN0ZXIvQVAgcmVsYXlzIHRoaXMgaW5mb3JtYXRpb24gdG8gdGhlIGRh dGFiYXNlLg0KDQotIGVuZCBvZiBuZXcgdGV4dCAtDQoNCkZvciBpbmZvcm1hdGlvbiwgZm9yIHRo b3NlIG5vdCBhY2Nlc3NpbmcgdGhlIHVybCBpbiB0aGUgZmlyc3QgcGFyYWdyYXBoIG9mIHRoaXMg ZW1haWwsIHRoZSBmdWxsIE9mY29tIHJlcXVpcmVtZW50cyBsZWFkaW5nIHRvIHRoaXMgbmV3IFBB V1MgdGV4dCBhcmUgYXMgZm9sbG93czoNCg0KMy4xOCBBZnRlciByZWNlaXZpbmcgaW5zdHJ1Y3Rp b25zIGZyb20gYSBXU0RCIGluIHJlbGF0aW9uIHRvIHRoZSBtYXhpbXVtIHBlcm1pdHRlZCBFSVJQ cyBvdmVyIHRoZSBEVFQgY2hhbm5lbHMsIGFuZCBwcmlvciB0byBpbml0aWF0aW5nIHRyYW5zbWlz c2lvbnMgd2l0aGluIHRoZSBVSEYgVFYgYmFuZCwgYSBtYXN0ZXIgV1NEIG11c3Rjb21tdW5pY2F0 ZSB0byB0aGUgV1NEQiB0aGUgZm9sbG93aW5nIGluZm9ybWF0aW9uOg0KMy4xOC4xIFRoZSBsb3dl ciBhbmQgdXBwZXIgZnJlcXVlbmN5IGJvdW5kYXJpZXMxMyBvZiB0aGUgaW4tYmxvY2sgZW1pc3Np b25zIG9mIHRoZSBtYXN0ZXIgV1NELCBhbmQgdGhvc2Ugb2YgdGhlIGluLWJsb2NrIGVtaXNzaW9u cyBvZiBpdHMgYXNzb2NpYXRlZCBzbGF2ZXMuIEEgbG93ZXIgZnJlcXVlbmN5IHdpbGwgYmUgc3Bl Y2lmaWVkIGFzICg0NzAgKyA4ayArIDAuMm4pIE1Ieiwgd2l0aCB0aGUgY29ycmVzcG9uZGluZyB1 cHBlciBmcmVxdWVuY3kgc3BlY2lmaWVkIGFzICg0NzAgKyA4ayArIDAuMm0pIE1Ieiwgd2hlcmUg MCChwiBrIKHCIDM5LCAwIKHCIG4gocIgMzksIDEgocIgbSChwiA0MCwgYW5kIG4gPCBtLg0KMy4x OC4yIFRoZSBtYXhpbXVtIGluLWJsb2NrIEVJUlAgc3BlY3RyYWwgZGVuc2l0aWVzIChpbiBkQm0v KDAuMiBNSHopKSB0aGF0IHRoZSBtYXN0ZXJXU0QsIGFuZCBpdHMgYXNzb2NpYXRlZCBzbGF2ZXMs IGFjdHVhbGx5IHJhZGlhdGUgYmV0d2VlbiBlYWNoIHJlcG9ydGVkIGxvd2VyIGZyZXF1ZW5jeSBi b3VuZGFyeSBhbmQgaXRzIGNvcnJlc3BvbmRpbmcgdXBwZXIgZnJlcXVlbmN5IGJvdW5kYXJ5Lg0K DQpGb290bm90ZSAxMyBzdGF0ZXM6DQpUaGUgdXNlIG9mIHVwcGVyIGFuZCBsb3dlciBmcmVxdWVu Y3kgYm91bmRhcmllcyAoZGVmaW5lZCBvdmVyIGEgMjAwIGtIeiByYXN0ZXIpIGFsbG93cyBhIFdT REIgdG8gY29sbGVjdCBtb3JlIGdyYW51bGFyIGluZm9ybWF0aW9uIHdpdGggcmVnYXJkcyB0byB0 aGUgdXNhZ2Ugb2YgdGhlIGZyZXF1ZW5jeSByZXNvdXJjZSBieW5hcnJvd2JhbmQgV1NEIHRlY2hu b2xvZ2llcy4gVGhlIHVwcGVyIGFuZCBsb3dlciBmcmVxdWVuY2llcyBvZiBhIGJvdW5kYXJ5IHBh aXIgZG8gbm90IHN0cmFkZGxlIGEgRFRUIGNoYW5uZWwgYm91bmRhcnkuIE5vdGUgdGhhdCBhIFdT RCBtYXkgdHJhbnNtaXQgb3ZlciBtdWx0aXBsZSwgbm9uLWNvbnRpZ3VvdXMsIHdob2xlIERUVCBj aGFubmVscyBvciBmcmFjdGlvbnMgb2YgRFRUIGNoYW5uZWxzLg0KDQozLjE5IEEgbWFzdGVyIFdT RCBtdXN0IGJlIGFibGUgdG8gcmVjZWl2ZSB0aGUgZm9sbG93aW5nIGluZm9ybWF0aW9uMTQgZnJv bSBhIFdTREI6DQo8c25pcD4NCjMuMTkuOCAgICAgW0FuIGFja25vd2xlZGdlbWVudCBmcm9tIHRo ZSBXU0RCLCBpbiB0aGUgY29udGV4dCBvZiAzLjE4LCB0aGF0IHRoZSByZXBvcnRlZCBpbmZvcm1h dGlvbiBvbiB0aGUgRFRUIGNoYW5uZWxzIGFuZCBFSVJQIHNwZWN0cmFsIGRlbnNpdGllcyBhY3R1 YWxseSB1c2VkIGJ5IHRoZSBtYXN0ZXIgYW5kIHNsYXZlIFdTRHMgd2VyZSByZWNlaXZlZCBzdWNj ZXNzZnVsbHkgYnkgdGhlIFdTREIxOF0uDQoNCkZvb3Rub3RlIDE0IHN0YXRlczoNCjE0IFdoaWxl IHRoZSBjb21tdW5pY2F0aW9uIG9mIHNvbWUgb2YgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIGEgV1NE QiB0byBhIG1hc3RlciBXU0QgaXMgb3B0aW9uYWwsIG1hc3RlciBXU0RzIG11c3QgYmUgYWJsZSB0 byByZWNlaXZlIGFuZCBpbnRlcnByZXQgdGhlc2UuDQoNCkZvb3Rub3RlIDE4IHN0YXRlczoNCjE4 IFRoaXMgZm9ybXMgcGFydCBvZiBhIGhhbmRzaGFrZSBwcm90b2NvbCBhbmQgbWF5IGJlIGFuIGFy ZWEgd2hlcmUgaW5kdXN0cnkgY291bGQgaGFybW9uaXNlIHdpdGhvdXQgdGhlIG5lZWQgZm9yIGFu IGV4cGxpY2l0IHJlcXVpcmVtZW50IGluIHRoZSByZWd1bGF0aW9ucy4NCg0KUmVnYXJkcw0KDQpB bmR5DQoNCkZyb206IHBhd3MtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cGF3cy1ib3VuY2VzQGll dGYub3JnPiBbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdhYm9y LkJhamtvQG5va2lhLmNvbTxtYWlsdG86R2Fib3IuQmFqa29Abm9raWEuY29tPg0KU2VudDogMDUg TWFyY2ggMjAxMiAxOTo0Ng0KVG86IHBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBbcGF3c10gV0dMQyBmb3IgZHJhZnQtaWV0Zi1wYXdzLXByb2JsZW0tc3RtdC11 c2VjYXNlcy1ycW10cy0wMw0KDQoNClRoZSBhdXRob3JzIG9mIHRoZSB1c2UgY2FzZXMgYW5kIHJl cXVpcmVtZW50cyBkcmFmdCBoYXZlIGp1c3QgcG9zdGVkIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRy YWZ0IGFuZCBpbmRpY2F0ZWQgdGhhdCB0aGVyZSBhcmUgbm8gdW5yZXNvbHZlZCBjb21tZW50cy9p c3N1ZXMgdGhleSBhcmUgYXdhcmUgb2YuDQoNCg0KDQpUaGVyZWZvcmUsIEknZCBsaWtlIHRvIGlu aXRpYXRlIGEgV0cgTGFzdCBDYWxsIGZvciBjb21tZW50cyBvbiBodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXBhd3MtcHJvYmxlbS1zdG10LXVzZWNhc2VzLXJx bXRzLTAzLnR4dA0KDQoNCg0KUGxlYXNlIHJldmlldyB0aGUgZHJhZnQgYW5kIHNlbmQgeW91cmNv bW1lbnRzIHRvIHRoZSBsaXN0IGJ5IE1hcmNoIDIwdGgsIDIwMTIuDQoNCg0KDQpJZiB5b3UgcmV2 aWV3IHRoZSBkcmFmdCBhbmQgaGF2ZSBubyBjb21tZW50cywgc2VuZCBhIG5vdGUgdG8gdGhlIGxp c3QgdGhhdCB0aGUgZHJhZnQgaXMgZ29vZCBhcyBpdCBpcywgd2UgbmVlZCB0aGVzZSBub3RlcyBh cyBtdWNoIGFzIHdlIG5lZWQgdGhlIGFjdHVhbCBjb21tZW50cy4NCg0KDQoNClRoYW5rcywgR2Fi b3INCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gcGF3 cyBtYWlsaW5nIGxpc3QgcGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo= --_000_CB7BA2DC1392Ascottprobasconokiacom_ Content-Type: text/html; charset="ks_c_5601-1987" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Gerald,

I believe Andy's proposal agrees with your suggestion below. Looking a= t O.13bis, the slave MAY send the channel usage information and if it does = so, it MUST include the following variables. I think P.12bis is appropriate= since the message MUST be defined by the protocol in order to have the OPTION of sending it. When these two = requirements are considered jointly does this provide the implementation fl= exibility you are thinking of?

Kind Regards,
Scott

From: ext Chouinard <gerald.chouinard@sympatico.ca>=
Date: Tue, 6 Mar 2012 12:13:05 -050= 0
To: Scott Probasco <scott.probasco@nokia.com>
Cc: "paws@ietf.org" <paws@i= etf.org>
Subject: RE: [paws] WGLC for draft-= ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting

Scott,

 

I am fine with your approach as long a= s the text says something as follows: =A1=B0the operating channel of the sl= ave needs to be provided to the database=A1=B1 rather than: =A1=B0the slave needs to provide the da= tabase with its operating channel=A1=B1.  This way, this information c= an be provided by either the slave or the master, not making it mandatory t= hat the =A1=B0slave=A1=B1 has to do it if the master knows the information.

 

The text proposed by Andy: =A1=B0The protocol MUST support a channel usage message from the slave device to the= master device.=A1=B1 Implies that the protocol to be developed needs to ap= ply on the connection between the slave and the master. Such connection sho= uld be implementation dependant.  What is required is that the information be available to the master for it to t= ransmit it to the database, never mind the format that isused between the s= lave and the master to carry this information.

 

Gerald

 

From: scott.probasco@nokia.com [<= a href=3D"mailto:scott.probasco@nokia.com">mailto:scott.probasco@nokia.com<= /a>]
Sent: Tuesday, 06 March, 201= 2 12:00
To: gerald.chouinard@sympa= tico.ca; andy.sago@bt.com
Cc: paws@ietf.org
Subject: Re: [paws] WGLC for= draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting

 

Hi Gerald,

 <= /p>

At least according to the FCC, a= slave (Mode I) device may utilize channels that the master (fixed device) = cannot use, see =A1=D715.707 and 15.712. Thus there are potential situations where the master cannot be assumed to know what c= hannel the slave is using. Although this is a bit esoteric as the FCC is si= lent about what the slave might do on those channels, it is nonetheless inc= luded in the FCC regulations.

 <= /p>

So I suggest we have no reason t= o overrule Ofcom requirements for channel usage information. Also Andy's ch= oice of words does ensure that this information is not required to be used in every operational scenario.

 <= /p>

Kind Regards,<= /font>

Scott

 <= /p>

 <= /p>

 <= /p>

From: = ext Chouinard <gerald.c= houinard@sympatico.ca>
Date: Tue, 6 Mar 2012 11:44:= 07 -0500
To: ext com <andy.sago@bt.com>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] WGLC for= draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting

 <= /p>

Andy,

 

Looking at your suggestions below, it = seems that there is a need to define more precisely what a =A1=B0slave=A1= =B1 device is relative to its =A1=B0master=A1=B1.

 

In my view, a slave can only use the s= ame transmission channel as that used by the master to which it is associat= ed (otherwise, master and slaves would not be able to talk to each other). As a consequence, the= slave does not have to indicate to the master the channel on which it is o= perating since the master knows it and can provided it to the database e.

 

Similarly, modern bidirectional commun= ication systems between a master and a slave device assumes that there will= be a transmit power control (TPC) loop between the two devices to minimize the required transm= it power in various propagation environments. The driving device in this cl= osed-loop process will be the master and as a result, the EIRP transmitted = by the slave device will be known to the master as long as there is a known factor linking the power specifi= cation sent by the master to the slave and the actual EIRP transmitted by t= he slave.  Such factor which is a constant for each device can be prov= ided from the slave to the master once at association.  As a result, the slave does not need to inform the m= aster of its current (and provably continuously varying) EIRP since the mas= ter will havethis information from its TPC process and can provide it to th= e database onbehalf of the slave device.

 

Gerald

 

= From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of andy.sago@bt.com
Sent: Tuesday, 06 March, 201= 2 10:42
To: paws@ietf.org; Gabor.Bajko@nokia.com
Subject: Re: [paws] WGLC for= draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting

 

= All

=  <= /u5:p>=

= Comparing the= draft with the Ofcom requirements at ht= tp://www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-regulatory-r= equirements-for-white-space-devices-in-the-UHF-TV-band, I believe the WG draft is deficient in the area of reporting frequencies a= nd powers actually used by masters and slaves (Ofcom requirements 3.18 and = 3.19.8). Ofcom intends to collect this data to assesses the impact of aggre= gate interference into other services. It would also provide usage information (frequency in use) that would info= rm the operation of a kill switch capability. I suggest this deficiency can= be remedied with the following changes:

=  <= /u5:p>=

= New P require= ments (probably best placed following P.12):

=  <= /u5:p>=

P.12bis: The protocol MUST support a channel usage message= from the slave device to the master device.  The channel usage message MUST include parameters as required by local regulat= ory requirement.  These parameters MAY include device ID, manufacturer= 's serial number, channel usage and power level information.

 

P.12ter: The protocol MUST support a channel usage message= from the master device to the database.  The channel usage message MUST include parameters as required by local regulatory requ= irement for the master and its associated slaves.  These parameters MA= Y include device ID, manufacturer's serial number, channel usage and power = level information.

 

P.12qua: The protocol MUST support a channel usage message= acknowledgement.

=  <= /u5:p>=

= New O require= ments (probably best placed following O13):

=  <= /u5:p>=

O.13bis:  According to local regulatory policy, after= connecting to a master device'sradio network a slave device MAY inform the master device of the actual channel usage. The slave= MUST include parameters required by local regulatory policy, e.g. device I= D, manufacturer's serial number, channel usage and power levelinformation.<= u5:p>

 

O.13ter:  According to local regulatory policy, a mas= ter device MAY inform the database of the actual channel usage of the master and its slaves. The master MUST include parameters req= uired by local regulatory policy, e.g. device ID, manufacturer's serial num= ber, channel usage and power level information of the master and its slaves= .

=  <= /u5:p>=

= New steps cou= ld be introduced into one or more use cases to cover these Ofcom requiremen= ts, e.g. new steps 6bis and 9bis in the hotspot use case at 4.2.1:

=  <= /u5:p>=

6bis. Prior to initiating transmission, if required by loc= al regulation, the master/AP informs the database of the channel and power level it has chosen. This is repeated for each sl= ave that associated with the master.

 

9bis. Prior to initiating transmission, if required by loc= al regulation, the slave informs the master/AP of the channel and power level it has chosen, and themaster/AP relays this= information to the database.

=  <= /u5:p>=

= - end of new = text -

=  <= /u5:p>=

= For informati= on, for those not accessing the url in the first paragraph of this email, t= he full Ofcom requirements leading to this new PAWS text are as follows:=

=  <= /u5:p>=

= 3.18 After re= ceiving instructions from a WSDB in relation to the maximum permitted EIRPs= over the DTT channels, and prior to initiating transmissions within the UHF TV band, a master WSD mustcommunicate to the = WSDB the following information:

3.18.1 The lower and upper frequency boundaries13 of the in-block emissions of the master WSD, and those of the in-block emissions of its associated slaves. A lower freq= uency will be specified as (470 + 8k + 0.2n) MHz, with the correspo= nding upper frequency specified as (470 + 8k + 0.2m) MHz, where 0 = =A1=C2 k =A1=C2 39, 0 =A1=C2 n =A1=C2 39, 1 =A1=C2 m =A1=C2 40, and n < = m.

3.18.2 The maximum in-block EIRP spectral densities (in dB= m/(0.2 MHz)) that the masterWSD, and its associated slaves, actually radiate between each reported lower frequency boundary an= d its corresponding upper frequency boundary.

=  <= /u5:p>=

= Footnote 13 s= tates:

= The use of up= per and lower frequency boundaries (defined over a 200 kHz raster) allows a= WSDB to collect more granular information with regards to the usage of the frequency resource bynarrowband WSD technologi= es. The upper and lower frequencies of a boundary pair do not straddle a DT= T channel boundary. Note that a WSD may transmit over multiple, non-contigu= ous, whole DTT channels or fractions of DTT channels.

=  <= /u5:p>=

= 3.19 A master= WSD must be able to receive the following information14 from a = WSDB:

= <snip><= u5:p>

3.19.8     [An acknowledgement from th= e WSDB, in the context of 3.18, that the reported information on the DTT channels and EIRP spectral densities actually used by the master and s= lave WSDs were received successfully by the WSDB18].

=  <= /u5:p>=

= Footnote 14 s= tates:

= 14 While the = communication of some of this information from a WSDB to a master WSD is op= tional, master WSDs must be able to receive and interpret these.

=  <= /u5:p>=

= Footnote 18 s= tates:

= 18 This forms= part of a handshake protocol and may be an area where industry could harmo= nise without the need for an explicit requirement in the regulations.

=  <= /u5:p>=

= Regards=

=  <= /u5:p>=

= Andy

=  <= /u5:p>=

= From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com
Sent: 05 March 2012 19:46 To: paws@ietf.org
Subject: [paws] WGLC for dra= ft-ietf-paws-problem-stmt-usecases-rqmts-03

 

The authors of the use cases = and requirements draft have just posted a new version of the draft and indi= cated that there are no unresolved comments/issues they are aware of.

 

Therefore, I'd like to initia= te a WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-r= qmts-03.txt

 

Please review the draft and s= end yourcomments to the list by March 20th, 2012.

 

If you review the draft and h= ave no comments, send a note to the list that the draft is good as it is, w= e need these notes as much as we need the actual comments.

 

Thanks, Gabor

 

________________________________= _______________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws

--_000_CB7BA2DC1392Ascottprobasconokiacom_-- From gerald.chouinard@sympatico.ca Tue Mar 6 09:44:18 2012 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 DF07321F85E1 for ; Tue, 6 Mar 2012 09:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.135 X-Spam-Level: X-Spam-Status: No, score=0.135 tagged_above=-999 required=5 tests=[AWL=1.103, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, MSGID_FROM_MTA_HEADER=0.803, 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 uBj1SnkTpt-h for ; Tue, 6 Mar 2012 09:44:14 -0800 (PST) Received: from blu0-omc3-s3.blu0.hotmail.com (blu0-omc3-s3.blu0.hotmail.com [65.55.116.78]) by ietfa.amsl.com (Postfix) with ESMTP id 5313111E8094 for ; Tue, 6 Mar 2012 09:44:13 -0800 (PST) Received: from BLU0-SMTP39 ([65.55.116.74]) by blu0-omc3-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Mar 2012 09:44:12 -0800 X-Originating-IP: [174.95.242.231] X-Originating-Email: [gerald.chouinard@sympatico.ca] Message-ID: Received: from Gerald2 ([174.95.242.231]) by BLU0-SMTP39.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Mar 2012 09:44:10 -0800 From: Gerald Chouinard To: References: Date: Tue, 6 Mar 2012 12:44:09 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EA_01CCFB96.D44F1340" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AQHM+7qBJZkKE/OsEE6WAJSH4Dz7PpZdfy+A//+SKwCAAHc5wA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 06 Mar 2012 17:44:11.0201 (UTC) FILETIME=[BD1D5310:01CCFBC0] Cc: paws@ietf.org Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 17:44:18 -0000 ------=_NextPart_000_00EA_01CCFB96.D44F1340 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Scott, =20 I am fine with your second sentence. However, I have some difficulty = with your third sentence since this would mean that the IETF-PAWS would get = into defining the signaling details between the slave and the master devices. = I believe this should be left to the wireless standard. Obviously, having this information available at the master would become a requirement that = the wireless standard would have to meet to be able to operate in white = space. The way it would be done would be internal to the wireless standard. = PAWS would take it from the master to the database. =20 Gerald =20 _____ =20 From: scott.probasco@Nokia.com [mailto:scott.probasco@Nokia.com]=20 Sent: Tuesday, 06 March, 2012 12:32 To: gerald.chouinard@sympatico.ca Cc: paws@ietf.org Subject: Re: [paws] WGLC for = draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting =20 Hi Gerald, =20 I believe Andy's proposal agrees with your suggestion below. Looking at O.13bis, the slave MAY send the channel usage information and if it does = so, it MUST include the following variables. I think P.12bis is appropriate since the message MUST be defined by the protocol in order to have the OPTION of sending it. When these two requirements are considered jointly does this provide the implementation flexibility you are thinking of? =20 Kind Regards, Scott =20 From: ext Chouinard Date: Tue, 6 Mar 2012 12:13:05 -0500 To: Scott Probasco Cc: "paws@ietf.org" Subject: RE: [paws] WGLC for = draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting =20 Scott, =20 I am fine with your approach as long as the text says something as = follows: =A1=B0the operating channel of the slave needs to be provided to the = database=A1=B1 rather than: =A1=B0the slave needs to provide the database with its = operating channel=A1=B1. This way, this information can be provided by either the = slave or the master, not making it mandatory that the =A1=B0slave=A1=B1 has to = do it if the master knows the information. =20 The text proposed by Andy: =A1=B0The protocol MUST support a channel = usage message from the slave device to the master device.=A1=B1 Implies that = the protocol to be developed needs to apply on the connection between the = slave and the master. Such connection should be implementation dependant. = What is required is that the information be available to the master for it to transmit it to the database, never mind the format that isused between = the slave and the master to carry this information. =20 Gerald =20 _____ =20 From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com]=20 Sent: Tuesday, 06 March, 2012 12:00 To: gerald.chouinard@sympatico.ca; andy.sago@bt.com Cc: paws@ietf.org Subject: Re: [paws] WGLC for = draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting =20 Hi Gerald, =20 At least according to the FCC, a slave (Mode I) device may utilize = channels that the master (fixed device) cannot use, see =A1=EC15.707 and 15.712. = Thus there are potential situations where the master cannot be assumed to = know what channel the slave is using. Although this is a bit esoteric as the = FCC is silent about what the slave might do on those channels, it is = nonetheless included in the FCC regulations. =20 So I suggest we have no reason to overrule Ofcom requirements for = channel usage information. Also Andy's choice of words does ensure that this information is not required to be used in every operational scenario. =20 Kind Regards, Scott =20 =20 =20 From: ext Chouinard Date: Tue, 6 Mar 2012 11:44:07 -0500 To: ext com Cc: "paws@ietf.org" Subject: Re: [paws] WGLC for = draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting =20 Andy, =20 Looking at your suggestions below, it seems that there is a need to = define more precisely what a =A1=B0slave=A1=B1 device is relative to its = =A1=B0master=A1=B1. =20 In my view, a slave can only use the same transmission channel as that = used by the master to which it is associated (otherwise, master and slaves = would not be able to talk to each other). As a consequence, the slave does not have to indicate to the master the channel on which it is operating = since the master knows it and can provided it to the database e. =20 Similarly, modern bidirectional communication systems between a master = and a slave device assumes that there will be a transmit power control (TPC) = loop between the two devices to minimize the required transmit power in = various propagation environments. The driving device in this closed-loop process will be the master and as a result, the EIRP transmitted by the slave = device will be known to the master as long as there is a known factor linking = the power specification sent by the master to the slave and the actual EIRP transmitted by the slave. Such factor which is a constant for each = device can be provided from the slave to the master once at association. As a result, the slave does not need to inform the master of its current (and provably continuously varying) EIRP since the master will havethis information from its TPC process and can provide it to the database = onbehalf of the slave device. =20 Gerald =20 _____ =20 From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of andy.sago@bt.com Sent: Tuesday, 06 March, 2012 10:42 To: paws@ietf.org; Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for = draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting =20 All =20 Comparing the draft with the Ofcom requirements at http://www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-regulato= ry- requirements-for-white-space-devices-in-the-UHF-TV-band, I believe the = WG draft is deficient in the area of reporting frequencies and powers = actually used by masters and slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom intends to collect this data to assesses the impact of aggregate interference into other services. It would also provide usage = information (frequency in use) that would inform the operation of a kill switch capability. I suggest this deficiency can be remedied with the following changes: =20 New P requirements (probably best placed following P.12): =20 P.12bis: The protocol MUST support a channel usage message from the = slave device to the master device. The channel usage message MUST include parameters as required by local regulatory requirement. These = parameters MAY include device ID, manufacturer's serial number, channel usage and = power level information. =20 P.12ter: The protocol MUST support a channel usage message from the = master device to the database. The channel usage message MUST include = parameters as required by local regulatory requirement for the master and its associated slaves. These parameters MAY include device ID, = manufacturer's serial number, channel usage and power level information. =20 P.12qua: The protocol MUST support a channel usage message = acknowledgement. =20 New O requirements (probably best placed following O13): =20 O.13bis: According to local regulatory policy, after connecting to a = master device'sradio network a slave device MAY inform the master device of the actual channel usage. The slave MUST include parameters required by = local regulatory policy, e.g. device ID, manufacturer's serial number, channel usage and power levelinformation. =20 O.13ter: According to local regulatory policy, a master device MAY = inform the database of the actual channel usage of the master and its slaves. = The master MUST include parameters required by local regulatory policy, e.g. device ID, manufacturer's serial number, channel usage and power level information of the master and its slaves. =20 New steps could be introduced into one or more use cases to cover these Ofcom requirements, e.g. new steps 6bis and 9bis in the hotspot use case = at 4.2.1: =20 6bis. Prior to initiating transmission, if required by local regulation, = the master/AP informs the database of the channel and power level it has = chosen. This is repeated for each slave that associated with the master. =20 9bis. Prior to initiating transmission, if required by local regulation, = the slave informs the master/AP of the channel and power level it has = chosen, and themaster/AP relays this information to the database.=20 =20 - end of new text - =20 For information, for those not accessing the url in the first paragraph = of this email, the full Ofcom requirements leading to this new PAWS text = are as follows: =20 3.18 After receiving instructions from a WSDB in relation to the maximum permitted EIRPs over the DTT channels, and prior to initiating = transmissions within the UHF TV band, a master WSD mustcommunicate to the WSDB the following information: 3.18.1 The lower and upper frequency boundaries13 of the in-block = emissions of the master WSD, and those of the in-block emissions of its associated slaves. A lower frequency will be specified as (470 + 8k + 0.2n) MHz, = with the corresponding upper frequency specified as (470 + 8k + 0.2m) MHz, = where 0 =A1=DC k =A1=DC 39, 0 =A1=DC n =A1=DC 39, 1 =A1=DC m =A1=DC 40, and n = < m. 3.18.2 The maximum in-block EIRP spectral densities (in dBm/(0.2 MHz)) = that the masterWSD, and its associated slaves, actually radiate between each reported lower frequency boundary and its corresponding upper frequency boundary. =20 Footnote 13 states: The use of upper and lower frequency boundaries (defined over a 200 kHz raster) allows a WSDB to collect more granular information with regards = to the usage of the frequency resource bynarrowband WSD technologies. The = upper and lower frequencies of a boundary pair do not straddle a DTT channel boundary. Note that a WSD may transmit over multiple, non-contiguous, = whole DTT channels or fractions of DTT channels. =20 3.19 A master WSD must be able to receive the following information14 = from a WSDB: 3.19.8 [An acknowledgement from the WSDB, in the context of 3.18, = that the reported information on the DTT channels and EIRP spectral densities actually used by the master and slave WSDs were received successfully by = the WSDB18]. =20 Footnote 14 states: 14 While the communication of some of this information from a WSDB to a master WSD is optional, master WSDs must be able to receive and = interpret these. =20 Footnote 18 states: 18 This forms part of a handshake protocol and may be an area where = industry could harmonise without the need for an explicit requirement in the regulations. =20 Regards =20 Andy =20 From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com Sent: 05 March 2012 19:46 To: paws@ietf.org Subject: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03 =20 The authors of the use cases and requirements draft have just posted a = new version of the draft and indicated that there are no unresolved comments/issues they are aware of. =20 Therefore, I'd like to initiate a WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases= -rq mts-03.txt =20 Please review the draft and send yourcomments to the list by March 20th, 2012. =20 If you review the draft and have no comments, send a note to the list = that the draft is good as it is, we need these notes as much as we need the actual comments. =20 Thanks, Gabor =20 _______________________________________________ paws mailing list = paws@ietf. org https://www.ietf.org/mailman/listinfo/paws ------=_NextPart_000_00EA_01CCFB96.D44F1340 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Scott,

 

I am fine with your second = sentence.  However, I have some difficulty with your third sentence since this would mean = that the IETF-PAWS would get into defining the signaling details between the = slave and the master devices. I believe this should be left to the wireless = standard.  Obviously, having this information available at the master would become a = requirement that the wireless standard would have to meet to be able to operate in white = space. The way it would be done would be internal to the wireless standard. =  PAWS would take it from the master to the = database.

 

Gerald

 

From: = scott.probasco@Nokia.com [mailto:scott.probasco@Nokia.com]
Sent: Tuesday, 06 March, = 2012 12:32
To: gerald.chouinard@sympatico.ca
Cc: paws@ietf.org
Subject: Re: [paws] WGLC = for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel = reporting

 

Hi = Gerald,

 

I believe Andy's proposal agrees = with your suggestion below. Looking at O.13bis, the slave MAY send the channel = usage information and if it does so, it MUST include the following variables. = I think P.12bis is appropriate since the message MUST be defined by the protocol = in order to have the OPTION of sending it. When these two requirements are considered jointly does this provide the implementation flexibility you = are thinking of?

 

Kind = Regards,

Scott

=

 

From: ext Chouinard <gerald.chouinard@sympatico.= ca>
Date: Tue, 6 Mar 2012 = 12:13:05 -0500
To: Scott Probasco <scott.probasco@nokia.com>=
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] WGLC = for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel = reporting

 

Scott,

 

I am fine with your approach as = long as the text says something as follows: =A1=B0the operating channel of the = slave needs to be provided to the database=A1=B1 rather than: =A1=B0the slave needs = to provide the database with its operating channel=A1=B1.  This way, this information can = be provided by either the slave or the master, not making it mandatory that the = =A1=B0slave=A1=B1 has to do it if the master knows the = information.

 

The text proposed by Andy: = =A1=B0The protocol MUST support a channel usage message from the slave device to = the master device.=A1=B1 Implies that the protocol to be developed needs to = apply on the connection between the slave and the master. Such connection should be implementation dependant.  What is required is that the information = be available to the master for it to transmit it to the database, never = mind the format that isused between the slave and the master to carry this = information.

 

Gerald

 

From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com<= /a>]
Sent: Tuesday, 06 March, = 2012 12:00
To: gerald.chouinard@sympatico.= ca; andy.sago@bt.com
Cc: paws@ietf.org
Subject: Re: [paws] WGLC = for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel = reporting

 

Hi = Gerald,

 <= font color=3Dblack>

At least according to the FCC, a = slave (Mode I) device may utilize channels that the master (fixed device) = cannot use, see =A1=EC15.707 and 15.712. Thus there are potential situations where = the master cannot be assumed to know what channel the slave is using. Although this = is a bit esoteric as the FCC is silent about what the slave might do on those channels, it is nonetheless included in the FCC = regulations.

 <= font color=3Dblack>

So I suggest we have no reason to = overrule Ofcom requirements for channel usage information. Also Andy's choice of = words does ensure that this information is not required to be used in every operational scenario.

 <= font color=3Dblack>

Kind = Regards,

Scott

 <= font color=3Dblack>

 <= font color=3Dblack>

 <= font color=3Dblack>

From: ext Chouinard <gerald.chouinard@sympatico.= ca>
Date: Tue, 6 Mar 2012 = 11:44:07 -0500
To: ext com <andy.sago@bt.com>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] WGLC = for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel = reporting

 <= font color=3Dblack>

Andy,

 

Looking at your suggestions below, = it seems that there is a need to define more precisely what a = =A1=B0slave=A1=B1 device is relative to its =A1=B0master=A1=B1.

 

In my view, a slave can only use = the same transmission channel as that used by the master to which it is = associated (otherwise, master and slaves would not be able to talk to each other). = As a consequence, the slave does not have to indicate to the master the = channel on which it is operating since the master knows it and can provided it to = the database e.

 

Similarly, modern bidirectional communication systems between a master and a slave device assumes that = there will be a transmit power control (TPC) loop between the two devices to = minimize the required transmit power in various propagation environments. The = driving device in this closed-loop process will be the master and as a result, = the EIRP transmitted by the slave device will be known to the master as long as = there is a known factor linking the power specification sent by the master to the = slave and the actual EIRP transmitted by the slave.  Such factor which is = a constant for each device can be provided from the slave to the master = once at association.  As a result, the slave does not need to inform the = master of its current (and provably continuously varying) EIRP since the master = will havethis information from its TPC process and can provide it to the = database onbehalf of the slave device.

 

Gerald

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] = On Behalf Of andy.sago@bt.com
Sent: Tuesday, 06 March, = 2012 10:42
To: paws@ietf.org; Gabor.Bajko@nokia.com
Subject: Re: [paws] WGLC = for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel = reporting=

 

All

 

Comparing the draft with the = Ofcom requirements at http:= //www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-regulatory-re= quirements-for-white-space-devices-in-the-UHF-TV-band, I believe the WG draft is deficient in the area of reporting frequencies = and powers actually used by masters and slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom intends to collect this data to assesses the impact of = aggregate interference into other services. It would also provide usage = information (frequency in use) that would inform the operation of a kill switch = capability. I suggest this deficiency can be remedied with the following = changes:

 

New P requirements (probably = best placed following P.12):

 

P.12bis: The protocol MUST support a channel usage message from the slave device = to the master device.  The channel usage message MUST include parameters = as required by local regulatory requirement.  These parameters MAY = include device ID, manufacturer's serial number, channel usage and power level information.

 

P.12ter: The protocol MUST support a channel usage message from the master device = to the database.  The channel usage message MUST include parameters as = required by local regulatory requirement for the master and its associated = slaves.  These parameters MAY include device ID, manufacturer's serial number, = channel usage and power level information.

 

P.12qua: The protocol MUST support a channel usage message = acknowledgement.

 

New O requirements (probably = best placed following O13):

 

O.13bis:  According to local regulatory policy, after connecting to a master device'sradio network a slave device MAY inform the master device of the = actual channel usage. The slave MUST include parameters required by local = regulatory policy, e.g. device ID, manufacturer's serial number, channel usage and = power levelinformation.

 

O.13ter:  According to local regulatory policy, a master device MAY inform the = database of the actual channel usage of the master and its slaves. The master = MUST include parameters required by local regulatory policy, e.g. device ID, manufacturer's serial number, channel usage and power level information = of the master and its slaves.

 

New steps could be introduced = into one or more use cases to cover these Ofcom requirements, e.g. new steps 6bis = and 9bis in the hotspot use case at 4.2.1:

 

6bis. Prior to initiating transmission, if required by local regulation, the master/AP informs the database of the channel and power level it has = chosen. This is repeated for each slave that associated with the = master.

 

9bis. Prior to initiating transmission, if required by local regulation, the = slave informs the master/AP of the channel and power level it has chosen, and themaster/AP relays this information to the database. =

 

- end of new text = -

 

For information, for those not = accessing the url in the first paragraph of this email, the full Ofcom = requirements leading to this new PAWS text are as = follows:

 

3.18 After receiving = instructions from a WSDB in relation to the maximum permitted EIRPs over the DTT channels, = and prior to initiating transmissions within the UHF TV band, a master WSD mustcommunicate to the WSDB the following = information:

3.18.1 The lower and upper frequency boundaries13 of the in-block = emissions of the master WSD, and those of the in-block emissions of its associated = slaves. A lower frequency will be specified as (470 + 8k + 0.2n) MHz, with the corresponding upper frequency specified as (470 + 8k + 0.2m) MHz, where = 0 =A1=DC k =A1=DC 39, 0 =A1=DC n =A1=DC 39, 1 =A1=DC m =A1=DC 40, and n < = m.

3.18.2 The maximum in-block EIRP spectral densities (in dBm/(0.2 MHz)) that the = masterWSD, and its associated slaves, actually radiate between each reported lower frequency boundary and its corresponding upper frequency = boundary.

 

Footnote 13 = states:

The use of upper and lower = frequency boundaries (defined over a 200 kHz raster) allows a WSDB to collect more granular information with regards to the usage of the frequency resource = bynarrowband WSD technologies. The upper and lower frequencies of a boundary pair do = not straddle a DTT channel boundary. Note that a WSD may transmit over = multiple, non-contiguous, whole DTT channels or fractions of DTT = channels.

 

3.19 A master WSD must be able = to receive the following information14 from a = WSDB:

<snip>=

3.19.8     [An acknowledgement from the WSDB, in the context of 3.18, that the = reported information on the DTT channels and EIRP spectral densities actually = used by the master and slave WSDs were received successfully by the = WSDB18].

 

Footnote 14 = states:

14 While the communication of = some of this information from a WSDB to a master WSD is optional, master WSDs = must be able to receive and interpret these.

 

Footnote 18 = states:

18 This forms part of a = handshake protocol and may be an area where industry could harmonise without the = need for an explicit requirement in the = regulations.

 

Regards

 

Andy<= font color=3Dblack>

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] = On Behalf Of Gabor.Bajko@nokia.com
Sent: 05 March 2012 = 19:46
To: paws@ietf.org
Subject: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03=

 

The authors of the use cases and requirements draft have just posted a new version of the draft and = indicated that there are no unresolved comments/issues they are aware = of.

 

Therefore, I'd like to initiate a = WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paw= s-problem-stmt-usecases-rqmts-03.txt

 

Please review the draft and send yourcomments to the list by March 20th, = 2012.

 

If you review the draft and have = no comments, send a note to the list that the draft is good as it is, we = need these notes as much as we need the actual = comments.

 

Thanks, = Gabor

 

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

------=_NextPart_000_00EA_01CCFB96.D44F1340-- From andy.sago@bt.com Tue Mar 6 09:45:16 2012 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 2BEC721E800C for ; Tue, 6 Mar 2012 09:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.963 X-Spam-Level: X-Spam-Status: No, score=-2.963 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 tsnNq7y9GbFU for ; Tue, 6 Mar 2012 09:45:15 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id B88DC21F8647 for ; Tue, 6 Mar 2012 09:45:14 -0800 (PST) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 6 Mar 2012 17:45:12 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.196]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Tue, 6 Mar 2012 17:45:12 +0000 From: To: , Date: Tue, 6 Mar 2012 17:45:13 +0000 Thread-Topic: WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03 Thread-Index: Acz7CHkh/FNx3kOiQQWaHcNbcyzaWwArxp5A Message-ID: <619CDADDCCD2B44380834BE8BF6F7141406914613F@EMV62-UKRD.domain1.systemhost.net> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601E1A52E@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601E1A52E@008-AM1MPN1-006.mgdnok.nokia.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: multipart/alternative; boundary="_000_619CDADDCCD2B44380834BE8BF6F7141406914613FEMV62UKRDdoma_" MIME-Version: 1.0 Cc: johnny.dixon@bt.com, chris.cheeseman@bt.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 17:45:16 -0000 --_000_619CDADDCCD2B44380834BE8BF6F7141406914613FEMV62UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All I believe that the WG draft has an omission in P.11 relating to the paramet= ers that MAY be sent from the master device to the database. The data model= in D.1 allows for location uncertainty, height and height uncertainty. The= se items are not mentioned in the parameters in P.11, and all (except heigh= t uncertainty) are required by Ofcom in http://www.cept.org/Documents/se-43= /4161/SE43(12)Info03_Draft-UK-regulatory-requirements-for-white-space-devic= es-in-the-UHF-TV-band. I propose the following change: P.11: The protocol MUST support a channel query request from the master de= vice to the database. The channel query request message MUST include param= eters as required by local regulatory requirement. These parameters MAY in= clude device location, location uncertainty, device height, height = uncertainty, device ID, manufacturer's serial number, and antenna = characteristic information. Regards Andy From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gab= or.Bajko@nokia.com Sent: 05 March 2012 19:46 To: paws@ietf.org Subject: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03 The authors of the use cases and requirements draft have just posted a new = version of the draft and indicated that there are no unresolved comments/is= sues they are aware of. Therefore, I'd like to initiate a WG Last Call for comments on http://www.i= etf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rqmts-03.txt Please review the draft and send your comments to the list by March 20th, 2= 012. If you review the draft and have no comments, send a note to the list that = the draft is good as it is, we need these notes as much as we need the actu= al comments. Thanks, Gabor --_000_619CDADDCCD2B44380834BE8BF6F7141406914613FEMV62UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All

 

I bel= ieve that the WG draft has an omission in P.11 relating to the parameters t= hat MAY be sent from the master device to the database. The data model in D= .1 allows for location uncertainty, height and height uncertainty. These it= ems are not mentioned in the parameters in P.11, and all (except height unc= ertainty) are required by Ofcom in http://www.cept.org/Documents/se-43/4161/SE43(= 12)Info03_Draft-UK-regulatory-requirements-for-white-space-devices-in-the-U= HF-TV-band. I propose the following change:

 

P.11:  The protocol MUST support a channel query request from = the master device to the database.  The channel query request message = MUST include parameters as required by local regulatory requirement.  = These parameters MAY include device location, <Insert>location uncert= ainty, device height, height uncertainty, </Insert>device ID, manufac= turer's serial number, and antenna characteristic information.

 

Regards

 

Andy=

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf= .org] On Behalf Of Gabor.Bajko@nokia.com
Sent: 05 March 20= 12 19:46
To: paws@ietf.org
Subject: [paws] WGLC for dra= ft-ietf-paws-problem-stmt-usecases-rqmts-03

 

The authors of the use cases and requirements draft have just p= osted a new version of the draft and indicated that there are no unresolved= comments/issues they are aware of.

 

=

Therefore,= I'd like to initiate a WG Last Call for comments on List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 18:05:24 -0000 --_000_CB7BA9DB1394Escottprobasconokiacom_ Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGkgR2VyYWxkLA0KDQpJIGFncmVlIHdpdGggeW91IHRoYXQgc29tZSB3aXJlbGVzcyBzdGFuZGFy ZHMgd2lsbCBpbmNsdWRlIHNpZ25hbGluZyB0aGF0IHN1cHBvcnRzIGRhdGFiYXNlIGFjY2Vzcy4g QnV0IFBBV1MgaXMgbm90IHNwZWNpZmljIHRvIGFueSBwYXJ0aWN1bGFyIHJhZGlvIHRlY2hub2xv Z3ksIHdlIGNhbm5vdCBleHBlY3QgdGhhdCBhbGwgcmFkaW8gdGVjaG5vbG9naWVzIHdpbGwgaW5j bHVkZSBzb21lIGNvbXBvbmVudHMgb2YgdGhlIHNpZ25hbGluZyBmb3IgZGF0YWJhc2UgYWNjZXNz LiBQQVdTIHNob3VsZCBpbmNsdWRlIGFsbCBuZWNlc3NhcnkgbWVzc2FnZXMgZm9yIGNvbnRhY3Qg YmV0d2VlbiB0aGUgZGV2aWNlIGFuZCB0aGUgZGF0YWJhc2UsIHdpdGhvdXQgcHJlc3VtcHRpb24g b2YgdGhlIHVuZGVybHlpbmcgcmFkaW8gdGVjaG5vbG9neS4NCg0KS2luZCBSZWdhcmRzLA0KU2Nv dHQNCg0KRnJvbTogZXh0IENob3VpbmFyZCA8Z2VyYWxkLmNob3VpbmFyZEBzeW1wYXRpY28uY2E8 bWFpbHRvOmdlcmFsZC5jaG91aW5hcmRAc3ltcGF0aWNvLmNhPj4NCkRhdGU6IFR1ZSwgNiBNYXIg MjAxMiAxMjo0NDowOSAtMDUwMA0KVG86IFNjb3R0IFByb2Jhc2NvIDxzY290dC5wcm9iYXNjb0Bu b2tpYS5jb208bWFpbHRvOnNjb3R0LnByb2Jhc2NvQG5va2lhLmNvbT4+DQpDYzogInBhd3NAaWV0 Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+IiA8cGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0Bp ZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogW3Bhd3NdIFdHTEMgZm9yIGRyYWZ0LWlldGYtcGF3cy1w cm9ibGVtLXN0bXQtdXNlY2FzZXMtcnFtdHMtMDM6IGNoYW5uZWwgcmVwb3J0aW5nDQoNClNjb3R0 LA0KDQpJIGFtIGZpbmUgd2l0aCB5b3VyIHNlY29uZCBzZW50ZW5jZS4gIEhvd2V2ZXIsIEkgaGF2 ZSBzb21lIGRpZmZpY3VsdHkgd2l0aCB5b3VyIHRoaXJkIHNlbnRlbmNlIHNpbmNlIHRoaXMgd291 bGQgbWVhbiB0aGF0IHRoZSBJRVRGLVBBV1Mgd291bGQgZ2V0IGludG8gZGVmaW5pbmcgdGhlIHNp Z25hbGluZyBkZXRhaWxzIGJldHdlZW4gdGhlIHNsYXZlIGFuZCB0aGUgbWFzdGVyIGRldmljZXMu IEkgYmVsaWV2ZSB0aGlzIHNob3VsZCBiZSBsZWZ0IHRvIHRoZSB3aXJlbGVzcyBzdGFuZGFyZC4g IE9idmlvdXNseSwgaGF2aW5nIHRoaXMgaW5mb3JtYXRpb24gYXZhaWxhYmxlIGF0IHRoZSBtYXN0 ZXIgd291bGQgYmVjb21lIGEgcmVxdWlyZW1lbnQgdGhhdCB0aGUgd2lyZWxlc3Mgc3RhbmRhcmQg d291bGQgaGF2ZSB0byBtZWV0IHRvIGJlIGFibGUgdG8gb3BlcmF0ZSBpbiB3aGl0ZSBzcGFjZS4g VGhlIHdheSBpdCB3b3VsZCBiZSBkb25lIHdvdWxkIGJlIGludGVybmFsIHRvIHRoZSB3aXJlbGVz cyBzdGFuZGFyZC4gIFBBV1Mgd291bGQgdGFrZSBpdCBmcm9tIHRoZSBtYXN0ZXIgdG8gdGhlIGRh dGFiYXNlLg0KDQpHZXJhbGQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZy b206IHNjb3R0LnByb2Jhc2NvQE5va2lhLmNvbTxtYWlsdG86c2NvdHQucHJvYmFzY29ATm9raWEu Y29tPiBbbWFpbHRvOnNjb3R0LnByb2Jhc2NvQE5va2lhLmNvbV0NClNlbnQ6IFR1ZXNkYXksIDA2 IE1hcmNoLCAyMDEyIDEyOjMyDQpUbzogZ2VyYWxkLmNob3VpbmFyZEBzeW1wYXRpY28uY2E8bWFp bHRvOmdlcmFsZC5jaG91aW5hcmRAc3ltcGF0aWNvLmNhPg0KQ2M6IHBhd3NAaWV0Zi5vcmc8bWFp bHRvOnBhd3NAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3Bhd3NdIFdHTEMgZm9yIGRyYWZ0LWll dGYtcGF3cy1wcm9ibGVtLXN0bXQtdXNlY2FzZXMtcnFtdHMtMDM6IGNoYW5uZWwgcmVwb3J0aW5n DQoNCkhpIEdlcmFsZCwNCg0KSSBiZWxpZXZlIEFuZHkncyBwcm9wb3NhbCBhZ3JlZXMgd2l0aCB5 b3VyIHN1Z2dlc3Rpb24gYmVsb3cuIExvb2tpbmcgYXQgTy4xM2JpcywgdGhlIHNsYXZlIE1BWSBz ZW5kIHRoZSBjaGFubmVsIHVzYWdlIGluZm9ybWF0aW9uIGFuZCBpZiBpdCBkb2VzIHNvLCBpdCBN VVNUIGluY2x1ZGUgdGhlIGZvbGxvd2luZyB2YXJpYWJsZXMuIEkgdGhpbmsgUC4xMmJpcyBpcyBh cHByb3ByaWF0ZSBzaW5jZSB0aGUgbWVzc2FnZSBNVVNUIGJlIGRlZmluZWQgYnkgdGhlIHByb3Rv Y29sIGlub3JkZXIgdG8gaGF2ZSB0aGUgT1BUSU9OIG9mIHNlbmRpbmcgaXQuIFdoZW4gdGhlc2Ug dHdvIHJlcXVpcmVtZW50cyBhcmUgY29uc2lkZXJlZCBqb2ludGx5IGRvZXMgdGhpcyBwcm92aWRl IHRoZSBpbXBsZW1lbnRhdGlvbiBmbGV4aWJpbGl0eSB5b3UgYXJldGhpbmtpbmcgb2Y/DQoNCktp bmQgUmVnYXJkcywNClNjb3R0DQoNCkZyb206IGV4dCBDaG91aW5hcmQgPGdlcmFsZC5jaG91aW5h cmRAc3ltcGF0aWNvLmNhPG1haWx0bzpnZXJhbGQuY2hvdWluYXJkQHN5bXBhdGljby5jYT4+DQpE YXRlOiBUdWUsIDYgTWFyIDIwMTIgMTI6MTM6MDUgLTA1MDANClRvOiBTY290dCBQcm9iYXNjbyA8 c2NvdHQucHJvYmFzY29Abm9raWEuY29tPG1haWx0bzpzY290dC5wcm9iYXNjb0Bub2tpYS5jb20+ Pg0KQ2M6ICJwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPiIgPHBhd3NAaWV0Zi5v cmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUkU6IFtwYXdzXSBXR0xDIGZvciBk cmFmdC1pZXRmLXBhd3MtcHJvYmxlbS1zdG10LXVzZWNhc2VzLXJxbXRzLTAzOiBjaGFubmVsIHJl cG9ydGluZw0KDQpTY290dCwNCg0KSSBhbSBmaW5lIHdpdGggeW91ciBhcHByb2FjaCBhcyBsb25n IGFzIHRoZSB0ZXh0IHNheXMgc29tZXRoaW5nIGFzIGZvbGxvd3M6IKGwdGhlIG9wZXJhdGluZyBj aGFubmVsIG9mIHRoZSBzbGF2ZSBuZWVkcyB0byBiZSBwcm92aWRlZCB0byB0aGUgZGF0YWJhc2Wh sSByYXRoZXIgdGhhbjogobB0aGUgc2xhdmUgbmVlZHMgdG8gcHJvdmlkZSB0aGUgZGF0YWJhc2Ug d2l0aCBpdHMgb3BlcmF0aW5nIGNoYW5uZWyhsS4gIFRoaXMgd2F5LCB0aGlzIGluZm9ybWF0aW9u IGNhbiBiZSBwcm92aWRlZCBieSBlaXRoZXIgdGhlIHNsYXZlIG9yIHRoZSBtYXN0ZXIsIG5vdCBt YWtpbmcgaXQgbWFuZGF0b3J5IHRoYXQgdGhlIKGwc2xhdmWhsSBoYXMgdG8gZG8gaXQgaWYgdGhl IG1hc3RlciBrbm93cyB0aGUgaW5mb3JtYXRpb24uDQoNClRoZSB0ZXh0IHByb3Bvc2VkIGJ5IEFu ZHk6IKGwVGhlIHByb3RvY29sIE1VU1Qgc3VwcG9ydCBhIGNoYW5uZWwgdXNhZ2UgbWVzc2FnZSBm cm9tIHRoZSBzbGF2ZSBkZXZpY2UgdG8gdGhlIG1hc3RlciBkZXZpY2UuobEgSW1wbGllcyB0aGF0 IHRoZSBwcm90b2NvbCB0byBiZSBkZXZlbG9wZWQgbmVlZHMgdG8gYXBwbHkgb24gdGhlIGNvbm5l Y3Rpb24gYmV0d2VlbiB0aGUgc2xhdmUgYW5kIHRoZSBtYXN0ZXIuIFN1Y2ggY29ubmVjdGlvbiBz aG91bGQgYmUgaW1wbGVtZW50YXRpb24gZGVwZW5kYW50LiAgV2hhdCBpcyByZXF1aXJlZCBpcyB0 aGF0IHRoZSBpbmZvcm1hdGlvbiBiZWF2YWlsYWJsZSB0byB0aGUgbWFzdGVyIGZvciBpdCB0byB0 cmFuc21pdCBpdCB0byB0aGUgZGF0YWJhc2UsIG5ldmVyIG1pbmQgdGhlIGZvcm1hdCB0aGF0IGlz dXNlZCBiZXR3ZWVuIHRoZSBzbGF2ZSBhbmQgdGhlIG1hc3RlciB0byBjYXJyeSB0aGlzIGluZm9y bWF0aW9uLg0KDQpHZXJhbGQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZy b206IHNjb3R0LnByb2Jhc2NvQG5va2lhLmNvbTxtYWlsdG86c2NvdHQucHJvYmFzY29Abm9raWEu Y29tPiBbbWFpbHRvOnNjb3R0LnByb2Jhc2NvQG5va2lhLmNvbV0NClNlbnQ6IFR1ZXNkYXksIDA2 IE1hcmNoLCAyMDEyIDEyOjAwDQpUbzogZ2VyYWxkLmNob3VpbmFyZEBzeW1wYXRpY28uY2E8bWFp bHRvOmdlcmFsZC5jaG91aW5hcmRAc3ltcGF0aWNvLmNhPjsgYW5keS5zYWdvQGJ0LmNvbTxtYWls dG86YW5keS5zYWdvQGJ0LmNvbT4NCkNjOiBwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYu b3JnPg0KU3ViamVjdDogUmU6IFtwYXdzXSBXR0xDIGZvciBkcmFmdC1pZXRmLXBhd3MtcHJvYmxl bS1zdG10LXVzZWNhc2VzLXJxbXRzLTAzOiBjaGFubmVsIHJlcG9ydGluZw0KDQpIaSBHZXJhbGQs DQoNCkF0IGxlYXN0IGFjY29yZGluZyB0byB0aGUgRkNDLCBhIHNsYXZlIChNb2RlIEkpIGRldmlj ZSBtYXkgdXRpbGl6ZSBjaGFubmVscyB0aGF0IHRoZSBtYXN0ZXIgKGZpeGVkIGRldmljZSkgY2Fu bm90IHVzZSwgc2VlIKHXMTUuNzA3IGFuZCAxNS43MTIuIFRodXMgdGhlcmUgYXJlIHBvdGVudGlh bCBzaXR1YXRpb25zIHdoZXJlIHRoZSBtYXN0ZXIgY2Fubm90IGJlIGFzc3VtZWQgdG8ga25vdyB3 aGF0IGNoYW5uZWwgdGhlIHNsYXZlIGlzIHVzaW5nLiBBbHRob3VnaCB0aGlzIGlzIGEgYml0IGVz b3RlcmljIGFzIHRoZSBGQ0MgaXMgc2lsZW50IGFib3V0IHdoYXQgdGhlIHNsYXZlIG1pZ2h0IGRv IG9uIHRob3NlIGNoYW5uZWxzLCBpdCBpcyBub25ldGhlbGVzcyBpbmNsdWRlZCBpbiB0aGUgRkND IHJlZ3VsYXRpb25zLg0KDQpTbyBJIHN1Z2dlc3Qgd2UgaGF2ZSBubyByZWFzb24gdG8gb3ZlcnJ1 bGUgT2Zjb20gcmVxdWlyZW1lbnRzIGZvciBjaGFubmVsIHVzYWdlIGluZm9ybWF0aW9uLiBBbHNv IEFuZHkncyBjaG9pY2Ugb2Ygd29yZHMgZG9lcyBlbnN1cmUgdGhhdCB0aGlzIGluZm9ybWF0aW9u IGlzIG5vdCByZXF1aXJlZCB0byBiZSB1c2VkIGluIGV2ZXJ5IG9wZXJhdGlvbmFsIHNjZW5hcmlv Lg0KDQpLaW5kIFJlZ2FyZHMsDQpTY290dA0KDQoNCg0KRnJvbTogZXh0IENob3VpbmFyZCA8Z2Vy YWxkLmNob3VpbmFyZEBzeW1wYXRpY28uY2E8bWFpbHRvOmdlcmFsZC5jaG91aW5hcmRAc3ltcGF0 aWNvLmNhPj4NCkRhdGU6IFR1ZSwgNiBNYXIgMjAxMiAxMTo0NDowNyAtMDUwMA0KVG86IGV4dCBj b20gPGFuZHkuc2Fnb0BidC5jb208bWFpbHRvOmFuZHkuc2Fnb0BidC5jb20+Pg0KQ2M6ICJwYXdz QGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPiIgPHBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBh d3NAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtwYXdzXSBXR0xDIGZvciBkcmFmdC1pZXRmLXBh d3MtcHJvYmxlbS1zdG10LXVzZWNhc2VzLXJxbXRzLTAzOiBjaGFubmVsIHJlcG9ydGluZw0KDQpB bmR5LA0KDQpMb29raW5nIGF0IHlvdXIgc3VnZ2VzdGlvbnMgYmVsb3csIGl0IHNlZW1zIHRoYXQg dGhlcmUgaXMgYSBuZWVkIHRvIGRlZmluZSBtb3JlIHByZWNpc2VseSB3aGF0IGEgobBzbGF2ZaGx IGRldmljZSBpcyByZWxhdGl2ZSB0byBpdHMgobBtYXN0ZXKhsS4NCg0KSW4gbXkgdmlldywgYSBz bGF2ZSBjYW4gb25seSB1c2UgdGhlIHNhbWUgdHJhbnNtaXNzaW9uIGNoYW5uZWwgYXMgdGhhdCB1 c2VkIGJ5IHRoZSBtYXN0ZXIgdG8gd2hpY2ggaXQgaXMgYXNzb2NpYXRlZCAob3RoZXJ3aXNlLCBt YXN0ZXIgYW5kIHNsYXZlcyB3b3VsZCBub3QgYmUgYWJsZSB0byB0YWxrIHRvIGVhY2ggb3RoZXIp LiBBcyBhIGNvbnNlcXVlbmNlLCB0aGUgc2xhdmUgZG9lcyBub3QgaGF2ZSB0byBpbmRpY2F0ZSB0 byB0aGUgbWFzdGVyIHRoZSBjaGFubmVsIG9uIHdoaWNoIGl0IGlzIG9wZXJhdGluZyBzaW5jZSB0 aGUgbWFzdGVyIGtub3dzIGl0IGFuZCBjYW4gcHJvdmlkZWQgaXQgdG8gdGhlIGRhdGFiYXNlIGUu DQoNClNpbWlsYXJseSwgbW9kZXJuIGJpZGlyZWN0aW9uYWwgY29tbXVuaWNhdGlvbiBzeXN0ZW1z IGJldHdlZW4gYSBtYXN0ZXIgYW5kIGEgc2xhdmUgZGV2aWNlIGFzc3VtZXMgdGhhdCB0aGVyZSB3 aWxsIGJlIGEgdHJhbnNtaXQgcG93ZXIgY29udHJvbCAoVFBDKSBsb29wIGJldHdlZW4gdGhlIHR3 byBkZXZpY2VzIHRvIG1pbmltaXplIHRoZSByZXF1aXJlZCB0cmFuc21pdCBwb3dlciBpbiB2YXJp b3VzIHByb3BhZ2F0aW9uIGVudmlyb25tZW50cy4gVGhlIGRyaXZpbmcgZGV2aWNlIGluIHRoaXMg Y2xvc2VkLWxvb3AgcHJvY2VzcyB3aWxsIGJlIHRoZSBtYXN0ZXIgYW5kIGFzIGEgcmVzdWx0LCB0 aGUgRUlSUCB0cmFuc21pdHRlZCBieSB0aGUgc2xhdmUgZGV2aWNlIHdpbGwgYmUga25vd24gdG8g dGhlIG1hc3RlciBhcyBsb25nIGFzIHRoZXJlIGlzIGEga25vd24gZmFjdG9yIGxpbmtpbmcgdGhl IHBvd2VyIHNwZWNpZmljYXRpb24gc2VudCBieSB0aGUgbWFzdGVyIHRvIHRoZSBzbGF2ZSBhbmQg dGhlIGFjdHVhbCBFSVJQIHRyYW5zbWl0dGVkIGJ5IHRoZSBzbGF2ZS4gIFN1Y2ggZmFjdG9yIHdo aWNoIGlzIGEgY29uc3RhbnQgZm9yIGVhY2ggZGV2aWNlIGNhbiBiZSBwcm92aWRlZCBmcm9tIHRo ZSBzbGF2ZSB0byB0aGUgbWFzdGVyIG9uY2UgYXQgYXNzb2NpYXRpb24uICBBcyBhIHJlc3VsdCwg dGhlIHNsYXZlIGRvZXMgbm90IG5lZWQgdG8gaW5mb3JtIHRoZSBtYXN0ZXIgb2YgaXRzIGN1cnJl bnQgKGFuZCBwcm92YWJseSBjb250aW51b3VzbHkgdmFyeWluZykgRUlSUCBzaW5jZSB0aGUgbWFz dGVyIHdpbGwgaGF2ZXRoaXMgaW5mb3JtYXRpb24gZnJvbSBpdHMgVFBDIHByb2Nlc3MgYW5kIGNh biBwcm92aWRlIGl0IHRvIHRoZSBkYXRhYmFzZSBvbmJlaGFsZiBvZiB0aGUgc2xhdmUgZGV2aWNl Lg0KDQpHZXJhbGQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IHBh d3MtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRv OnBhd3MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGFuZHkuc2Fnb0BidC5jb208bWFp bHRvOmFuZHkuc2Fnb0BidC5jb20+DQpTZW50OiBUdWVzZGF5LCAwNiBNYXJjaCwgMjAxMiAxMDo0 Mg0KVG86IHBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+OyBHYWJvci5CYWprb0Bu b2tpYS5jb208bWFpbHRvOkdhYm9yLkJhamtvQG5va2lhLmNvbT4NClN1YmplY3Q6IFJlOiBbcGF3 c10gV0dMQyBmb3IgZHJhZnQtaWV0Zi1wYXdzLXByb2JsZW0tc3RtdC11c2VjYXNlcy1ycW10cy0w MzogY2hhbm5lbCByZXBvcnRpbmcNCg0KQWxsDQoNCkNvbXBhcmluZyB0aGUgZHJhZnQgd2l0aCB0 aGUgT2Zjb20gcmVxdWlyZW1lbnRzIGF0IGh0dHA6Ly93d3cuY2VwdC5vcmcvRG9jdW1lbnRzL3Nl LTQzLzQxNjEvU0U0MygxMilJbmZvMDNfRHJhZnQtVUstcmVndWxhdG9yeS1yZXF1aXJlbWVudHMt Zm9yLXdoaXRlLXNwYWNlLWRldmljZXMtaW4tdGhlLVVIRi1UVi1iYW5kLCBJIGJlbGlldmUgdGhl IFdHIGRyYWZ0IGlzIGRlZmljaWVudCBpbiB0aGUgYXJlYSBvZiByZXBvcnRpbmcgZnJlcXVlbmNp ZXMgYW5kIHBvd2VycyBhY3R1YWxseSB1c2VkIGJ5IG1hc3RlcnMgYW5kIHNsYXZlcyAoT2Zjb20g cmVxdWlyZW1lbnRzIDMuMTggYW5kIDMuMTkuOCkuIE9mY29tIGludGVuZHMgdG8gY29sbGVjdCB0 aGlzIGRhdGEgdG8gYXNzZXNzZXMgdGhlIGltcGFjdCBvZiBhZ2dyZWdhdGUgaW50ZXJmZXJlbmNl IGludG8gb3RoZXIgc2VydmljZXMuIEl0IHdvdWxkIGFsc28gcHJvdmlkZSB1c2FnZSBpbmZvcm1h dGlvbiAoZnJlcXVlbmN5IGluIHVzZSkgdGhhdCB3b3VsZCBpbmZvcm0gdGhlIG9wZXJhdGlvbiBv ZiBhIGtpbGwgc3dpdGNoIGNhcGFiaWxpdHkuIEkgc3VnZ2VzdCB0aGlzIGRlZmljaWVuY3kgY2Fu IGJlIHJlbWVkaWVkIHdpdGggdGhlIGZvbGxvd2luZyBjaGFuZ2VzOg0KDQpOZXcgUCByZXF1aXJl bWVudHMgKHByb2JhYmx5IGJlc3QgcGxhY2VkIGZvbGxvd2luZyBQLjEyKToNCg0KUC4xMmJpczog VGhlIHByb3RvY29sIE1VU1Qgc3VwcG9ydCBhIGNoYW5uZWwgdXNhZ2UgbWVzc2FnZSBmcm9tIHRo ZSBzbGF2ZSBkZXZpY2UgdG8gdGhlIG1hc3RlciBkZXZpY2UuICBUaGUgY2hhbm5lbCB1c2FnZSBt ZXNzYWdlIE1VU1QgaW5jbHVkZSBwYXJhbWV0ZXJzIGFzIHJlcXVpcmVkIGJ5IGxvY2FsIHJlZ3Vs YXRvcnkgcmVxdWlyZW1lbnQuICBUaGVzZSBwYXJhbWV0ZXJzIE1BWSBpbmNsdWRlIGRldmljZSBJ RCwgbWFudWZhY3R1cmVyJ3Mgc2VyaWFsIG51bWJlciwgY2hhbm5lbCB1c2FnZSBhbmQgcG93ZXIg bGV2ZWwgaW5mb3JtYXRpb24uDQoNClAuMTJ0ZXI6IFRoZSBwcm90b2NvbCBNVVNUIHN1cHBvcnQg YSBjaGFubmVsIHVzYWdlIG1lc3NhZ2UgZnJvbSB0aGUgbWFzdGVyIGRldmljZSB0byB0aGUgZGF0 YWJhc2UuICBUaGUgY2hhbm5lbCB1c2FnZSBtZXNzYWdlIE1VU1QgaW5jbHVkZSBwYXJhbWV0ZXJz IGFzIHJlcXVpcmVkIGJ5IGxvY2FsIHJlZ3VsYXRvcnkgcmVxdWlyZW1lbnQgZm9yIHRoZSBtYXN0 ZXIgYW5kIGl0cyBhc3NvY2lhdGVkIHNsYXZlcy4gIFRoZXNlIHBhcmFtZXRlcnMgTUFZIGluY2x1 ZGUgZGV2aWNlIElELCBtYW51ZmFjdHVyZXIncyBzZXJpYWwgbnVtYmVyLCBjaGFubmVsIHVzYWdl IGFuZCBwb3dlciBsZXZlbCBpbmZvcm1hdGlvbi4NCg0KUC4xMnF1YTogVGhlIHByb3RvY29sIE1V U1Qgc3VwcG9ydCBhIGNoYW5uZWwgdXNhZ2UgbWVzc2FnZSBhY2tub3dsZWRnZW1lbnQuDQoNCk5l dyBPIHJlcXVpcmVtZW50cyAocHJvYmFibHkgYmVzdCBwbGFjZWQgZm9sbG93aW5nIE8xMyk6DQoN Ck8uMTNiaXM6ICBBY2NvcmRpbmcgdG8gbG9jYWwgcmVndWxhdG9yeSBwb2xpY3ksIGFmdGVyIGNv bm5lY3RpbmcgdG8gYSBtYXN0ZXIgZGV2aWNlJ3NyYWRpbyBuZXR3b3JrIGEgc2xhdmUgZGV2aWNl IE1BWSBpbmZvcm0gdGhlIG1hc3RlciBkZXZpY2Ugb2YgdGhlIGFjdHVhbCBjaGFubmVsIHVzYWdl LiBUaGUgc2xhdmUgTVVTVCBpbmNsdWRlIHBhcmFtZXRlcnMgcmVxdWlyZWQgYnkgbG9jYWwgcmVn dWxhdG9yeSBwb2xpY3ksIGUuZy4gZGV2aWNlIElELCBtYW51ZmFjdHVyZXIncyBzZXJpYWwgbnVt YmVyLCBjaGFubmVsIHVzYWdlIGFuZCBwb3dlciBsZXZlbGluZm9ybWF0aW9uLg0KDQpPLjEzdGVy OiAgQWNjb3JkaW5nIHRvIGxvY2FsIHJlZ3VsYXRvcnkgcG9saWN5LCBhIG1hc3RlciBkZXZpY2Ug TUFZIGluZm9ybSB0aGUgZGF0YWJhc2Ugb2YgdGhlIGFjdHVhbCBjaGFubmVsIHVzYWdlIG9mIHRo ZSBtYXN0ZXIgYW5kIGl0cyBzbGF2ZXMuIFRoZSBtYXN0ZXIgTVVTVCBpbmNsdWRlIHBhcmFtZXRl cnMgcmVxdWlyZWQgYnkgbG9jYWwgcmVndWxhdG9yeSBwb2xpY3ksIGUuZy4gZGV2aWNlIElELCBt YW51ZmFjdHVyZXIncyBzZXJpYWwgbnVtYmVyLCBjaGFubmVsIHVzYWdlIGFuZCBwb3dlciBsZXZl bCBpbmZvcm1hdGlvbiBvZiB0aGUgbWFzdGVyIGFuZCBpdHMgc2xhdmVzLg0KDQpOZXcgc3RlcHMg Y291bGQgYmUgaW50cm9kdWNlZCBpbnRvIG9uZSBvciBtb3JlIHVzZSBjYXNlcyB0byBjb3ZlciB0 aGVzZSBPZmNvbSByZXF1aXJlbWVudHMsIGUuZy4gbmV3IHN0ZXBzIDZiaXMgYW5kIDliaXMgaW4g dGhlIGhvdHNwb3QgdXNlIGNhc2UgYXQgNC4yLjE6DQoNCjZiaXMuIFByaW9yIHRvIGluaXRpYXRp bmcgdHJhbnNtaXNzaW9uLCBpZiByZXF1aXJlZCBieSBsb2NhbCByZWd1bGF0aW9uLCB0aGUgbWFz dGVyL0FQIGluZm9ybXMgdGhlIGRhdGFiYXNlIG9mIHRoZSBjaGFubmVsIGFuZCBwb3dlciBsZXZl bCBpdCBoYXMgY2hvc2VuLiBUaGlzIGlzIHJlcGVhdGVkIGZvciBlYWNoIHNsYXZlIHRoYXQgYXNz b2NpYXRlZCB3aXRoIHRoZSBtYXN0ZXIuDQoNCjliaXMuIFByaW9yIHRvIGluaXRpYXRpbmcgdHJh bnNtaXNzaW9uLCBpZiByZXF1aXJlZCBieSBsb2NhbCByZWd1bGF0aW9uLCB0aGUgc2xhdmUgaW5m b3JtcyB0aGUgbWFzdGVyL0FQIG9mIHRoZSBjaGFubmVsIGFuZCBwb3dlciBsZXZlbCBpdCBoYXMg Y2hvc2VuLCBhbmQgdGhlbWFzdGVyL0FQIHJlbGF5cyB0aGlzIGluZm9ybWF0aW9uIHRvIHRoZSBk YXRhYmFzZS4NCg0KLSBlbmQgb2YgbmV3IHRleHQgLQ0KDQpGb3IgaW5mb3JtYXRpb24sIGZvciB0 aG9zZSBub3QgYWNjZXNzaW5nIHRoZSB1cmwgaW4gdGhlIGZpcnN0IHBhcmFncmFwaCBvZiB0aGlz IGVtYWlsLCB0aGUgZnVsbCBPZmNvbSByZXF1aXJlbWVudHMgbGVhZGluZyB0byB0aGlzIG5ldyBQ QVdTIHRleHQgYXJlIGFzIGZvbGxvd3M6DQoNCjMuMTggQWZ0ZXIgcmVjZWl2aW5nIGluc3RydWN0 aW9ucyBmcm9tIGEgV1NEQiBpbiByZWxhdGlvbiB0byB0aGUgbWF4aW11bSBwZXJtaXR0ZWQgRUlS UHMgb3ZlciB0aGUgRFRUIGNoYW5uZWxzLCBhbmQgcHJpb3IgdG8gaW5pdGlhdGluZyB0cmFuc21p c3Npb25zIHdpdGhpbiB0aGUgVUhGIFRWIGJhbmQsIGEgbWFzdGVyIFdTRCBtdXN0Y29tbXVuaWNh dGUgdG8gdGhlIFdTREIgdGhlIGZvbGxvd2luZyBpbmZvcm1hdGlvbjoNCjMuMTguMSBUaGUgbG93 ZXIgYW5kIHVwcGVyIGZyZXF1ZW5jeSBib3VuZGFyaWVzMTMgb2YgdGhlIGluLWJsb2NrIGVtaXNz aW9ucyBvZiB0aGUgbWFzdGVyIFdTRCwgYW5kIHRob3NlIG9mIHRoZSBpbi1ibG9jayBlbWlzc2lv bnMgb2YgaXRzIGFzc29jaWF0ZWQgc2xhdmVzLiBBIGxvd2VyIGZyZXF1ZW5jeSB3aWxsIGJlIHNw ZWNpZmllZCBhcyAoNDcwICsgOGsgKyAwLjJuKSBNSHosIHdpdGggdGhlIGNvcnJlc3BvbmRpbmcg dXBwZXIgZnJlcXVlbmN5IHNwZWNpZmllZCBhcyAoNDcwICsgOGsgKyAwLjJtKSBNSHosIHdoZXJl IDAgocIgayChwiAzOSwgMCChwiBuIKHCIDM5LCAxIKHCIG0gocIgNDAsIGFuZCBuIDwgbS4NCjMu MTguMiBUaGUgbWF4aW11bSBpbi1ibG9jayBFSVJQIHNwZWN0cmFsIGRlbnNpdGllcyAoaW4gZEJt LygwLjIgTUh6KSkgdGhhdCB0aGUgbWFzdGVyV1NELCBhbmQgaXRzIGFzc29jaWF0ZWQgc2xhdmVz LCBhY3R1YWxseSByYWRpYXRlIGJldHdlZW4gZWFjaCByZXBvcnRlZCBsb3dlciBmcmVxdWVuY3kg Ym91bmRhcnkgYW5kIGl0cyBjb3JyZXNwb25kaW5nIHVwcGVyIGZyZXF1ZW5jeSBib3VuZGFyeS4N Cg0KRm9vdG5vdGUgMTMgc3RhdGVzOg0KVGhlIHVzZSBvZiB1cHBlciBhbmQgbG93ZXIgZnJlcXVl bmN5IGJvdW5kYXJpZXMgKGRlZmluZWQgb3ZlciBhIDIwMCBrSHogcmFzdGVyKSBhbGxvd3MgYSBX U0RCIHRvIGNvbGxlY3QgbW9yZSBncmFudWxhciBpbmZvcm1hdGlvbiB3aXRoIHJlZ2FyZHMgdG8g dGhlIHVzYWdlIG9mIHRoZSBmcmVxdWVuY3kgcmVzb3VyY2UgYnluYXJyb3diYW5kIFdTRCB0ZWNo bm9sb2dpZXMuIFRoZSB1cHBlciBhbmQgbG93ZXIgZnJlcXVlbmNpZXMgb2YgYSBib3VuZGFyeSBw YWlyIGRvIG5vdHN0cmFkZGxlIGEgRFRUIGNoYW5uZWwgYm91bmRhcnkuIE5vdGUgdGhhdCBhIFdT RCBtYXkgdHJhbnNtaXQgb3ZlciBtdWx0aXBsZSwgbm9uLWNvbnRpZ3VvdXMsIHdob2xlIERUVCBj aGFubmVscyBvciBmcmFjdGlvbnMgb2YgRFRUIGNoYW5uZWxzLg0KDQozLjE5IEEgbWFzdGVyIFdT RCBtdXN0IGJlIGFibGUgdG8gcmVjZWl2ZSB0aGUgZm9sbG93aW5nIGluZm9ybWF0aW9uMTQgZnJv bSBhIFdTREI6DQo8c25pcD4NCjMuMTkuOCAgICAgW0FuIGFja25vd2xlZGdlbWVudCBmcm9tIHRo ZSBXU0RCLCBpbiB0aGUgY29udGV4dCBvZiAzLjE4LCB0aGF0IHRoZSByZXBvcnRlZCBpbmZvcm1h dGlvbiBvbiB0aGUgRFRUIGNoYW5uZWxzIGFuZCBFSVJQIHNwZWN0cmFsIGRlbnNpdGllcyBhY3R1 YWxseSB1c2VkIGJ5IHRoZSBtYXN0ZXIgYW5kIHNsYXZlIFdTRHMgd2VyZSByZWNlaXZlZCBzdWNj ZXNzZnVsbHkgYnkgdGhlIFdTREIxOF0uDQoNCkZvb3Rub3RlIDE0IHN0YXRlczoNCjE0IFdoaWxl IHRoZSBjb21tdW5pY2F0aW9uIG9mIHNvbWUgb2YgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIGEgV1NE QiB0byBhIG1hc3RlciBXU0QgaXMgb3B0aW9uYWwsIG1hc3RlciBXU0RzIG11c3QgYmUgYWJsZSB0 byByZWNlaXZlIGFuZCBpbnRlcnByZXQgdGhlc2UuDQoNCkZvb3Rub3RlIDE4IHN0YXRlczoNCjE4 IFRoaXMgZm9ybXMgcGFydCBvZiBhIGhhbmRzaGFrZSBwcm90b2NvbCBhbmQgbWF5IGJlIGFuIGFy ZWEgd2hlcmUgaW5kdXN0cnkgY291bGQgaGFybW9uaXNlIHdpdGhvdXQgdGhlIG5lZWQgZm9yIGFu IGV4cGxpY2l0IHJlcXVpcmVtZW50IGluIHRoZSByZWd1bGF0aW9ucy4NCg0KUmVnYXJkcw0KDQpB bmR5DQoNCkZyb206IHBhd3MtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cGF3cy1ib3VuY2VzQGll dGYub3JnPiBbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdhYm9y LkJhamtvQG5va2lhLmNvbTxtYWlsdG86R2Fib3IuQmFqa29Abm9raWEuY29tPg0KU2VudDogMDUg TWFyY2ggMjAxMiAxOTo0Ng0KVG86IHBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBbcGF3c10gV0dMQyBmb3IgZHJhZnQtaWV0Zi1wYXdzLXByb2JsZW0tc3RtdC11 c2VjYXNlcy1ycW10cy0wMw0KDQoNClRoZSBhdXRob3JzIG9mIHRoZSB1c2UgY2FzZXMgYW5kIHJl cXVpcmVtZW50cyBkcmFmdCBoYXZlIGp1c3QgcG9zdGVkIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRy YWZ0IGFuZCBpbmRpY2F0ZWQgdGhhdCB0aGVyZSBhcmUgbm8gdW5yZXNvbHZlZCBjb21tZW50cy9p c3N1ZXMgdGhleSBhcmUgYXdhcmUgb2YuDQoNCg0KDQpUaGVyZWZvcmUsIEknZCBsaWtlIHRvIGlu aXRpYXRlIGEgV0cgTGFzdCBDYWxsIGZvciBjb21tZW50cyBvbiBodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXBhd3MtcHJvYmxlbS1zdG10LXVzZWNhc2VzLXJx bXRzLTAzLnR4dA0KDQoNCg0KUGxlYXNlIHJldmlldyB0aGUgZHJhZnQgYW5kIHNlbmQgeW91cmNv bW1lbnRzIHRvIHRoZSBsaXN0IGJ5IE1hcmNoIDIwdGgsIDIwMTIuDQoNCg0KDQpJZiB5b3UgcmV2 aWV3IHRoZSBkcmFmdCBhbmQgaGF2ZSBubyBjb21tZW50cywgc2VuZCBhIG5vdGUgdG8gdGhlIGxp c3QgdGhhdCB0aGUgZHJhZnQgaXMgZ29vZCBhcyBpdCBpcywgd2UgbmVlZCB0aGVzZSBub3RlcyBh cyBtdWNoIGFzIHdlIG5lZWQgdGhlIGFjdHVhbCBjb21tZW50cy4NCg0KDQoNClRoYW5rcywgR2Fi b3INCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gcGF3 cyBtYWlsaW5nIGxpc3QgcGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo= --_000_CB7BA9DB1394Escottprobasconokiacom_ Content-Type: text/html; charset="ks_c_5601-1987" Content-ID: <8FB3BF4CCBDF1746A340BBC24E777A80@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable


I agree with you that some wireless standards will include signaling t= hat supports database access. But PAWS is not specific to any particular ra= dio technology, we cannot expect that all radio technologies will include s= ome components of the signaling for database access. PAWS should include all necessary messages for contac= t between the device and the database, without presumption of the underlyin= g radio technology.

Kind Regards,
Scott

From: ext Chouinard <gerald.chouinard@sympatico.ca>=
Date: Tue, 6 Mar 2012 12:44:09 -050= 0
To: Scott Probasco <scott.probasco@nokia.com>
Cc: "paws@ietf.org" <paws@i= etf.org>
Subject: RE: [paws] WGLC for draft-= ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting

Scott,

 

I am fine with your second sentence. &= nbsp;However, I have some difficulty with your third sentence since this wo= uld mean that the IETF-PAWS would get into defining the signaling details between the slave and the ma= ster devices. I believe this should be left to the wireless standard.  = ;Obviously, having this information available at the master would become a = requirement that the wireless standard would have to meet to be able to operate in white space. The way it would = be done would be internal to the wireless standard.  PAWS would take i= t from the master to the database.

 

Gerald

 

From: scott.probasco@Nokia.com [<= a href=3D"mailto:scott.probasco@Nokia.com">mailto:scott.probasco@Nokia.com<= /a>]
Sent: Tuesday, 06 March, 201= 2 12:32
To: gerald.chouinard@sympa= tico.ca
Cc: paws@ietf.org
Subject: Re: [paws] WGLC for= draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting

 

Hi Gerald,

 <= /p>

I believe Andy's proposal agrees= with your suggestion below. Looking at O.13bis, the slave MAY send the cha= nnel usage information and if it does so, it MUST include the following variables. I think P.12bis is appropriate si= nce the message MUST be defined by the protocol inorder to have the OPTION = of sending it. When these two requirements are considered jointly does this= provide the implementation flexibility you arethinking of?

 <= /p>

Kind Regards,<= /font>

Scott

 <= /p>

From: = ext Chouinard <gerald.c= houinard@sympatico.ca>
Date: Tue, 6 Mar 2012 12:13:= 05 -0500
To: Scott Probasco <scott.probasco@nokia.com>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] WGLC for= draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting

 <= /p>

Scott,

 

I am fine with your approach as long a= s the text says something as follows: =A1=B0the operating channel of the sl= ave needs to be provided to the database=A1=B1 rather than: =A1=B0the slave needs to provide the da= tabase with its operating channel=A1=B1.  This way, this information c= an be provided by either the slave or the master, not making it mandatory t= hat the =A1=B0slave=A1=B1 has to do it if the master knows the information.

 

The text proposed by Andy: =A1=B0The protocol MUST support a channel usage message from the slave device to the= master device.=A1=B1 Implies that the protocol to be developed needs to ap= ply on the connection between the slave and the master. Such connection sho= uld be implementation dependant.  What is required is that the information beavailable to the master for it to tr= ansmit it to the database, never mind the format that isused between the sl= ave and the master to carry this information.

 

Gerald

 

= From: scott.probasco@nokia.com [<= a href=3D"mailto:scott.probasco@nokia.com">mailto:scott.probasco@nokia.com<= /a>]
Sent: Tuesday, 06 March, 201= 2 12:00
To: gerald.chouinard@symp= atico.ca; andy.sago@bt.com
Cc: paws@ietf.org
Subject: Re: [paws] WGLC for= draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting

 

Hi Gerald,

 

At least according to the FCC, a= slave (Mode I) device may utilize channels that the master (fixed device) = cannot use, see =A1=D715.707 and 15.712. Thus there are potential situations where the master cannot be assumed to know what c= hannel the slave is using. Although this is a bit esoteric as the FCC is si= lent about what the slave might do on those channels, it is nonetheless inc= luded in the FCC regulations.

 

So I suggest we have no reason t= o overrule Ofcom requirements for channel usage information. Also Andy's ch= oice of words does ensure that this information is not required to be used in every operational scenario.

 

Kind Regards,

Scott= =

 

 

 

From: = ext Chouinard <gerald.c= houinard@sympatico.ca>
Date: Tue, 6 Mar 2012 11:44:= 07 -0500
To: ext com <andy.sago@bt.com>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] WGLC for= draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting

 

Andy,=

 

Looking at your suggestions below, it = seems that there is a need to define more precisely what a =A1=B0slave=A1= =B1 device is relative to its =A1=B0master=A1=B1.=

 

In my view, a slave can only use the s= ame transmission channel as that used by the master to which it is associat= ed (otherwise, master and slaves would not be able to talk to each other). As a consequence, the= slave does not have to indicate to the master the channel on which it is o= perating since the master knows it and can provided it to the database e.=

 

Similarly, modern bidirectional commun= ication systems between a master and a slave device assumes that there will= be a transmit power control (TPC) loop between the two devices to minimize the required transm= it power in various propagation environments. The driving device in this cl= osed-loop process will be the master and as a result, the EIRP transmitted = by the slave device will be known to the master as long as there is a known factor linking the power specifi= cation sent by the master to the slave and the actual EIRP transmitted by t= he slave.  Such factor which is a constant for each device can be prov= ided from the slave to the master once at association.  As a result, the slave does not need to inform the m= aster of its current (and provably continuously varying) EIRP since the mas= ter will havethis information from its TPC process and can provide it to th= e database onbehalf of the slave device.

 

Gerald

 

= From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of andy.sago@bt.com
Sent: Tuesday, 06 March, 201= 2 10:42
To: paws@ietf.org; Gabor.Bajko@nokia.com
Subject: Re: [paws] WGLC for= draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting<= /u1:p>

 =

= All

=  <= /u5:p>

= Comparing the= draft with the Ofcom requirements at ht= tp://www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-regulatory-r= equirements-for-white-space-devices-in-the-UHF-TV-band, I believe the WG draft is deficient in the area of reporting frequencies a= nd powers actually used by masters and slaves (Ofcom requirements 3.18 and = 3.19.8). Ofcom intends to collect this data to assesses the impact of aggre= gate interference into other services. It would also provide usage information (frequency in use) that would info= rm the operation of a kill switch capability. I suggest this deficiency can= be remedied with the following changes:

=  <= /u5:p>

= New P require= ments (probably best placed following P.12):

=  <= /u5:p>

P.12bis: The protocol MUST support a channel usage message= from the slave device to the master device.  The channel usage message MUST include parameters as required by local regulat= ory requirement.  These parameters MAY include device ID, manufacturer= 's serial number, channel usage and power level information.=

 

P.12ter: The protocol MUST support a channel usage message= from the master device to the database.  The channel usage message MUST include parameters as required by local regulatory requ= irement for the master and its associated slaves.  These parameters MA= Y include device ID, manufacturer's serial number, channel usage and power = level information.

 

P.12qua: The protocol MUST support a channel usage message= acknowledgement.

=  <= /u5:p>

= New O require= ments (probably best placed following O13):

=  <= /u5:p>

O.13bis:  According to local regulatory policy, after= connecting to a master device'sradio network a slave device MAY inform the master device of the actual channel usage. The slave= MUST include parameters required by local regulatory policy, e.g. device I= D, manufacturer's serial number, channel usage and power levelinformation.<= u5:p>

 

O.13ter:  According to local regulatory policy, a mas= ter device MAY inform the database of the actual channel usage of the master and its slaves. The master MUST include parameters req= uired by local regulatory policy, e.g. device ID, manufacturer's serial num= ber, channel usage and power level information of the master and its slaves= .

=  <= /u5:p>

= New steps cou= ld be introduced into one or more use cases to cover these Ofcom requiremen= ts, e.g. new steps 6bis and 9bis in the hotspot use case at 4.2.1:

=  <= /u5:p>

6bis. Prior to initiating transmission, if required by loc= al regulation, the master/AP informs the database of the channel and power level it has chosen. This is repeated for each sl= ave that associated with the master.

 

9bis. Prior to initiating transmission, if required by loc= al regulation, the slave informs the master/AP of the channel and power level it has chosen, and themaster/AP relays this= information to the database.

=  <= /u5:p>

= - end of new = text -

=  <= /u5:p>

= For informati= on, for those not accessing the url in the first paragraph of this email, t= he full Ofcom requirements leading to this new PAWS text are as follows:=

=  <= /u5:p>

= 3.18 After re= ceiving instructions from a WSDB in relation to the maximum permitted EIRPs= over the DTT channels, and prior to initiating transmissions within the UHF TV band, a master WSD mustcommunicate to the = WSDB the following information:

3.18.1 The lower and upper frequency boundaries13 of the in-block emissions of the master WSD, and those of the in-block emissions of its associated slaves. A lower freq= uency will be specified as (470 + 8k + 0.2n) MHz, with the correspo= nding upper frequency specified as (470 + 8k + 0.2m) MHz, where 0 = =A1=C2 k =A1=C2 39, 0 =A1=C2 n =A1=C2 39, 1 =A1=C2 m =A1=C2 40, and n < = m.

3.18.2 The maximum in-block EIRP spectral densities (in dB= m/(0.2 MHz)) that the masterWSD, and its associated slaves, actually radiate between each reported lower frequency boundary an= d its corresponding upper frequency boundary.

=  <= /u5:p>

= Footnote 13 s= tates:

= The use of up= per and lower frequency boundaries (defined over a 200 kHz raster) allows a= WSDB to collect more granular information with regards to the usage of the frequency resource bynarrowband WSD technologi= es. The upper and lower frequencies of a boundary pair do notstraddle a DTT= channel boundary. Note that a WSD may transmit over multiple, non-contiguo= us, whole DTT channels or fractions of DTT channels.

=  <= /u5:p>

= 3.19 A master= WSD must be able to receive the following information14 from a = WSDB:

= <snip><= u5:p>

3.19.8     [An acknowledgement from th= e WSDB, in the context of 3.18, that the reported information on the DTT channels and EIRP spectral densities actually used by the master and s= lave WSDs were received successfully by the WSDB18].

=  <= /u5:p>

= Footnote 14 s= tates:

= 14 While the = communication of some of this information from a WSDB to a master WSD is op= tional, master WSDs must be able to receive and interpret these.

=  <= /u5:p>

= Footnote 18 s= tates:

= 18 This forms= part of a handshake protocol and may be an area where industry could harmo= nise without the need for an explicit requirement in the regulations.

=  <= /u5:p>

= Regards=

=  <= /u5:p>

= Andy<= /u1:p>

=  <= /u5:p>

= From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com
Sent: 05 March 2012 19:46 To: paws@ietf.org
Subject: [paws] WGLC for dra= ft-ietf-paws-problem-stmt-usecases-rqmts-03

 

The authors of the use cases = and requirements draft have just posted a new version of the draft and indi= cated that there are no unresolved comments/issues they are aware of.

 

Therefore, I'd like to initia= te a WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-r= qmts-03.txt

 

Please review the draft and s= end yourcomments to the list by March 20th, 2012.=

 

If you review the draft and h= ave no comments, send a note to the list that the draft is good as it is, w= e need these notes as much as we need the actual comments.

 

Thanks, Gabor

 =

________________________________= _______________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws

--_000_CB7BA9DB1394Escottprobasconokiacom_-- From gerald.chouinard@sympatico.ca Tue Mar 6 10:18:32 2012 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 847DE21F88D6 for ; Tue, 6 Mar 2012 10:18:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.066 X-Spam-Level: X-Spam-Status: No, score=0.066 tagged_above=-999 required=5 tests=[AWL=1.034, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, MSGID_FROM_MTA_HEADER=0.803, 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 c-b8E4G6O1JL for ; Tue, 6 Mar 2012 10:18:30 -0800 (PST) Received: from blu0-omc3-s19.blu0.hotmail.com (blu0-omc3-s19.blu0.hotmail.com [65.55.116.94]) by ietfa.amsl.com (Postfix) with ESMTP id 1D42921F88B8 for ; Tue, 6 Mar 2012 10:18:30 -0800 (PST) Received: from BLU0-SMTP94 ([65.55.116.73]) by blu0-omc3-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Mar 2012 10:18:29 -0800 X-Originating-IP: [174.95.242.231] X-Originating-Email: [gerald.chouinard@sympatico.ca] Message-ID: Received: from Gerald2 ([174.95.242.231]) by BLU0-SMTP94.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Mar 2012 10:18:28 -0800 From: Gerald Chouinard To: References: Date: Tue, 6 Mar 2012 13:18:25 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FD_01CCFB9B.9E330C30" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AQHM+7qBJZkKE/OsEE6WAJSH4Dz7PpZdfy+A//+SKwCAAHc5wP//kfoAgAB2qjA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 06 Mar 2012 18:18:28.0472 (UTC) FILETIME=[8757F780:01CCFBC5] Cc: paws@ietf.org Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 18:18:32 -0000 ------=_NextPart_000_00FD_01CCFB9B.9E330C30 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Scott, =20 I believe that this could be kept simple by assuming that if a device = needs to directly communicate its information to the database, it can be considered for the purpose of PAWS as a =A1=B0master=A1=B1 device. If = this can be done through a proxy device in between, then the device needs to be = slaved to this device in between which will then be considered as the = =A1=B0master=A1=B1. In such case, the wireless standard used between these devices needs to = have all the necessary means to transmit the necessary information from the =A1=B0slave=A1=B1 to its =A1=B0master=A1=B1 to meet the requirements of = white space operation. The way it is done can vary from one technology to another. = This was, the scope of PAWS is limited to the link between the master and the database and not between the slave and the master. =20 Gerald =20 _____ =20 From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com]=20 Sent: Tuesday, 06 March, 2012 13:05 To: gerald.chouinard@sympatico.ca Cc: paws@ietf.org Subject: Re: [paws] WGLC for = draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting =20 Hi Gerald, =20 I agree with you that some wireless standards will include signaling = that supports database access. But PAWS is not specific to any particular = radio technology, we cannot expect that all radio technologies will include = some components of the signaling for database access. PAWS should include all necessary messages for contact between the device and the database, = without presumption of the underlying radio technology. =20 Kind Regards, Scott =20 From: ext Chouinard Date: Tue, 6 Mar 2012 12:44:09 -0500 To: Scott Probasco Cc: "paws@ietf.org" Subject: RE: [paws] WGLC for = draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting =20 Scott, =20 I am fine with your second sentence. However, I have some difficulty = with your third sentence since this would mean that the IETF-PAWS would get = into defining the signaling details between the slave and the master devices. = I believe this should be left to the wireless standard. Obviously, having this information available at the master would become a requirement that = the wireless standard would have to meet to be able to operate in white = space. The way it would be done would be internal to the wireless standard. = PAWS would take it from the master to the database. =20 Gerald =20 _____ =20 From: scott.probasco@Nokia.com [mailto:scott.probasco@Nokia.com]=20 Sent: Tuesday, 06 March, 2012 12:32 To: gerald.chouinard@sympatico.ca Cc: paws@ietf.org Subject: Re: [paws] WGLC for = draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting =20 Hi Gerald, =20 I believe Andy's proposal agrees with your suggestion below. Looking at O.13bis, the slave MAY send the channel usage information and if it does = so, it MUST include the following variables. I think P.12bis is appropriate since the message MUST be defined by the protocol inorder to have the = OPTION of sending it. When these two requirements are considered jointly does = this provide the implementation flexibility you arethinking of? =20 Kind Regards, Scott =20 From: ext Chouinard Date: Tue, 6 Mar 2012 12:13:05 -0500 To: Scott Probasco Cc: "paws@ietf.org" Subject: RE: [paws] WGLC for = draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting =20 Scott, =20 I am fine with your approach as long as the text says something as = follows: =A1=B0the operating channel of the slave needs to be provided to the = database=A1=B1 rather than: =A1=B0the slave needs to provide the database with its = operating channel=A1=B1. This way, this information can be provided by either the = slave or the master, not making it mandatory that the =A1=B0slave=A1=B1 has to = do it if the master knows the information. =20 The text proposed by Andy: =A1=B0The protocol MUST support a channel = usage message from the slave device to the master device.=A1=B1 Implies that = the protocol to be developed needs to apply on the connection between the = slave and the master. Such connection should be implementation dependant. = What is required is that the information beavailable to the master for it to transmit it to the database, never mind the format that isused between = the slave and the master to carry this information. =20 Gerald =20 _____ =20 From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com]=20 Sent: Tuesday, 06 March, 2012 12:00 To: gerald.chouinard@sympatico.ca; andy.sago@bt.com Cc: paws@ietf.org Subject: Re: [paws] WGLC for = draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting =20 Hi Gerald, =20 At least according to the FCC, a slave (Mode I) device may utilize = channels that the master (fixed device) cannot use, see =A1=EC15.707 and 15.712. = Thus there are potential situations where the master cannot be assumed to = know what channel the slave is using. Although this is a bit esoteric as the = FCC is silent about what the slave might do on those channels, it is = nonetheless included in the FCC regulations. =20 So I suggest we have no reason to overrule Ofcom requirements for = channel usage information. Also Andy's choice of words does ensure that this information is not required to be used in every operational scenario. =20 Kind Regards, Scott =20 =20 =20 From: ext Chouinard Date: Tue, 6 Mar 2012 11:44:07 -0500 To: ext com Cc: "paws@ietf.org" Subject: Re: [paws] WGLC for = draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting =20 Andy, =20 Looking at your suggestions below, it seems that there is a need to = define more precisely what a =A1=B0slave=A1=B1 device is relative to its = =A1=B0master=A1=B1. =20 In my view, a slave can only use the same transmission channel as that = used by the master to which it is associated (otherwise, master and slaves = would not be able to talk to each other). As a consequence, the slave does not have to indicate to the master the channel on which it is operating = since the master knows it and can provided it to the database e. =20 Similarly, modern bidirectional communication systems between a master = and a slave device assumes that there will be a transmit power control (TPC) = loop between the two devices to minimize the required transmit power in = various propagation environments. The driving device in this closed-loop process will be the master and as a result, the EIRP transmitted by the slave = device will be known to the master as long as there is a known factor linking = the power specification sent by the master to the slave and the actual EIRP transmitted by the slave. Such factor which is a constant for each = device can be provided from the slave to the master once at association. As a result, the slave does not need to inform the master of its current (and provably continuously varying) EIRP since the master will havethis information from its TPC process and can provide it to the database = onbehalf of the slave device. =20 Gerald =20 _____ =20 From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of andy.sago@bt.com Sent: Tuesday, 06 March, 2012 10:42 To: paws@ietf.org; Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for = draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting =20 All =20 Comparing the draft with the Ofcom requirements at http://www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-regulato= ry- requirements-for-white-space-devices-in-the-UHF-TV-band, I believe the = WG draft is deficient in the area of reporting frequencies and powers = actually used by masters and slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom intends to collect this data to assesses the impact of aggregate interference into other services. It would also provide usage = information (frequency in use) that would inform the operation of a kill switch capability. I suggest this deficiency can be remedied with the following changes: =20 New P requirements (probably best placed following P.12): =20 P.12bis: The protocol MUST support a channel usage message from the = slave device to the master device. The channel usage message MUST include parameters as required by local regulatory requirement. These = parameters MAY include device ID, manufacturer's serial number, channel usage and = power level information. =20 P.12ter: The protocol MUST support a channel usage message from the = master device to the database. The channel usage message MUST include = parameters as required by local regulatory requirement for the master and its associated slaves. These parameters MAY include device ID, = manufacturer's serial number, channel usage and power level information. =20 P.12qua: The protocol MUST support a channel usage message = acknowledgement. =20 New O requirements (probably best placed following O13): =20 O.13bis: According to local regulatory policy, after connecting to a = master device'sradio network a slave device MAY inform the master device of the actual channel usage. The slave MUST include parameters required by = local regulatory policy, e.g. device ID, manufacturer's serial number, channel usage and power levelinformation. =20 O.13ter: According to local regulatory policy, a master device MAY = inform the database of the actual channel usage of the master and its slaves. = The master MUST include parameters required by local regulatory policy, e.g. device ID, manufacturer's serial number, channel usage and power level information of the master and its slaves. =20 New steps could be introduced into one or more use cases to cover these Ofcom requirements, e.g. new steps 6bis and 9bis in the hotspot use case = at 4.2.1: =20 6bis. Prior to initiating transmission, if required by local regulation, = the master/AP informs the database of the channel and power level it has = chosen. This is repeated for each slave that associated with the master. =20 9bis. Prior to initiating transmission, if required by local regulation, = the slave informs the master/AP of the channel and power level it has = chosen, and themaster/AP relays this information to the database.=20 =20 - end of new text - =20 For information, for those not accessing the url in the first paragraph = of this email, the full Ofcom requirements leading to this new PAWS text = are as follows: =20 3.18 After receiving instructions from a WSDB in relation to the maximum permitted EIRPs over the DTT channels, and prior to initiating = transmissions within the UHF TV band, a master WSD mustcommunicate to the WSDB the following information: 3.18.1 The lower and upper frequency boundaries13 of the in-block = emissions of the master WSD, and those of the in-block emissions of its associated slaves. A lower frequency will be specified as (470 + 8k + 0.2n) MHz, = with the corresponding upper frequency specified as (470 + 8k + 0.2m) MHz, = where 0 =A1=DC k =A1=DC 39, 0 =A1=DC n =A1=DC 39, 1 =A1=DC m =A1=DC 40, and n = < m. 3.18.2 The maximum in-block EIRP spectral densities (in dBm/(0.2 MHz)) = that the masterWSD, and its associated slaves, actually radiate between each reported lower frequency boundary and its corresponding upper frequency boundary. =20 Footnote 13 states: The use of upper and lower frequency boundaries (defined over a 200 kHz raster) allows a WSDB to collect more granular information with regards = to the usage of the frequency resource bynarrowband WSD technologies. The = upper and lower frequencies of a boundary pair do notstraddle a DTT channel boundary. Note that a WSD may transmit over multiple, non-contiguous, = whole DTT channels or fractions of DTT channels. =20 3.19 A master WSD must be able to receive the following information14 = from a WSDB: 3.19.8 [An acknowledgement from the WSDB, in the context of 3.18, = that the reported information on the DTT channels and EIRP spectral densities actually used by the master and slave WSDs were received successfully by = the WSDB18]. =20 Footnote 14 states: 14 While the communication of some of this information from a WSDB to a master WSD is optional, master WSDs must be able to receive and = interpret these. =20 Footnote 18 states: 18 This forms part of a handshake protocol and may be an area where = industry could harmonise without the need for an explicit requirement in the regulations. =20 Regards =20 Andy =20 From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com Sent: 05 March 2012 19:46 To: paws@ietf.org Subject: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03 =20 The authors of the use cases and requirements draft have just posted a = new version of the draft and indicated that there are no unresolved comments/issues they are aware of. =20 Therefore, I'd like to initiate a WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases= -rq mts-03.txt =20 Please review the draft and send yourcomments to the list by March 20th, 2012. =20 If you review the draft and have no comments, send a note to the list = that the draft is good as it is, we need these notes as much as we need the actual comments. =20 Thanks, Gabor =20 _______________________________________________ paws mailing list = paws@ietf. org https://www.ietf.org/mailman/listinfo/paws ------=_NextPart_000_00FD_01CCFB9B.9E330C30 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Scott,

 

I believe that this could be kept = simple by assuming that if a device needs to directly communicate its = information to the database, it can be considered for the purpose of PAWS as a = =A1=B0master=A1=B1 device. If this can be done through a proxy device in between, then the = device needs to be slaved to this device in between which will then be = considered as the =A1=B0master=A1=B1. In such case, the wireless standard used between = these devices needs to have all the necessary means to transmit the necessary information = from the =A1=B0slave=A1=B1 to its =A1=B0master=A1=B1 to meet the requirements of white space = operation.  The way it is done can vary from one technology to another. This was, the = scope of PAWS is limited to the link between the master and the database and not = between the slave and the master.

 

Gerald

 

From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com]
Sent: Tuesday, 06 March, = 2012 13:05
To: gerald.chouinard@sympatico.ca
Cc: paws@ietf.org
Subject: Re: [paws] WGLC = for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel = reporting

 

Hi = Gerald,

 

I agree with you that some = wireless standards will include signaling that supports database access. But PAWS = is not specific to any particular radio technology, we cannot expect that all = radio technologies will include some components of the signaling for database = access. PAWS should include all necessary messages for contact between the = device and the database, without presumption of the underlying radio = technology.

 

Kind = Regards,

Scott

=

 

From: ext Chouinard <gerald.chouinard@sympatico.= ca>
Date: Tue, 6 Mar 2012 = 12:44:09 -0500
To: Scott Probasco <scott.probasco@nokia.com>=
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] WGLC = for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel = reporting

 

Scott,

 

I am fine with your second = sentence.  However, I have some difficulty with your third sentence since = this would mean that the IETF-PAWS would get into defining the signaling details = between the slave and the master devices. I believe this should be left to the = wireless standard.  Obviously, having this information available at the = master would become a requirement that the wireless standard would have to meet = to be able to operate in white space. The way it would be done would be = internal to the wireless standard.  PAWS would take it from the master to the = database.

 

Gerald

 

From: scott.probasco@Nokia.com [mailto:scott.probasco@Nokia.com<= /a>]
Sent: Tuesday, 06 March, = 2012 12:32
To: gerald.chouinard@sympatico.= ca
Cc: paws@ietf.org
Subject: Re: [paws] WGLC = for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel = reporting

 

Hi = Gerald,

 <= font color=3Dblack>

I believe Andy's proposal agrees = with your suggestion below. Looking at O.13bis, the slave MAY send the channel = usage information and if it does so, it MUST include the following variables. = I think P.12bis is appropriate since the message MUST be defined by the protocol inorder to have the OPTION of sending it. When these two requirements = are considered jointly does this provide the implementation flexibility you arethinking of?

 <= font color=3Dblack>

Kind = Regards,

Scott

 <= font color=3Dblack>

From: ext Chouinard <gerald.chouinard@sympatico.= ca>
Date: Tue, 6 Mar 2012 = 12:13:05 -0500
To: Scott Probasco <scott.probasco@nokia.com>=
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] WGLC = for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel = reporting

 <= font color=3Dblack>

Scott,

 

I am fine with your approach as = long as the text says something as follows: =A1=B0the operating channel of the = slave needs to be provided to the database=A1=B1 rather than: =A1=B0the slave needs = to provide the database with its operating channel=A1=B1.  This way, this = information can be provided by either the slave or the master, not making it mandatory that = the =A1=B0slave=A1=B1 has to do it if the master knows the = information.

 

The text proposed by Andy: = =A1=B0The protocol MUST support a channel usage message from the slave device to = the master device.=A1=B1 Implies that the protocol to be developed needs to = apply on the connection between the slave and the master. Such connection should be implementation dependant.  What is required is that the information beavailable to the master for it to transmit it to the database, never = mind the format that isused between the slave and the master to carry this = information.=

 

Gerald

 

From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com<= /a>]
Sent: Tuesday, 06 March, = 2012 12:00
To: gerald.chouinard@sympatico.= ca; andy.sago@bt.com
Cc: paws@ietf.org
Subject: Re: [paws] WGLC = for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel = reporting=

 

Hi = Gerald,

 <= font color=3Dblack>

At least according to the FCC, a = slave (Mode I) device may utilize channels that the master (fixed device) = cannot use, see =A1=EC15.707 and 15.712. Thus there are potential situations where = the master cannot be assumed to know what channel the slave is using. Although this = is a bit esoteric as the FCC is silent about what the slave might do on those channels, it is nonetheless included in the FCC = regulations.

 <= font color=3Dblack>

So I suggest we have no reason to = overrule Ofcom requirements for channel usage information. Also Andy's choice of = words does ensure that this information is not required to be used in every operational scenario.

 <= font color=3Dblack>

Kind = Regards,

Scott

 <= font color=3Dblack>

 <= font color=3Dblack>

 <= font color=3Dblack>

From: ext Chouinard <gerald.chouinard@sympatico.= ca>
Date: Tue, 6 Mar 2012 = 11:44:07 -0500
To: ext com <andy.sago@bt.com>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] WGLC = for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel = reporting

 <= font color=3Dblack>

Andy,=

 =

Looking at your suggestions below, = it seems that there is a need to define more precisely what a = =A1=B0slave=A1=B1 device is relative to its =A1=B0master=A1=B1.=

 =

In my view, a slave can only use = the same transmission channel as that used by the master to which it is = associated (otherwise, master and slaves would not be able to talk to each other). = As a consequence, the slave does not have to indicate to the master the = channel on which it is operating since the master knows it and can provided it to = the database e.

 =

Similarly, modern bidirectional communication systems between a master and a slave device assumes that = there will be a transmit power control (TPC) loop between the two devices to = minimize the required transmit power in various propagation environments. The = driving device in this closed-loop process will be the master and as a result, = the EIRP transmitted by the slave device will be known to the master as long as = there is a known factor linking the power specification sent by the master to the = slave and the actual EIRP transmitted by the slave.  Such factor which is = a constant for each device can be provided from the slave to the master = once at association.  As a result, the slave does not need to inform the = master of its current (and provably continuously varying) EIRP since the master = will havethis information from its TPC process and can provide it to the = database onbehalf of the slave device.=

 =

Gerald=

 =

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] = On Behalf Of andy.sago@bt.com
Sent: Tuesday, 06 March, = 2012 10:42
To: paws@ietf.org; Gabor.Bajko@nokia.com
Subject: Re: [paws] WGLC = for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel = reporting<= /span>

 

All=

 =

Comparing the draft with the = Ofcom requirements at http:= //www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-regulatory-re= quirements-for-white-space-devices-in-the-UHF-TV-band, I believe the WG draft is deficient in the area of reporting frequencies = and powers actually used by masters and slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom intends to collect this data to assesses the impact of = aggregate interference into other services. It would also provide usage = information (frequency in use) that would inform the operation of a kill switch = capability. I suggest this deficiency can be remedied with the following = changes:=

 =

New P requirements (probably = best placed following P.12):=

 =

P.12bis: The protocol MUST support a channel usage message from the slave device = to the master device.  The channel usage message MUST include parameters = as required by local regulatory requirement.  These parameters MAY = include device ID, manufacturer's serial number, channel usage and power level information.=

 =

P.12ter: The protocol MUST support a channel usage message from the master device = to the database.  The channel usage message MUST include parameters as = required by local regulatory requirement for the master and its associated = slaves.  These parameters MAY include device ID, manufacturer's serial number, = channel usage and power level information.=

 =

P.12qua: The protocol MUST support a channel usage message = acknowledgement.=

 =

New O requirements (probably = best placed following O13):=

 =

O.13bis:  According to local regulatory policy, after connecting to a master device'sradio network a slave device MAY inform the master device of the = actual channel usage. The slave MUST include parameters required by local = regulatory policy, e.g. device ID, manufacturer's serial number, channel usage and = power levelinformation.=

 =

O.13ter:  According to local regulatory policy, a master device MAY inform the = database of the actual channel usage of the master and its slaves. The master = MUST include parameters required by local regulatory policy, e.g. device ID, manufacturer's serial number, channel usage and power level information = of the master and its slaves.=

 =

New steps could be introduced = into one or more use cases to cover these Ofcom requirements, e.g. new steps 6bis = and 9bis in the hotspot use case at 4.2.1:=

 =

6bis. Prior to initiating transmission, if required by local regulation, the master/AP informs the database of the channel and power level it has = chosen. This is repeated for each slave that associated with the = master.=

 =

9bis. Prior to initiating transmission, if required by local regulation, the = slave informs the master/AP of the channel and power level it has chosen, and themaster/AP relays this information to the database. = =

 =

- end of new text = -=

 =

For information, for those not = accessing the url in the first paragraph of this email, the full Ofcom = requirements leading to this new PAWS text are as = follows:=

 =

3.18 After receiving = instructions from a WSDB in relation to the maximum permitted EIRPs over the DTT channels, = and prior to initiating transmissions within the UHF TV band, a master WSD mustcommunicate to the WSDB the following = information:=

3.18.1 The lower and upper frequency boundaries13 of the in-block = emissions of the master WSD, and those of the in-block emissions of its associated = slaves. A lower frequency will be specified as (470 + 8k + 0.2n) MHz, with the corresponding upper frequency specified as (470 + 8k + 0.2m) MHz, where = 0 =A1=DC k =A1=DC 39, 0 =A1=DC n =A1=DC 39, 1 =A1=DC m =A1=DC 40, and n < = m.=

3.18.2 The maximum in-block EIRP spectral densities (in dBm/(0.2 MHz)) that the = masterWSD, and its associated slaves, actually radiate between each reported lower frequency boundary and its corresponding upper frequency = boundary.=

 =

Footnote 13 = states:=

The use of upper and lower = frequency boundaries (defined over a 200 kHz raster) allows a WSDB to collect more granular information with regards to the usage of the frequency resource bynarrowband WSD technologies. The upper and lower frequencies of a = boundary pair do notstraddle a DTT channel boundary. Note that a WSD may transmit = over multiple, non-contiguous, whole DTT channels or fractions of DTT = channels.=

 =

3.19 A master WSD must be able = to receive the following information14 from a = WSDB:=

<snip>= =

3.19.8     [An acknowledgement from the WSDB, in the context of 3.18, that the = reported information on the DTT channels and EIRP spectral densities actually = used by the master and slave WSDs were received successfully by the = WSDB18].=

 =

Footnote 14 = states:=

14 While the communication of = some of this information from a WSDB to a master WSD is optional, master WSDs = must be able to receive and interpret these.=

 =

Footnote 18 = states:=

18 This forms part of a = handshake protocol and may be an area where industry could harmonise without the = need for an explicit requirement in the = regulations.=

 =

Regards=

 =

Andy<= font color=3Dblack>=

 =

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] = On Behalf Of Gabor.Bajko@nokia.com
Sent: 05 March 2012 = 19:46
To: paws@ietf.org
Subject: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03= =

 

The authors of the use cases and requirements draft have just posted a new version of the draft and = indicated that there are no unresolved comments/issues they are aware = of.

 

Therefore, I'd like to initiate a = WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paw= s-problem-stmt-usecases-rqmts-03.txt<= /u1:p>

 

Please review the draft and send yourcomments to the list by March 20th, = 2012.

=

 

If you review the draft and have = no comments, send a note to the list that the draft is good as it is, we = need these notes as much as we need the actual = comments.=

 

Thanks, = Gabor

=

 

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

------=_NextPart_000_00FD_01CCFB9B.9E330C30-- From d.joslyn@spectrumbridge.com Tue Mar 6 11:12:54 2012 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 4263621E807B for ; Tue, 6 Mar 2012 11:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.834 X-Spam-Level: X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5 tests=[AWL=0.764, 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 dk-K5GyPb7ep for ; Tue, 6 Mar 2012 11:12:53 -0800 (PST) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id C511921E8045 for ; Tue, 6 Mar 2012 11:12:52 -0800 (PST) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Tue, 6 Mar 2012 14:13:50 -0500 From: Don Joslyn To: "paws@ietf.org" Importance: high X-Priority: 1 Date: Tue, 6 Mar 2012 14:13:37 -0500 Thread-Topic: Spectrum Bridge WS Protocol submitted to PAWS WG for consideration Thread-Index: Acz7sSDZZHyQ4kjASHKdZUQDrq9c/AAG+vNQ Message-ID: <8375F6DAEFB09F48815203F1FE23B797113CB4E6EA@shelby> 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_8375F6DAEFB09F48815203F1FE23B797113CB4E6EAshelby_" MIME-Version: 1.0 Subject: [paws] Spectrum Bridge WS Protocol submitted to PAWS WG for consideration X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 19:12:54 -0000 --_000_8375F6DAEFB09F48815203F1FE23B797113CB4E6EAshelby_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Spectrum Bridge has respectfully submitted an Internet Draft for considerat= ion by the PAWS working group entitled "Protocol for Communication between = White Space Device and White Space Database". The submitted I-D describes t= he current protocol used by Spectrum Bridge's FCC certified database. The I-D is located here: https://datatracker.ietf.org/doc/draft-sbi-paws-pr= otocol/ Abstract: This document defines an application protocol for WSDB services provided to TV Band Devices (TVBDs). The protocol complies with FCC Rules/Requirements [FCC 10-174] and in the context of operating an FCC certified database, it also complies with requirements defined by IETF PAWS [IETF-PAWS-03]. We believe this protocol can be easily extended to include the remaining requirements not already satisfied from the IETF PAWS requirements. Regards, Don Joslyn Spectrum Bridge, Inc. --_000_8375F6DAEFB09F48815203F1FE23B797113CB4E6EAshelby_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Spectrum Bridge = has respectfully submitted an Internet Draft for consideration by the PAWS = working group entitled “Protocol for Communication between White Spac= e Device and White Space Database”. The submitted I-D describes the c= urrent protocol used by Spectrum Bridge’s FCC certified database.

 

T= he I-D is located here: https://datatracker.ietf.org/doc/draft-sbi-paws-protocol= /

 

Abstract:

 

<= p class=3DMsoNormal style=3D'line-height:14.4pt;background:white'>This document= defines an application protocol for WSDB services

provided to TV = Band Devices (TVBDs). The protocol complies with FCC

<= p class=3DMsoNormal style=3D'line-height:14.4pt;background:white'>Rules/Require= ments [FCC 10-174] and in the context of operating an

=

FCC certifie= d database, it also complies with requirements defined by=

IETF PAW= S [IETF-PAWS-03]. We believe this protocol can be easily<= /p>

extended = to include the remaining requirements not already satisfied

from t= he IETF PAWS requirements.

&= nbsp;

 

Regards,

 

Don Joslyn

Spectrum Bridge= , Inc.

= --_000_8375F6DAEFB09F48815203F1FE23B797113CB4E6EAshelby_-- From JuanCarlos.Zuniga@InterDigital.com Tue Mar 6 15:18:02 2012 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 9ED9521E805D for ; Tue, 6 Mar 2012 15:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 wy3fpUXk0eRx for ; Tue, 6 Mar 2012 15:18:00 -0800 (PST) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id D142021E800F for ; Tue, 6 Mar 2012 15:17:59 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Mar 2012 18:17:58 -0500 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_01CCFBEF.5E9A2167" Date: Tue, 6 Mar 2012 18:17:57 -0500 Message-ID: In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601E1A52E@008-AM1MPN1-006.mgdnok.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: protocol details Thread-Index: Acz7CHkh/FNx3kOiQQWaHcNbcyzaWwAsH3rw References: <1ECAFF543A2FED4EA2BEB6CACE08E47601E1A52E@008-AM1MPN1-006.mgdnok.nokia.com> From: "Zuniga, Juan Carlos" To: , X-OriginalArrivalTime: 06 Mar 2012 23:17:58.0776 (UTC) FILETIME=[5E7ABF80:01CCFBEF] Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: protocol details X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 23:18:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFBEF.5E9A2167 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 I have taken a look at the Ofcom requirements reference on the CEPT site and besides the points raised by Andy I believe the following protocol requirements should also be addressed in the PAWS requirements doc: =20 - Ofcom 3.11 A master WSD must communicate its technology identifier to a WSDB - This is needed to identify the type of RAT being used, beyond the antenna, power and channel characteristics. Having said that, we had some issues in IEEE 802.21 where we were playing a horse race with the constantly evolving 802.11, 3GPP, etc PHY technologies, so perhaps another approach could be to specify directly the modulation, medium access method, etc. instead of the actual RAT ID. We don't need to define the actual solution now, as long as the requirement allows it in the future. Suggested text: o D.5: The Data Model MUST support specifying an ID of the transmitter device. This ID would contain the ID of the transmitter device that has been certified by a regulatory body for its regulatory domain. The Data Model MUST support a device class. The Data Model MUST support specifying information about the type of RAT of the transmitter device. =20 - Ofcom 3.15 A master WSD must communicate to a WSDB whether it, and its associated slave WSDs, are fixed devices or portable/mobile devices - Not sure if this is covered by "device class" in D.5. Since Device Class is not defined in the document, I would suggest either defining it as including fixed vs. mobile/portable characteristics, or adding a sentence at the end of D.5 such as "The Data Model MUST support specifying whether the transmitter device is fixed or mobile/portable." =20 - Ofcom 3.16 A fixed master WSD may communicate to a WSDB whether it, and its associated fixed slave WSDs, are indoor devices or outdoor devices - Similar to the previous 3.15 requirement. I would suggest either adding a definition for Device Class including indoor or outdoor characteristics, or adding a sentence in D.5 like "The Data Model MAY support specifying whether the transmitter is an outdoor or indoor device." =20 Also, I believe we need to add some clarification on the following: =20 - P.14/P.15 state that the protocol must support a "validation request from the master to the database to validate a slave device". Is this a master relaying a request to the WSDB on behalf of a slave? It is not clear what validation means. It would be good to provide some more explanatory text. =20 - Now that the CEPT version of the Ofcom requirements is publicly available we should add a reference to the document in Section 3.3 "Background information on white space in the UK." =20 Regards, =20 Juan Carlos=20 =20 From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com Sent: Monday, March 05, 2012 2:46 PM To: paws@ietf.org Subject: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03 =20 The authors of the use cases and requirements draft have just posted a new version of the draft and indicated that there are no unresolved comments/issues they are aware of. =20 Therefore, I'd like to initiate a WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecase s-rqmts-03.txt=20 =20 Please review the draft and send your comments to the list by March 20th, 2012. =20 If you review the draft and have no comments, send a note to the list that the draft is good as it is, we need these notes as much as we need the actual comments. =20 Thanks, Gabor =20 ------_=_NextPart_001_01CCFBEF.5E9A2167 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I have taken a look at = the Ofcom requirements reference on the CEPT site and besides the points = raised by Andy I believe the following protocol requirements should also = be addressed in the PAWS requirements doc:

 

-          = Ofcom 3.11 = A master WSD must communicate its technology identifier to a WSDB = – This is needed to identify the type of RAT being used, beyond = the antenna, power and channel characteristics. Having said that, we had = some issues in IEEE 802.21 where we were playing a horse race with the = constantly evolving 802.11, 3GPP, etc PHY technologies, so perhaps = another approach could be to specify directly the modulation, medium = access method, etc. instead of the actual RAT ID. We don’t need to = define the actual solution now, as long as the requirement allows it in = the future. Suggested text:

o   = D.5:   The Data Model MUST support = specifying an ID of the transmitter device.  This ID would contain = the ID of the transmitter device that has been certified by a regulatory = body for its regulatory domain.  The Data Model MUST support a = device class. <Insert> The Data Model MUST support specifying = information about the type of RAT of the transmitter = device.</Insert>

 

-          = Ofcom = 3.15    A master WSD must communicate to a WSDB whether = it, and its associated slave WSDs, are fixed devices or portable/mobile = devices – Not sure if this is covered by “device = class” in D.5. Since Device Class is not defined in the document, = I would suggest either defining it as including fixed vs. = mobile/portable characteristics, or adding a sentence at the end of D.5 = such as “The Data Model MUST support specifying whether the = transmitter device is fixed or = mobile/portable.”

 

-          = Ofcom = 3.16    A fixed master WSD may communicate to a WSDB = whether it, and its associated fixed slave WSDs, are indoor devices or = outdoor devices – Similar to the previous 3.15 requirement. I = would suggest either adding a definition for Device Class including = indoor or outdoor characteristics, or adding a sentence in D.5 like = “The Data Model MAY support specifying whether the transmitter is = an outdoor or indoor device.”

 

Also, I believe we need = to add some clarification on the following:

 

-          = P.14/P.15 = state that the protocol must support a “validation request from = the master to the database to validate a slave device”. Is this a = master relaying a request to the WSDB on behalf of a slave? It is not = clear what validation means. It would be good to provide some more = explanatory text.

 

-          = Now that = the CEPT version of the Ofcom requirements is publicly available we = should add a reference to the document in Section 3.3 “Background = information on white space in the UK.”

 

Regards,

 

Juan Carlos =

 

From:= = paws-bounces@ietf.org [mailto:paws-bounces@ietf.= org] On Behalf Of Gabor.Bajko@nokia.com
Sen= t: Monday, March 05, 2012 2:46 PM
To: paws@ietf.org
Subject: = [paws] WGLC for = draft-ietf-paws-problem-stmt-usecases-rqmts-03

 

The authors of the use cases and requirements draft = have just posted a new version of the draft and indicated that there are = no unresolved comments/issues they are aware of.

 

Therefore, I'd like to = initiate a WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paw= s-problem-stmt-usecases-rqmts-03.txt

 

Please review the draft = and send your comments to the list by March 20th, = 2012.

 

If you review the draft = and have no comments, send a note to the list that the draft is good as = it is, we need these notes as much as we need the actual = comments.

 

Thanks, = Gabor

 

------_=_NextPart_001_01CCFBEF.5E9A2167-- From brian.rosen@neustar.biz Wed Mar 7 08:41:08 2012 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 5D40321F86C7 for ; Wed, 7 Mar 2012 08:41:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.658 X-Spam-Level: X-Spam-Status: No, score=-4.658 tagged_above=-999 required=5 tests=[AWL=-1.239, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4, 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 TjOqyfZt7+xM for ; Wed, 7 Mar 2012 08:41:06 -0800 (PST) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id E1F6321F84BD for ; Wed, 7 Mar 2012 08:41:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1331138501; x=1646491346; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=i+8u/tCq2tkGHuHb1s5VJ DPFH7KW8nE8QyUTYPoC6lA=; b=TfYFdIAcOcl429ToZ/N/80uhYU6TuGstaIu+i ghIeEMhKTc4c88xnz6wJUTWdvjlKYzgxgkpNkQ53/kRS3wQ3w== Received: from ([10.31.13.228]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.6059729; Wed, 07 Mar 2012 11:41:40 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Wed, 7 Mar 2012 11:41:00 -0500 From: "Rosen, Brian" To: " " Date: Wed, 7 Mar 2012 11:40:59 -0500 Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting Thread-Index: Acz8gRPEdzn8obR2RIazbIAYmfOTcg== Message-ID: References: <4F5643A8.7000706@joelhalpern.com> <619CDADDCCD2B44380834BE8BF6F71414069146126@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: <619CDADDCCD2B44380834BE8BF6F71414069146126@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: 6Y16fj8OKZxVpwf6bFrvHw== Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" , "johnny.dixon@bt.com" , "chris.cheeseman@bt.com" Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 16:41:08 -0000 I'd also suggest that our charter limitation is really support for sharing = of whitespace by whitespace devices. Reporting what you use is not sharing= , it's just data gathering. The point of excluding sharing was to eliminate the complexities of what co= nstituted fairness, and what kinds of communication might be needed between= databases, where more than one could supply available whitespace in a band= . This doesn't have any of those issues, As long as it's just sending information, I don't have a problem. Once the= database is supposed to do anything with it that involves changing what sp= ectrum it reports, then I think we cross the line. Brian On Mar 6, 2012, at 12:28 PM, wrote: > Joel >=20 > Indeed, the regulator has not described the process or provided a flow di= agram, so there may be some wrinkles, but we need to provide for their inte= nt. To answer your question, the channels that the master will use are sent= in a separate message (described in P.12 ter), that occurs after the maste= r receives the response to its channel request, but before the master can t= ransmit. At this point, it knows what channels are available, and which one= it will use. As far as the slaves are concerned, as they associate, the ma= ster will need to gather their details and send further channel usage messa= ges to the database on their behalf. >=20 > Regards >=20 > Andy >=20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of J= oel M. Halpern > Sent: 06 March 2012 17:05 > To: scott.probasco@nokia.com > Cc: paws@ietf.org; Cheeseman,CJ,Chris,COD R; Dixon,JS,Johnny,COD R > Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-= 03: channel reporting >=20 > Ahh. I think I see where the request and my understanding divurge. > If the idea here is that the master must provide, in the request, an indi= cation of what channels it expects to use, I can at least understand that. = I will return to technical concerns in a moment. >=20 > However, when you say "provide channel usage information, in order to eva= luate interference", what that says to me is providing, during operation, i= nformation as to what channels are being used, and at what power levels. T= hat is what would be needed to analyze actual interference effects. > And that is out of scope as I understand our scope. >=20 > I do see a technical difficulty with having the master provide, as part o= f either registering or requesting spectrum information, what channels it i= ntends to use. It doesn;t know what channels it intends to use. It intend= s to use some number of available channels. It will figure out which ones = when it is told what is available. How can it send that information in the= request? >=20 > Yours, > Joel >=20 > On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: >> Hi, >>=20 >> There is a similarity here with device ID. In context of PAWS we are >> not concerned with why a device ID is required by a regulator, we >> accept it is a requirement from a regulator and include it to the >> protocol. Ofcom identifies in 3.18& 3.19 that channel usage >> information is required and thus we need to include this information. >> Since the master must provide this information prior to transmitting, >> PAWS will not function in the UK without this information and thus I >> believe channel usage information is integral to the channel request& r= esponse messaging. >>=20 >> Kind Regards, >> Scott >>=20 >>=20 >> On 3/6/12 10:30 AM, "ext Joel M. Halpern" wrote: >>=20 >>> I would draw a distinction. Ofcom regulations about whitespace >>> requests are very much relevant. >>> Ofcom regulations about notification of dynamic behavior (which >>> spectrum is being used) are not in scope as I understand the earlier >>> discussions, particularly the chartering discussions. >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: >>>>=20 >>>> The ofcom requirements are very much relevant to the scope of the >>>> PAWS WG. >>>> The only other regulatory requirements that we have today is the FCC. >>>> Ofcom requirements are a good addition to the set. >>>>=20 >>>> -Raj >>>>=20 >>>> On 3/6/12 10:03 AM, "ext andy.sago@bt.com" wrote: >>>>=20 >>>>> Hi Joel >>>>>=20 >>>>> There's no language I can find in the charter that explicitly puts >>>>> this out of scope. On the other hand, the charter says that the >>>>> group will "consider input from regulatory entities", and this is >>>>> one of the requirements from Ofcom that they have just published. >>>>> The protocol will be worthless for the UK if it omits some >>>>> requirements. >>>>>=20 >>>>> Regards >>>>>=20 >>>>> Andy >>>>>=20 >>>>> -----Original Message----- >>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>>> Sent: 06 March 2012 15:53 >>>>> To: Sago,AJ,Andy,COD R >>>>> Cc: paws@ietf.org; Gabor.Bajko@nokia.com >>>>> Subject: Re: [paws] WGLC for >>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting >>>>>=20 >>>>> As I understand, the information you are asking for is explicitly >>>>> out of scope for the working group. >>>>> Yours, >>>>> Joel >>>>>=20 >>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >>>>>> All >>>>>>=20 >>>>>> Comparing the draft with the Ofcom requirements at >>>>>> http://www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-r >>>>>> egul >>>>>> atory-requirements-for-white-space-devices-in-the-UHF-TV-band, >>>>>> I believe the WG draft is deficient in the area of reporting >>>>>> frequencies and powers actually used by masters and slaves (Ofcom >>>>>> requirements 3.18 and 3.19.8). Ofcom intends to collect this data >>>>>> to assesses the impact of aggregate interference into other >>>>>> services. It would also provide usage information (frequency in >>>>>> use) that would inform the operation of a kill switch capability. >>>>>> I suggest this deficiency can be remedied with the following changes= : >>>>>>=20 >>>>>> New P requirements (probably best placed following P.12): >>>>>>=20 >>>>>> P.12bis: The protocol MUST support a channel usage message from >>>>>> the slave device to the master device. The channel usage message >>>>>> MUST include parameters as required by local regulatory >>>>>> requirement. These parameters MAY include device ID, >>>>>> manufacturer's serial number, channel usage and power level informat= ion. >>>>>>=20 >>>>>> P.12ter: The protocol MUST support a channel usage message from >>>>>> the master device to the database. The channel usage message MUST >>>>>> include parameters as required by local regulatory requirement for >>>>>> the master and its associated slaves. These parameters MAY >>>>>> include device ID, manufacturer's serial number, channel usage and >>>>>> power level information. >>>>>>=20 >>>>>> P.12qua: The protocol MUST support a channel usage message >>>>>> acknowledgement. >>>>>>=20 >>>>>> New O requirements (probably best placed following O13): >>>>>>=20 >>>>>> O.13bis: According to local regulatory policy, after connecting >>>>>> to a master device's radio network a slave device MAY inform the >>>>>> master device of the actual channel usage. The slave MUST include >>>>>> parameters required by local regulatory policy, e.g. device ID, >>>>>> manufacturer's serial number, channel usage and power level informat= ion. >>>>>>=20 >>>>>> O.13ter: According to local regulatory policy, a master device >>>>>> MAY inform the database of the actual channel usage of the master >>>>>> and its slaves. The master MUST include parameters required by >>>>>> local regulatory policy, e.g. device ID, manufacturer's serial >>>>>> number, channel usage and power level information of the master >>>>>> and its slaves. >>>>>>=20 >>>>>> New steps could be introduced into one or more use cases to cover >>>>>> these Ofcom requirements, e.g. new steps 6bis and 9bis in the >>>>>> hotspot use case at 4.2.1: >>>>>>=20 >>>>>> 6bis. Prior to initiating transmission, if required by local >>>>>> regulation, the master/AP informs the database of the channel and >>>>>> power level it has chosen. This is repeated for each slave that >>>>>> associated with the master. >>>>>>=20 >>>>>> 9bis. Prior to initiating transmission, if required by local >>>>>> regulation, the slave informs the master/AP of the channel and >>>>>> power level it has chosen, and the master/AP relays this >>>>>> information to the database. >>>>>>=20 >>>>>> - end of new text - >>>>>>=20 >>>>>> For information, for those not accessing the url in the first >>>>>> paragraph of this email, the full Ofcom requirements leading to >>>>>> this new PAWS text are as follows: >>>>>>=20 >>>>>> 3.18 After receiving instructions from a WSDB in relation to the >>>>>> maximum permitted EIRPs over the DTT channels, and prior to >>>>>> initiating transmissions within the UHF TV band, a master WSD must >>>>>> communicate to the WSDB the following information: >>>>>>=20 >>>>>> 3.18.1 The lower and upper frequency boundaries^13 of the in-block >>>>>> emissions of the master WSD, and those of the in-block emissions >>>>>> of its associated slaves. A lower frequency will be specified as >>>>>> (470 + 8k + >>>>>> 0.2n) MHz, with the corresponding upper frequency specified as >>>>>> (470 + 8k >>>>>> + 0.2m) MHz, where 0 3=AE4 k 3=AE4 39, 0 3=AE4 n 3=AE4 39, 1 3=AE4 m= 3=AE4 40, and n< m. >>>>>>=20 >>>>>> 3.18.2 The maximum in-block EIRP spectral densities (in dBm/(0.2 >>>>>> MHz)) that the master WSD, and its associated slaves, actually >>>>>> radiate between each reported lower frequency boundary and its >>>>>> corresponding upper frequency boundary. >>>>>>=20 >>>>>> Footnote 13 states: >>>>>>=20 >>>>>> The use of upper and lower frequency boundaries (defined over a >>>>>> 200 kHz >>>>>> raster) allows a WSDB to collect more granular information with >>>>>> regards to the usage of the frequency resource by narrowband WSD >>>>>> technologies. >>>>>> The upper and lower frequencies of a boundary pair do not straddle >>>>>> a DTT channel boundary. Note that a WSD may transmit over >>>>>> multiple, non-contiguous, whole DTT channels or fractions of DTT cha= nnels. >>>>>>=20 >>>>>> 3.19 A master WSD must be able to receive the following >>>>>> information^14 from a WSDB: >>>>>>=20 >>>>>> >>>>>>=20 >>>>>> 3.19.8 [An acknowledgement from the WSDB, in the context of 3.18= , >>>>>> that the reported information on the DTT channels and EIRP >>>>>> spectral densities actually used by the master and slave WSDs were >>>>>> received successfully by the WSDB^18 ]. >>>>>>=20 >>>>>> Footnote 14 states: >>>>>>=20 >>>>>> 14 While the communication of some of this information from a WSDB >>>>>> to a master WSD is optional, master WSDs must be able to receive >>>>>> and interpret these. >>>>>>=20 >>>>>> Footnote 18 states: >>>>>>=20 >>>>>> 18 This forms part of a handshake protocol and may be an area >>>>>> where industry could harmonise without the need for an explicit >>>>>> requirement in the regulations. >>>>>>=20 >>>>>> Regards >>>>>>=20 >>>>>> Andy >>>>>>=20 >>>>>> *From:*paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On >>>>>> Behalf Of *Gabor.Bajko@nokia.com >>>>>> *Sent:* 05 March 2012 19:46 >>>>>> *To:* paws@ietf.org >>>>>> *Subject:* [paws] WGLC for >>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >>>>>>=20 >>>>>> The authors of the use cases and requirements draft have just >>>>>> posted a new version of the draft and indicated that there are no >>>>>> unresolved comments/issues they are aware of. >>>>>>=20 >>>>>> Therefore, I'd like to initiate a WG Last Call for comments on >>>>>> http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-u >>>>>> seca >>>>>> ses-rqmts-03.txt >>>>>>=20 >>>>>>=20 >>>>>> Please review the draft and send your comments to the list by >>>>>> March 20th, 2012. >>>>>>=20 >>>>>> If you review the draft and have no comments, send a note to the >>>>>> list that the draft is good as it is, we need these notes as much >>>>>> as we need the actual comments. >>>>>>=20 >>>>>> Thanks, Gabor >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> paws mailing list >>>>>> paws@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>>=20 >>>>=20 >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>=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 d.joslyn@spectrumbridge.com Wed Mar 7 13:39:58 2012 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 C3B1211E80A3 for ; Wed, 7 Mar 2012 13:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.975 X-Spam-Level: X-Spam-Status: No, score=-1.975 tagged_above=-999 required=5 tests=[AWL=0.396, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Kud+5096NL+h for ; Wed, 7 Mar 2012 13:39:55 -0800 (PST) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 74A6411E80A1 for ; Wed, 7 Mar 2012 13:39:55 -0800 (PST) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Wed, 7 Mar 2012 16:40:55 -0500 From: Don Joslyn To: "Zuniga, Juan Carlos" , "paws@ietf.org" , "Gabor.Bajko@nokia.com" Date: Wed, 7 Mar 2012 16:40:46 -0500 Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: protocol details Thread-Index: Acz7CHkh/FNx3kOiQQWaHcNbcyzaWwAsH3rwADxBwxA= Message-ID: <8375F6DAEFB09F48815203F1FE23B797113CB4E784@shelby> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601E1A52E@008-AM1MPN1-006.mgdnok.nokia.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: multipart/alternative; boundary="_000_8375F6DAEFB09F48815203F1FE23B797113CB4E784shelby_" MIME-Version: 1.0 Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: protocol details X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 21:39:58 -0000 --_000_8375F6DAEFB09F48815203F1FE23B797113CB4E784shelby_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: - P.14/P.15 state that the protocol must support a "validation req= uest from the master to the database to validate a slave device". Is this a= master relaying a request to the WSDB on behalf of a slave? It is not clea= r what validation means. It would be good to provide some more explanatory = text. In the context of FCC certified databases and devices, Fixed or Mode II TVB= D (master devices) must verify that the FCC identifier (FCC ID) of the Mode= I device (slave) is valid before sending a channel list to the slave. In other words, before a master device sends a channel list to a slave devi= ce, the master device must send a verification request message to the datab= ase to validate the slave's reported FCC ID. The master may only send a cha= nnel list to the slave device after the database has validated the FCC ID b= y sending a success in the reply to a verification request message. Don From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Zun= iga, Juan Carlos Sent: Tuesday, March 06, 2012 6:18 PM To: paws@ietf.org; Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03= : protocol details Hi all, I have taken a look at the Ofcom requirements reference on the CEPT site an= d besides the points raised by Andy I believe the following protocol requir= ements should also be addressed in the PAWS requirements doc: - Ofcom 3.11 A master WSD must communicate its technology identifi= er to a WSDB - This is needed to identify the type of RAT being used, beyon= d the antenna, power and channel characteristics. Having said that, we had = some issues in IEEE 802.21 where we were playing a horse race with the cons= tantly evolving 802.11, 3GPP, etc PHY technologies, so perhaps another appr= oach could be to specify directly the modulation, medium access method, etc= . instead of the actual RAT ID. We don't need to define the actual solution= now, as long as the requirement allows it in the future. Suggested text: o D.5: The Data Model MUST support specifying an ID of the transmitter = device. This ID would contain the ID of the transmitter device that has be= en certified by a regulatory body for its regulatory domain. The Data Mode= l MUST support a device class. The Data Model MUST support specify= ing information about the type of RAT of the transmitter device. - Ofcom 3.15 A master WSD must communicate to a WSDB whether it= , and its associated slave WSDs, are fixed devices or portable/mobile devic= es - Not sure if this is covered by "device class" in D.5. Since Device Cla= ss is not defined in the document, I would suggest either defining it as in= cluding fixed vs. mobile/portable characteristics, or adding a sentence at = the end of D.5 such as "The Data Model MUST support specifying whether the = transmitter device is fixed or mobile/portable." - Ofcom 3.16 A fixed master WSD may communicate to a WSDB wheth= er it, and its associated fixed slave WSDs, are indoor devices or outdoor d= evices - Similar to the previous 3.15 requirement. I would suggest either a= dding a definition for Device Class including indoor or outdoor characteris= tics, or adding a sentence in D.5 like "The Data Model MAY support specifyi= ng whether the transmitter is an outdoor or indoor device." Also, I believe we need to add some clarification on the following: - P.14/P.15 state that the protocol must support a "validation req= uest from the master to the database to validate a slave device". Is this a= master relaying a request to the WSDB on behalf of a slave? It is not clea= r what validation means. It would be good to provide some more explanatory = text. - Now that the CEPT version of the Ofcom requirements is publicly = available we should add a reference to the document in Section 3.3 "Backgro= und information on white space in the UK." Regards, Juan Carlos From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Gabor.Baj= ko@nokia.com Sent: Monday, March 05, 2012 2:46 PM To: paws@ietf.org Subject: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03 The authors of the use cases and requirements draft have just posted a new = version of the draft and indicated that there are no unresolved comments/is= sues they are aware of. Therefore, I'd like to initiate a WG Last Call for comments on http://www.i= etf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rqmts-03.txt Please review the draft and send your comments to the list by March 20th, 2= 012. If you review the draft and have no comments, send a note to the list that = the draft is good as it is, we need these notes as much as we need the actu= al comments. Thanks, Gabor --_000_8375F6DAEFB09F48815203F1FE23B797113CB4E784shelby_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Re:

-        =   P.14/P.= 15 state that the protocol must support a “validation request from th= e master to the database to validate a slave device”. Is this a maste= r relaying a request to the WSDB on behalf of a slave? It is not clear what= validation means. It would be good to provide some more explanatory text.<= o:p>

 

In the context of FCC certified databases and devices, Fixed or Mode II TV= BD (master devices) must verify that the FCC identifier (FCC ID) of the Mod= e I device (slave) is valid before sending a channel list to the slave.

&= nbsp;

In= other words, before a master device sends a channel list to a slave device= , the master device must send a verification request message to the databas= e to validate the slave’s reported FCC ID. The master may only send a= channel list to the slave device after the database has validated the FCC = ID by sending a success in the reply to a verification request message.

&= nbsp;

Do= n

<= o:p> 

From: paws-boun= ces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Zuniga, Jua= n Carlos
Sent: Tuesday, March 06, 2012 6:18 PM
To: paws= @ietf.org; Gabor.Bajko@nokia.com
Subject: Re: [paws] WGLC for dra= ft-ietf-paws-problem-stmt-usecases-rqmts-03: protocol details

 

Hi all,

 

I have taken a look at the O= fcom requirements reference on the CEPT site and besides the points raised = by Andy I believe the following protocol requirements should also be addres= sed in the PAWS requirements doc:

 

-<= span style=3D'font:7.0pt "Times New Roman"'>     &= nbsp;    Ofcom 3.11 A master WSD must communicate its technology identifie= r to a WSDB – This is needed to identify the type of RAT being used, = beyond the antenna, power and channel characteristics. Having said that, we= had some issues in IEEE 802.21 where we were playing a horse race with the= constantly evolving 802.11, 3GPP, etc PHY technologies, so perhaps another= approach could be to specify directly the modulation, medium access method= , etc. instead of the actual RAT ID. We don’t need to define the actu= al solution now, as long as the requirement allows it in the future. Sugges= ted text:

o   D.5:  = The Data Model MUST support specifying an ID of the transmitter device.&nb= sp; This ID would contain the ID of the transmitter device that has been ce= rtified by a regulatory body for its regulatory domain.  The Data Mode= l MUST support a device class. <Insert> The Data Model MUST support s= pecifying information about the type of RAT of the transmitter device.</= Insert>

 

-         = ; Ofcom 3.15&n= bsp;   A master WSD must communicate to a WSDB whether it, and it= s associated slave WSDs, are fixed devices or portable/mobile devices ̵= 1; Not sure if this is covered by “device class” in D.5. Since = Device Class is not defined in the document, I would suggest either definin= g it as including fixed vs. mobile/portable characteristics, or adding a se= ntence at the end of D.5 such as “The Data Model MUST support specify= ing whether the transmitter device is fixed or mobile/portable.”=

=  

-          = Ofcom 3.16  = ;  A fixed master WSD may communicate to a WSDB whether it, and its as= sociated fixed slave WSDs, are indoor devices or outdoor devices – Si= milar to the previous 3.15 requirement. I would suggest either adding a def= inition for Device Class including indoor or outdoor characteristics, or ad= ding a sentence in D.5 like “The Data Model MAY support specifying wh= ether the transmitter is an outdoor or indoor device.”

 =

Also, I belie= ve we need to add some clarification on the following:

 

- &n= bsp;        P.14/P.15 state that the protocol must sup= port a “validation request from the master to the database to validat= e a slave device”. Is this a master relaying a request to the WSDB on= behalf of a slave? It is not clear what validation means. It would be good= to provide some more explanatory text.

 

-    = ;      Now that the CEPT version of the Ofcom requirements is p= ublicly available we should add a reference to the document in Section 3.3 = “Background information on white space in the UK.”

&nb= sp;

Rega= rds,

 

Juan Carlos

 

From: paws-bounces@ietf= .org [mailto:paws-bou= nces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com
Sent: Monday, March 05, 2012 2:46 = PM
To: paws@ietf.org
S= ubject: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03<= o:p>

 

=

The authors of the use cases and requirements draft= have just posted a new version of the draft and indicated that there are n= o unresolved comments/issues they are aware of.

 

Therefore, I'd like to initiate= a WG Last Call for comments on http://www.ietf.org= /internet-drafts/draft-ietf-paws-problem-stmt-usecases-rqmts-03.txt

 

Please review the draft and send your comments to the list by March 20th, = 2012.

 

If you review the draft and have no comments, send a note to the l= ist that the draft is good as it is, we need these notes as much as we need= the actual comments.

 

Thanks, Gabor

 

= --_000_8375F6DAEFB09F48815203F1FE23B797113CB4E784shelby_-- From ghorn@qualcomm.com Wed Mar 7 16:12:46 2012 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 126F511E8072 for ; Wed, 7 Mar 2012 16:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.371 X-Spam-Level: X-Spam-Status: No, score=-106.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 LnwcHvsT2Or5 for ; Wed, 7 Mar 2012 16:12:41 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 0698921F84E6 for ; Wed, 7 Mar 2012 16:12:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ghorn@qualcomm.com; q=dns/txt; s=qcdkim; t=1331165560; x=1362701560; h=from:to:subject:thread-topic:thread-index:date: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:x-originating-ip: content-type:mime-version; z=From:=20"Horn,=20Gavin"=20|To:=20Don =20Joslyn=20,=20"Zuniga,=20J uan=20Carlos"=0D=0A=09,=20"paws@ietf.org"=20,=0D=0A=09"Gabor.Ba jko@nokia.com"=20|Subject:=20RE: =20[paws]=20WGLC=20for=20draft-ietf-paws-problem-stmt-use cases-rqmts-03:=0D=0A=09protocol=20details|Thread-Topic: =20[paws]=20WGLC=20for=0D=0A=20draft-ietf-paws-problem-st mt-usecases-rqmts-03:=09protocol=20details|Thread-Index: =20Acz8wBBlg4+pa03QTXiFs3QuD9yPOA=3D=3D|Date:=20Thu,=208 =20Mar=202012=2000:12:38=20+0000|Message-ID:=20<66361BFB3 0EEF84D8D64DC9FB5C2ADE222E2A385@nasanexd02a.na.qualcomm.c om>|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|x-originating-ip: =20[172.30.48.1]|Content-Type:=20multipart/alternative=3B =0D=0A=09boundary=3D"_000_66361BFB30EEF84D8D64DC9FB5C2ADE 222E2A385nasanexd02anaqu_"|MIME-Version:=201.0; bh=G5ixXRrNK6JoScRqdkWweqtl+e9mu+Xrr78hF7UfcpA=; b=KeyUI1xvZ8IpC6KVK717ZzLqu/z+g4taNRq/U2E3PUDYqLYqrOTo6j0O 9P4utwbRQ0UldDJ6F31ujEBBuEXDYoL96fpKzYfolFZ3vFoIPTG2KjB2F D3p8jKyxvPLj98DXNfNqSCd398Fe+rjUrL2LDC27tysPas3Q5S5i/hGJT A=; X-IronPort-AV: E=McAfee;i="5400,1158,6642"; a="168127470" Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by wolverine02.qualcomm.com with ESMTP; 07 Mar 2012 16:12:40 -0800 X-IronPort-AV: E=Sophos;i="4.73,546,1325491200"; d="scan'208,217";a="119611010" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 07 Mar 2012 16:12:40 -0800 Received: from NASANEXD02A.na.qualcomm.com ([169.254.1.199]) by nasanexhc04.na.qualcomm.com ([172.30.48.17]) with mapi id 14.01.0339.001; Wed, 7 Mar 2012 16:12:39 -0800 From: "Horn, Gavin" To: Don Joslyn , "Zuniga, Juan Carlos" , "paws@ietf.org" , "Gabor.Bajko@nokia.com" Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: protocol details Thread-Index: Acz8wBBlg4+pa03QTXiFs3QuD9yPOA== Date: Thu, 8 Mar 2012 00:12:38 +0000 Message-ID: <66361BFB30EEF84D8D64DC9FB5C2ADE222E2A385@nasanexd02a.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.48.1] Content-Type: multipart/alternative; boundary="_000_66361BFB30EEF84D8D64DC9FB5C2ADE222E2A385nasanexd02anaqu_" MIME-Version: 1.0 Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: protocol details X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 00:12:46 -0000 --_000_66361BFB30EEF84D8D64DC9FB5C2ADE222E2A385nasanexd02anaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Some comments on the requirements with respect to the scope of the document The following requirements seem unrelated to the master and database interf= ace and can probably be deleted - P.13: The protocol MUST support a channel query request from th= e slave device to the master device. The channel query request message MUS= T include parameters as required by local regulatory requirement. These pa= rameters MAY include device ID and slave device location. - P.16: The protocol MUST support a channel query response from t= he master device to the slave device. The channel query response message M= UST include parameters as required by local regulatory requirement, includi= ng a response code and sufficient information to decode an enabling signal. - P.17: The protocol MUST support an enabling signal sent from th= e master to the slave. This signal MUST allow the slave device to validate= that a previously received available channel list is still valid or not. = This signal MUST be encoded to allow the slave device to determine the iden= tity if the sending master device. - O.13: After the master device has received a response from the = database, the master device MUST respond to the slave device. If all regul= atory requirements are met the response will contain an available channel l= ist. If regulatory requirements are not met, the response MUST contain at = least a response code. - O.14: If a master device has provided an available channel list= to a slave device the master device MAY send a periodic enabling signal to= allow the slave device to confirm it is still within reception range of th= e master device. - O.15: The enabling signal MUST be encoded so that the receiving= slave can determine the identity of the sending master. - O.16: Periodically, at an interval according to local regulatio= ns, the slave device MUST either receive and enabling signal or MUST succes= sfully repeat the channel request process or MUST cease transmission on the= channel. - O.19: If slave devices change their location during operation b= y more than a limit specified by the local regulator, the slave device MUST= query the master device for available operating channels. P.14 already covers the forwarding of information received in P.13 from the= slave, so it is not clear why P.13 is needed. The concept of an enabling signal in P.16, P.17, O.14, O.15 and O.16 is air= interface specific between the master and slave. Similarly O.13 contains d= etails of masters response to the slave. For O.19, the requirement is subje= ct to local regulation but is also probably not needed for the PAWS work ei= ther since it is related to the master and slave only. P.11 and P.19 are very similar and should probably be merged Regards Gavin From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Don= Joslyn Sent: Wednesday, March 07, 2012 1:41 PM To: Zuniga, Juan Carlos; paws@ietf.org; Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03= : protocol details Re: - P.14/P.15 state that the protocol must support a "validation req= uest from the master to the database to validate a slave device". Is this a= master relaying a request to the WSDB on behalf of a slave? It is not clea= r what validation means. It would be good to provide some more explanatory = text. In the context of FCC certified databases and devices, Fixed or Mode II TVB= D (master devices) must verify that the FCC identifier (FCC ID) of the Mode= I device (slave) is valid before sending a channel list to the slave. In other words, before a master device sends a channel list to a slave devi= ce, the master device must send a verification request message to the datab= ase to validate the slave's reported FCC ID. The master may only send a cha= nnel list to the slave device after the database has validated the FCC ID b= y sending a success in the reply to a verification request message. Don From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Zun= iga, Juan Carlos Sent: Tuesday, March 06, 2012 6:18 PM To: paws@ietf.org; Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03= : protocol details Hi all, I have taken a look at the Ofcom requirements reference on the CEPT site an= d besides the points raised by Andy I believe the following protocol requir= ements should also be addressed in the PAWS requirements doc: - Ofcom 3.11 A master WSD must communicate its technology identifi= er to a WSDB - This is needed to identify the type of RAT being used, beyon= d the antenna, power and channel characteristics. Having said that, we had = some issues in IEEE 802.21 where we were playing a horse race with the cons= tantly evolving 802.11, 3GPP, etc PHY technologies, so perhaps another appr= oach could be to specify directly the modulation, medium access method, etc= . instead of the actual RAT ID. We don't need to define the actual solution= now, as long as the requirement allows it in the future. Suggested text: o D.5: The Data Model MUST support specifying an ID of the transmitter = device. This ID would contain the ID of the transmitter device that has be= en certified by a regulatory body for its regulatory domain. The Data Mode= l MUST support a device class. The Data Model MUST support specify= ing information about the type of RAT of the transmitter device. - Ofcom 3.15 A master WSD must communicate to a WSDB whether it= , and its associated slave WSDs, are fixed devices or portable/mobile devic= es - Not sure if this is covered by "device class" in D.5. Since Device Cla= ss is not defined in the document, I would suggest either defining it as in= cluding fixed vs. mobile/portable characteristics, or adding a sentence at = the end of D.5 such as "The Data Model MUST support specifying whether the = transmitter device is fixed or mobile/portable." - Ofcom 3.16 A fixed master WSD may communicate to a WSDB wheth= er it, and its associated fixed slave WSDs, are indoor devices or outdoor d= evices - Similar to the previous 3.15 requirement. I would suggest either a= dding a definition for Device Class including indoor or outdoor characteris= tics, or adding a sentence in D.5 like "The Data Model MAY support specifyi= ng whether the transmitter is an outdoor or indoor device." Also, I believe we need to add some clarification on the following: - P.14/P.15 state that the protocol must support a "validation req= uest from the master to the database to validate a slave device". Is this a= master relaying a request to the WSDB on behalf of a slave? It is not clea= r what validation means. It would be good to provide some more explanatory = text. - Now that the CEPT version of the Ofcom requirements is publicly = available we should add a reference to the document in Section 3.3 "Backgro= und information on white space in the UK." Regards, Juan Carlos From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Gabor.Baj= ko@nokia.com Sent: Monday, March 05, 2012 2:46 PM To: paws@ietf.org Subject: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03 The authors of the use cases and requirements draft have just posted a new = version of the draft and indicated that there are no unresolved comments/is= sues they are aware of. Therefore, I'd like to initiate a WG Last Call for comments on http://www.i= etf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rqmts-03.txt Please review the draft and send your comments to the list by March 20th, 2= 012. If you review the draft and have no comments, send a note to the list that = the draft is good as it is, we need these notes as much as we need the actu= al comments. Thanks, Gabor --_000_66361BFB30EEF84D8D64DC9FB5C2ADE222E2A385nasanexd02anaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Some comments on the requirements with respect to th= e scope of the document

 

The following requirements seem unrelated to the mas= ter and database interface and can probably be deleted

 

-P.13:  The protocol MUST support a channel qu= ery request from the slave device to the master device.  The channel q= uery request message MUST include parameters as required by local regulatory requirement.  These parameters MAY include device= ID and slave device location.

 

=
-       &nb=
sp;  P.16:  The protocol MUST supp=
ort a channel query response from the master device to the slave device.&nb=
sp; The channel query response message MUST include parameters as required =
by local regulatory requirement, including a response code and sufficient i=
nformation to decode an enabling signal.
 
=
-       &nb=
sp;  P.17:  The protocol MUST supp=
ort an enabling signal sent from the master to the slave.  This signal=
 MUST allow the slave device to validate that a previously received availab=
le channel list is still valid or not.  This signal MUST be encoded to=
 allow the slave device to determine the identity if the sending master dev=
ice.
 

 

=
-       &nb=
sp;  O.13:  After the master devic=
e has received a response from the database, the master device MUST respond=
 to the slave device.  If all regulatory requirements are met the resp=
onse will contain an available channel list.  If regulatory requiremen=
ts are not met, the response MUST contain at least a response code.
 
=
-       &nb=
sp;  O.14:  If a master device has=
 provided an available channel list to a slave device the master device MAY=
 send a periodic enabling signal to allow the slave device to confirm it is=
 still within reception range of the master device.
 
=
-       &nb=
sp;  O.15:  The enabling signal MU=
ST be encoded so that the receiving slave can determine the identity of the=
 sending master.
 
=
-       &nb=
sp;  O.16:  Periodically, at an in=
terval according to local regulations, the slave device MUST either receive=
 and enabling signal or MUST successfully repeat the channel request proces=
s or MUST cease transmission on the channel.
 

 

=
-       &nb=
sp;  O.19:  If slave devices chang=
e their location during operation by more than a limit specified by the loc=
al regulator, the slave device MUST query the master device for available o=
perating channels.
 

P.14 already covers the forwarding of information re= ceived in P.13 from the slave, so it is not clear why P.13 is needed.<= /o:p>

 

The concept of an enabling signal in P.16, P.17, O.1= 4, O.15 and O.16 is air interface specific between the master and slave. Si= milarly O.13 contains details of masters response to the slave. For O.19, t= he requirement is subject to local regulation but is also probably not needed for the PAWS work either since = it is related to the master and slave only.

 

P.11 and P.19 are very similar and should probably b= e merged

 

Regards

Gavin

 

 

From: paws-bou= nces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Don Joslyn
Sent: Wednesday, March 07, 2012 1:41 PM
To: Zuniga, Juan Carlos; paws@ietf.org; Gabor.Bajko@nokia.com
Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-r= qmts-03: protocol details

 

Re: =

-&nb= sp;         P.14/P.15 stat= e that the protocol must support a “validation request from the maste= r to the database to validate a slave device”. Is this a master relay= ing a request to the WSDB on behalf of a slave? It is not clear what validation means. It would be good to provide some mo= re explanatory text.

 

In the context of FCC = certified databases and devices, Fixed or Mode II TVBD (master devices) mus= t verify that the FCC identifier (FCC ID) of the Mode I device (slave) is v= alid before sending a channel list to the slave.

 

In other words, before= a master device sends a channel list to a slave device, the master device = must send a verification request message to the database to validate the sl= ave’s reported FCC ID. The master may only send a channel list to the slave device after the database has valida= ted the FCC ID by sending a success in the reply to a verification request = message.

 

Don<= /p>

 

From: paws-bou= nces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Zuniga, Juan Carlos
Sent: Tuesday, March 06, 2012 6:18 PM
To: paws@ietf.org; Gabor.Bajko@nokia.com
Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-r= qmts-03: protocol details

 

Hi all,

 

I have taken a look at= the Ofcom requirements reference on the CEPT site and besides the points r= aised by Andy I believe the following protocol requirements should also be = addressed in the PAWS requirements doc:

 

-&nb= sp;         Ofcom 3.11 A m= aster WSD must communicate its technology identifier to a WSDB – This= is needed to identify the type of RAT being used, beyond the antenna, powe= r and channel characteristics. Having said that, we had some issues in IEEE 802.21 where we were playing a horse race= with the constantly evolving 802.11, 3GPP, etc PHY technologies, so perhap= s another approach could be to specify directly the modulation, medium acce= ss method, etc. instead of the actual RAT ID. We don’t need to define the actual solution now, as long as = the requirement allows it in the future. Suggested text:<= /p>

o   D.5: &nbs= p; The Data Model MUST support specifying an ID of the transmitter device.&= nbsp; This ID would contain the ID of the transmitter device that has been = certified by a regulatory body for its regulatory domain.  The Data Model MUST support a device class. <Insert> T= he Data Model MUST support specifying information about the type of RAT of = the transmitter device.</Insert>

 

-&nb= sp;         Ofcom 3.15&nbs= p;   A master WSD must communicate to a WSDB whether it, and its = associated slave WSDs, are fixed devices or portable/mobile devices –= Not sure if this is covered by “device class” in D.5. Since Device Class is not defined in the document, I would suggest either = defining it as including fixed vs. mobile/portable characteristics, or addi= ng a sentence at the end of D.5 such as “The Data Model MUST support = specifying whether the transmitter device is fixed or mobile/portable.”

 

-&nb= sp;         Ofcom 3.16&nbs= p;   A fixed master WSD may communicate to a WSDB whether it, and= its associated fixed slave WSDs, are indoor devices or outdoor devices = 211; Similar to the previous 3.15 requirement. I would suggest either adding a definition for Device Class including indoor or ou= tdoor characteristics, or adding a sentence in D.5 like “The Data Mod= el MAY support specifying whether the transmitter is an outdoor or indoor d= evice.”

 

Also, I believe we nee= d to add some clarification on the following:

 

-&nb= sp;         P.14/P.15 stat= e that the protocol must support a “validation request from the maste= r to the database to validate a slave device”. Is this a master relay= ing a request to the WSDB on behalf of a slave? It is not clear what validation means. It would be good to provide some mo= re explanatory text.

 

-&nb= sp;         Now that the C= EPT version of the Ofcom requirements is publicly available we should add a= reference to the document in Section 3.3 “Background information on = white space in the UK.”

 

Regards,

 

Juan Carlos

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com
Sent: Monday, March 05, 2012 2:46 PM
To: paws@ietf.org
Subject: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts= -03

 

The authors of the use cases and requirements dra= ft have just posted a new version of the draft and indicated that there are= no unresolved comments/issues they are aware of.

 

Therefore, I'd like t= o initiate a WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-r= qmts-03.txt

 

Please review the dra= ft and send your comments to the list by March 20th, 2012.

 

If you review the dra= ft and have no comments, send a note to the list that the draft is good as = it is, we need these notes as much as we need the actual comments.

 

Thanks, Gabor

 

--_000_66361BFB30EEF84D8D64DC9FB5C2ADE222E2A385nasanexd02anaqu_-- From stpeter@stpeter.im Wed Mar 7 16:41:50 2012 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 6496211E8085 for ; Wed, 7 Mar 2012 16:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.357 X-Spam-Level: X-Spam-Status: No, score=-101.357 tagged_above=-999 required=5 tests=[AWL=-1.385, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, 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 IN9mxji1bqqn for ; Wed, 7 Mar 2012 16:41:49 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA9411E8080 for ; Wed, 7 Mar 2012 16:41:49 -0800 (PST) Received: from squire.local (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2306B4005B; Wed, 7 Mar 2012 17:53:49 -0700 (MST) Message-ID: <4F58004B.5000201@stpeter.im> Date: Wed, 07 Mar 2012 17:41:47 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Rosen, Brian" References: <4F5643A8.7000706@joelhalpern.com> <619CDADDCCD2B44380834BE8BF6F71414069146126@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "paws@ietf.org" , Pete Resnick , "johnny.dixon@bt.com" , "chris.cheeseman@bt.com" Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 00:41:50 -0000 As your responsible Area Director (until March 28, when Pete Resnick will take over from me), I have reviewed this thread. In my opinion (I am happy to be proven wrong), this new requirement goes beyond what the charter defined as the scope of this working group, which was to enable a device to discover the white space available to it in its current location. Reporting usage back to the database is simply not mentioned in the charter. Earlier in this thread, Andy Sago wrote: There's no language I can find in the charter that explicitly puts this out of scope. An IETF charter defines what the working group shall work on. Many interesting features could be developed here. However, it is not the job of the charter to mention explicitly that each of those interesting features is out of scope. The charter does say: Once the device learns of the available white space (e.g., in a TV white space implementation, the list of available channels at that location), it can then select one of the bands from the list and begin to transmit and receive on the selected band. This text might have assumed that no further communication or authorization was required in order to select one of the bands from the list and then transmit/receive. Perhaps that assumption was mistaken. If so, it would be good to have a discussion about that, so we can determine if we need to revisit the assumptions we made early on. If in fact we made some faulty or limited assumptions, then let's get that out in the open. Peter On 3/7/12 9:40 AM, Rosen, Brian wrote: > > I'd also suggest that our charter limitation is really support for sharing of whitespace by whitespace devices. Reporting what you use is not sharing, it's just data gathering. > > The point of excluding sharing was to eliminate the complexities of what constituted fairness, and what kinds of communication might be needed between databases, where more than one could supply available whitespace in a band. This doesn't have any of those issues, > As long as it's just sending information, I don't have a problem. Once the database is supposed to do anything with it that involves changing what spectrum it reports, then I think we cross the line. > > Brian > > On Mar 6, 2012, at 12:28 PM, wrote: > >> Joel >> >> Indeed, the regulator has not described the process or provided a flow diagram, so there may be some wrinkles, but we need to provide for their intent. To answer your question, the channels that the master will use are sent in a separate message (described in P.12 ter), that occurs after the master receives the response to its channel request, but before the master can transmit. At this point, it knows what channels are available, and which one it will use. As far as the slaves are concerned, as they associate, the master will need to gather their details and send further channel usage messages to the database on their behalf. >> >> Regards >> >> Andy >> >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: 06 March 2012 17:05 >> To: scott.probasco@nokia.com >> Cc: paws@ietf.org; Cheeseman,CJ,Chris,COD R; Dixon,JS,Johnny,COD R >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting >> >> Ahh. I think I see where the request and my understanding divurge. >> If the idea here is that the master must provide, in the request, an indication of what channels it expects to use, I can at least understand that. I will return to technical concerns in a moment. >> >> However, when you say "provide channel usage information, in order to evaluate interference", what that says to me is providing, during operation, information as to what channels are being used, and at what power levels. That is what would be needed to analyze actual interference effects. >> And that is out of scope as I understand our scope. >> >> I do see a technical difficulty with having the master provide, as part of either registering or requesting spectrum information, what channels it intends to use. It doesn;t know what channels it intends to use. It intends to use some number of available channels. It will figure out which ones when it is told what is available. How can it send that information in the request? >> >> Yours, >> Joel >> >> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: >>> Hi, >>> >>> There is a similarity here with device ID. In context of PAWS we are >>> not concerned with why a device ID is required by a regulator, we >>> accept it is a requirement from a regulator and include it to the >>> protocol. Ofcom identifies in 3.18& 3.19 that channel usage >>> information is required and thus we need to include this information. >>> Since the master must provide this information prior to transmitting, >>> PAWS will not function in the UK without this information and thus I >>> believe channel usage information is integral to the channel request& response messaging. >>> >>> Kind Regards, >>> Scott >>> >>> >>> On 3/6/12 10:30 AM, "ext Joel M. Halpern" wrote: >>> >>>> I would draw a distinction. Ofcom regulations about whitespace >>>> requests are very much relevant. >>>> Ofcom regulations about notification of dynamic behavior (which >>>> spectrum is being used) are not in scope as I understand the earlier >>>> discussions, particularly the chartering discussions. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: >>>>> >>>>> The ofcom requirements are very much relevant to the scope of the >>>>> PAWS WG. >>>>> The only other regulatory requirements that we have today is the FCC. >>>>> Ofcom requirements are a good addition to the set. >>>>> >>>>> -Raj >>>>> >>>>> On 3/6/12 10:03 AM, "ext andy.sago@bt.com" wrote: >>>>> >>>>>> Hi Joel >>>>>> >>>>>> There's no language I can find in the charter that explicitly puts >>>>>> this out of scope. On the other hand, the charter says that the >>>>>> group will "consider input from regulatory entities", and this is >>>>>> one of the requirements from Ofcom that they have just published. >>>>>> The protocol will be worthless for the UK if it omits some >>>>>> requirements. >>>>>> >>>>>> Regards >>>>>> >>>>>> Andy >>>>>> >>>>>> -----Original Message----- >>>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>>>> Sent: 06 March 2012 15:53 >>>>>> To: Sago,AJ,Andy,COD R >>>>>> Cc: paws@ietf.org; Gabor.Bajko@nokia.com >>>>>> Subject: Re: [paws] WGLC for >>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting >>>>>> >>>>>> As I understand, the information you are asking for is explicitly >>>>>> out of scope for the working group. >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >>>>>>> All >>>>>>> >>>>>>> Comparing the draft with the Ofcom requirements at >>>>>>> http://www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-r >>>>>>> egul >>>>>>> atory-requirements-for-white-space-devices-in-the-UHF-TV-band, >>>>>>> I believe the WG draft is deficient in the area of reporting >>>>>>> frequencies and powers actually used by masters and slaves (Ofcom >>>>>>> requirements 3.18 and 3.19.8). Ofcom intends to collect this data >>>>>>> to assesses the impact of aggregate interference into other >>>>>>> services. It would also provide usage information (frequency in >>>>>>> use) that would inform the operation of a kill switch capability. >>>>>>> I suggest this deficiency can be remedied with the following changes: >>>>>>> >>>>>>> New P requirements (probably best placed following P.12): >>>>>>> >>>>>>> P.12bis: The protocol MUST support a channel usage message from >>>>>>> the slave device to the master device. The channel usage message >>>>>>> MUST include parameters as required by local regulatory >>>>>>> requirement. These parameters MAY include device ID, >>>>>>> manufacturer's serial number, channel usage and power level information. >>>>>>> >>>>>>> P.12ter: The protocol MUST support a channel usage message from >>>>>>> the master device to the database. The channel usage message MUST >>>>>>> include parameters as required by local regulatory requirement for >>>>>>> the master and its associated slaves. These parameters MAY >>>>>>> include device ID, manufacturer's serial number, channel usage and >>>>>>> power level information. >>>>>>> >>>>>>> P.12qua: The protocol MUST support a channel usage message >>>>>>> acknowledgement. >>>>>>> >>>>>>> New O requirements (probably best placed following O13): >>>>>>> >>>>>>> O.13bis: According to local regulatory policy, after connecting >>>>>>> to a master device's radio network a slave device MAY inform the >>>>>>> master device of the actual channel usage. The slave MUST include >>>>>>> parameters required by local regulatory policy, e.g. device ID, >>>>>>> manufacturer's serial number, channel usage and power level information. >>>>>>> >>>>>>> O.13ter: According to local regulatory policy, a master device >>>>>>> MAY inform the database of the actual channel usage of the master >>>>>>> and its slaves. The master MUST include parameters required by >>>>>>> local regulatory policy, e.g. device ID, manufacturer's serial >>>>>>> number, channel usage and power level information of the master >>>>>>> and its slaves. >>>>>>> >>>>>>> New steps could be introduced into one or more use cases to cover >>>>>>> these Ofcom requirements, e.g. new steps 6bis and 9bis in the >>>>>>> hotspot use case at 4.2.1: >>>>>>> >>>>>>> 6bis. Prior to initiating transmission, if required by local >>>>>>> regulation, the master/AP informs the database of the channel and >>>>>>> power level it has chosen. This is repeated for each slave that >>>>>>> associated with the master. >>>>>>> >>>>>>> 9bis. Prior to initiating transmission, if required by local >>>>>>> regulation, the slave informs the master/AP of the channel and >>>>>>> power level it has chosen, and the master/AP relays this >>>>>>> information to the database. >>>>>>> >>>>>>> - end of new text - >>>>>>> >>>>>>> For information, for those not accessing the url in the first >>>>>>> paragraph of this email, the full Ofcom requirements leading to >>>>>>> this new PAWS text are as follows: >>>>>>> >>>>>>> 3.18 After receiving instructions from a WSDB in relation to the >>>>>>> maximum permitted EIRPs over the DTT channels, and prior to >>>>>>> initiating transmissions within the UHF TV band, a master WSD must >>>>>>> communicate to the WSDB the following information: >>>>>>> >>>>>>> 3.18.1 The lower and upper frequency boundaries^13 of the in-block >>>>>>> emissions of the master WSD, and those of the in-block emissions >>>>>>> of its associated slaves. A lower frequency will be specified as >>>>>>> (470 + 8k + >>>>>>> 0.2n) MHz, with the corresponding upper frequency specified as >>>>>>> (470 + 8k >>>>>>> + 0.2m) MHz, where 0 3Ž4 k 3Ž4 39, 0 3Ž4 n 3Ž4 39, 1 3Ž4 m 3Ž4 40, and n< m. >>>>>>> >>>>>>> 3.18.2 The maximum in-block EIRP spectral densities (in dBm/(0.2 >>>>>>> MHz)) that the master WSD, and its associated slaves, actually >>>>>>> radiate between each reported lower frequency boundary and its >>>>>>> corresponding upper frequency boundary. >>>>>>> >>>>>>> Footnote 13 states: >>>>>>> >>>>>>> The use of upper and lower frequency boundaries (defined over a >>>>>>> 200 kHz >>>>>>> raster) allows a WSDB to collect more granular information with >>>>>>> regards to the usage of the frequency resource by narrowband WSD >>>>>>> technologies. >>>>>>> The upper and lower frequencies of a boundary pair do not straddle >>>>>>> a DTT channel boundary. Note that a WSD may transmit over >>>>>>> multiple, non-contiguous, whole DTT channels or fractions of DTT channels. >>>>>>> >>>>>>> 3.19 A master WSD must be able to receive the following >>>>>>> information^14 from a WSDB: >>>>>>> >>>>>>> >>>>>>> >>>>>>> 3.19.8 [An acknowledgement from the WSDB, in the context of 3.18, >>>>>>> that the reported information on the DTT channels and EIRP >>>>>>> spectral densities actually used by the master and slave WSDs were >>>>>>> received successfully by the WSDB^18 ]. >>>>>>> >>>>>>> Footnote 14 states: >>>>>>> >>>>>>> 14 While the communication of some of this information from a WSDB >>>>>>> to a master WSD is optional, master WSDs must be able to receive >>>>>>> and interpret these. >>>>>>> >>>>>>> Footnote 18 states: >>>>>>> >>>>>>> 18 This forms part of a handshake protocol and may be an area >>>>>>> where industry could harmonise without the need for an explicit >>>>>>> requirement in the regulations. >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Andy >>>>>>> >>>>>>> *From:*paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On >>>>>>> Behalf Of *Gabor.Bajko@nokia.com >>>>>>> *Sent:* 05 March 2012 19:46 >>>>>>> *To:* paws@ietf.org >>>>>>> *Subject:* [paws] WGLC for >>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >>>>>>> >>>>>>> The authors of the use cases and requirements draft have just >>>>>>> posted a new version of the draft and indicated that there are no >>>>>>> unresolved comments/issues they are aware of. >>>>>>> >>>>>>> Therefore, I'd like to initiate a WG Last Call for comments on >>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-u >>>>>>> seca >>>>>>> ses-rqmts-03.txt >>>>>>> >>>>>>> >>>>>>> Please review the draft and send your comments to the list by >>>>>>> March 20th, 2012. >>>>>>> >>>>>>> If you review the draft and have no comments, send a note to the >>>>>>> list that the draft is good as it is, we need these notes as much >>>>>>> as we need the actual comments. >>>>>>> >>>>>>> Thanks, Gabor >>>>>>> >>>>>>> From brian.rosen@neustar.biz Wed Mar 7 16:58:10 2012 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 2B0C511E8089 for ; Wed, 7 Mar 2012 16:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.87 X-Spam-Level: X-Spam-Status: No, score=-4.87 tagged_above=-999 required=5 tests=[AWL=-0.898, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4, 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 QYs88YfPt9Nn for ; Wed, 7 Mar 2012 16:58:08 -0800 (PST) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF5D21F85A2 for ; Wed, 7 Mar 2012 16:58:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1331168305; x=1646519905; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=OkMKJxqx+p/+YXemaR9pQ P2bRZEHyhLFvQwh08s/8EY=; b=nHVUergFMoUGB4O+G57uGjtNqT5s7Ruez8XFd bmdnoeCop3a/PRrmONI1VcnFP2n6aYJ1p7pAprZhK56lDAgpw== Received: from ([10.31.13.229]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.4030677; Wed, 07 Mar 2012 19:58:24 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Wed, 7 Mar 2012 19:58:01 -0500 From: "Rosen, Brian" To: Peter Saint-Andre Date: Wed, 7 Mar 2012 19:57:59 -0500 Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting Thread-Index: Acz8xoLFWIO3CO+3QEi8gBm19FFPCQ== Message-ID: <4B086951-E2F9-4775-B671-9ED717971AB3@neustar.biz> References: <4F5643A8.7000706@joelhalpern.com> <619CDADDCCD2B44380834BE8BF6F71414069146126@EMV62-UKRD.domain1.systemhost.net> <4F58004B.5000201@stpeter.im> In-Reply-To: <4F58004B.5000201@stpeter.im> 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: 4tPP2jFa7fPESso+Egh2CQ== Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" , Pete Resnick , "johnny.dixon@bt.com" , "chris.cheeseman@bt.com" Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 00:58:10 -0000 I think that this requirement easily fits in: In addition, the particular data exchanged between a device and a database might depend on the ranges of radio spectrum that are to be used, the REQUIREMENTS OF the database operators and their GOVERNING REGULATIONS, and other factors. emphasis added. It is data exchanged between the device and the database and It doesn't sig= nificantly alter the design of the protocol, and specifically doesn't tread= into areas of concern when the charter was written. We didn't have the be= nefit of the OFCOM rules at the time, or we could have explicitly included = it. Again, if the whitespace returned somehow depended on this information, the= n I think we would be out of scope. I defer to your decision, of course. Brian On Mar 7, 2012, at 7:41 PM, Peter Saint-Andre wrote: > > > As your responsible Area Director (until March 28, when Pete Resnick > will take over from me), I have reviewed this thread. > > In my opinion (I am happy to be proven wrong), this new requirement goes > beyond what the charter defined as the scope of this working group, > which was to enable a device to discover the white space available to it > in its current location. Reporting usage back to the database is simply > not mentioned in the charter. > > Earlier in this thread, Andy Sago wrote: > > There's no language I can find in the charter that explicitly puts > this out of scope. > > An IETF charter defines what the working group shall work on. Many > interesting features could be developed here. However, it is not the job > of the charter to mention explicitly that each of those interesting > features is out of scope. > > The charter does say: > > Once the device learns of the available white space (e.g., in a TV > white space implementation, the list of available channels at that > location), it can then select one of the bands from the list and > begin to transmit and receive on the selected band. > > This text might have assumed that no further communication or > authorization was required in order to select one of the bands from the > list and then transmit/receive. Perhaps that assumption was mistaken. If > so, it would be good to have a discussion about that, so we can > determine if we need to revisit the assumptions we made early on. If in > fact we made some faulty or limited assumptions, then let's get that out > in the open. > > Peter > > On 3/7/12 9:40 AM, Rosen, Brian wrote: >> >> I'd also suggest that our charter limitation is really support for shari= ng of whitespace by whitespace devices. Reporting what you use is not shar= ing, it's just data gathering. >> >> The point of excluding sharing was to eliminate the complexities of what= constituted fairness, and what kinds of communication might be needed betw= een databases, where more than one could supply available whitespace in a b= and. This doesn't have any of those issues, >> As long as it's just sending information, I don't have a problem. Once = the database is supposed to do anything with it that involves changing what= spectrum it reports, then I think we cross the line. >> >> Brian >> >> On Mar 6, 2012, at 12:28 PM, wrote= : >> >>> Joel >>> >>> Indeed, the regulator has not described the process or provided a flow = diagram, so there may be some wrinkles, but we need to provide for their in= tent. To answer your question, the channels that the master will use are se= nt in a separate message (described in P.12 ter), that occurs after the mas= ter receives the response to its channel request, but before the master can= transmit. At this point, it knows what channels are available, and which o= ne it will use. As far as the slaves are concerned, as they associate, the = master will need to gather their details and send further channel usage mes= sages to the database on their behalf. >>> >>> Regards >>> >>> Andy >>> >>> -----Original Message----- >>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of= Joel M. Halpern >>> Sent: 06 March 2012 17:05 >>> To: scott.probasco@nokia.com >>> Cc: paws@ietf.org; Cheeseman,CJ,Chris,COD R; Dixon,JS,Johnny,COD R >>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmt= s-03: channel reporting >>> >>> Ahh. I think I see where the request and my understanding divurge. >>> If the idea here is that the master must provide, in the request, an in= dication of what channels it expects to use, I can at least understand that= . I will return to technical concerns in a moment. >>> >>> However, when you say "provide channel usage information, in order to e= valuate interference", what that says to me is providing, during operation,= information as to what channels are being used, and at what power levels. = That is what would be needed to analyze actual interference effects. >>> And that is out of scope as I understand our scope. >>> >>> I do see a technical difficulty with having the master provide, as part= of either registering or requesting spectrum information, what channels it= intends to use. It doesn;t know what channels it intends to use. It inte= nds to use some number of available channels. It will figure out which one= s when it is told what is available. How can it send that information in t= he request? >>> >>> Yours, >>> Joel >>> >>> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: >>>> Hi, >>>> >>>> There is a similarity here with device ID. In context of PAWS we are >>>> not concerned with why a device ID is required by a regulator, we >>>> accept it is a requirement from a regulator and include it to the >>>> protocol. Ofcom identifies in 3.18& 3.19 that channel usage >>>> information is required and thus we need to include this information. >>>> Since the master must provide this information prior to transmitting, >>>> PAWS will not function in the UK without this information and thus I >>>> believe channel usage information is integral to the channel request& = response messaging. >>>> >>>> Kind Regards, >>>> Scott >>>> >>>> >>>> On 3/6/12 10:30 AM, "ext Joel M. Halpern" wrote: >>>> >>>>> I would draw a distinction. Ofcom regulations about whitespace >>>>> requests are very much relevant. >>>>> Ofcom regulations about notification of dynamic behavior (which >>>>> spectrum is being used) are not in scope as I understand the earlier >>>>> discussions, particularly the chartering discussions. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: >>>>>> >>>>>> The ofcom requirements are very much relevant to the scope of the >>>>>> PAWS WG. >>>>>> The only other regulatory requirements that we have today is the FCC= . >>>>>> Ofcom requirements are a good addition to the set. >>>>>> >>>>>> -Raj >>>>>> >>>>>> On 3/6/12 10:03 AM, "ext andy.sago@bt.com" wrote= : >>>>>> >>>>>>> Hi Joel >>>>>>> >>>>>>> There's no language I can find in the charter that explicitly puts >>>>>>> this out of scope. On the other hand, the charter says that the >>>>>>> group will "consider input from regulatory entities", and this is >>>>>>> one of the requirements from Ofcom that they have just published. >>>>>>> The protocol will be worthless for the UK if it omits some >>>>>>> requirements. >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Andy >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>>>>> Sent: 06 March 2012 15:53 >>>>>>> To: Sago,AJ,Andy,COD R >>>>>>> Cc: paws@ietf.org; Gabor.Bajko@nokia.com >>>>>>> Subject: Re: [paws] WGLC for >>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting >>>>>>> >>>>>>> As I understand, the information you are asking for is explicitly >>>>>>> out of scope for the working group. >>>>>>> Yours, >>>>>>> Joel >>>>>>> >>>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >>>>>>>> All >>>>>>>> >>>>>>>> Comparing the draft with the Ofcom requirements at >>>>>>>> http://www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-r >>>>>>>> egul >>>>>>>> atory-requirements-for-white-space-devices-in-the-UHF-TV-band, >>>>>>>> I believe the WG draft is deficient in the area of reporting >>>>>>>> frequencies and powers actually used by masters and slaves (Ofcom >>>>>>>> requirements 3.18 and 3.19.8). Ofcom intends to collect this data >>>>>>>> to assesses the impact of aggregate interference into other >>>>>>>> services. It would also provide usage information (frequency in >>>>>>>> use) that would inform the operation of a kill switch capability. >>>>>>>> I suggest this deficiency can be remedied with the following chang= es: >>>>>>>> >>>>>>>> New P requirements (probably best placed following P.12): >>>>>>>> >>>>>>>> P.12bis: The protocol MUST support a channel usage message from >>>>>>>> the slave device to the master device. The channel usage message >>>>>>>> MUST include parameters as required by local regulatory >>>>>>>> requirement. These parameters MAY include device ID, >>>>>>>> manufacturer's serial number, channel usage and power level inform= ation. >>>>>>>> >>>>>>>> P.12ter: The protocol MUST support a channel usage message from >>>>>>>> the master device to the database. The channel usage message MUST >>>>>>>> include parameters as required by local regulatory requirement for >>>>>>>> the master and its associated slaves. These parameters MAY >>>>>>>> include device ID, manufacturer's serial number, channel usage and >>>>>>>> power level information. >>>>>>>> >>>>>>>> P.12qua: The protocol MUST support a channel usage message >>>>>>>> acknowledgement. >>>>>>>> >>>>>>>> New O requirements (probably best placed following O13): >>>>>>>> >>>>>>>> O.13bis: According to local regulatory policy, after connecting >>>>>>>> to a master device's radio network a slave device MAY inform the >>>>>>>> master device of the actual channel usage. The slave MUST include >>>>>>>> parameters required by local regulatory policy, e.g. device ID, >>>>>>>> manufacturer's serial number, channel usage and power level inform= ation. >>>>>>>> >>>>>>>> O.13ter: According to local regulatory policy, a master device >>>>>>>> MAY inform the database of the actual channel usage of the master >>>>>>>> and its slaves. The master MUST include parameters required by >>>>>>>> local regulatory policy, e.g. device ID, manufacturer's serial >>>>>>>> number, channel usage and power level information of the master >>>>>>>> and its slaves. >>>>>>>> >>>>>>>> New steps could be introduced into one or more use cases to cover >>>>>>>> these Ofcom requirements, e.g. new steps 6bis and 9bis in the >>>>>>>> hotspot use case at 4.2.1: >>>>>>>> >>>>>>>> 6bis. Prior to initiating transmission, if required by local >>>>>>>> regulation, the master/AP informs the database of the channel and >>>>>>>> power level it has chosen. This is repeated for each slave that >>>>>>>> associated with the master. >>>>>>>> >>>>>>>> 9bis. Prior to initiating transmission, if required by local >>>>>>>> regulation, the slave informs the master/AP of the channel and >>>>>>>> power level it has chosen, and the master/AP relays this >>>>>>>> information to the database. >>>>>>>> >>>>>>>> - end of new text - >>>>>>>> >>>>>>>> For information, for those not accessing the url in the first >>>>>>>> paragraph of this email, the full Ofcom requirements leading to >>>>>>>> this new PAWS text are as follows: >>>>>>>> >>>>>>>> 3.18 After receiving instructions from a WSDB in relation to the >>>>>>>> maximum permitted EIRPs over the DTT channels, and prior to >>>>>>>> initiating transmissions within the UHF TV band, a master WSD must >>>>>>>> communicate to the WSDB the following information: >>>>>>>> >>>>>>>> 3.18.1 The lower and upper frequency boundaries^13 of the in-block >>>>>>>> emissions of the master WSD, and those of the in-block emissions >>>>>>>> of its associated slaves. A lower frequency will be specified as >>>>>>>> (470 + 8k + >>>>>>>> 0.2n) MHz, with the corresponding upper frequency specified as >>>>>>>> (470 + 8k >>>>>>>> + 0.2m) MHz, where 0 3=8E4 k 3=8E4 39, 0 3=8E4 n 3=8E4 39, 1 3=8E4= m 3=8E4 40, and n< m. >>>>>>>> >>>>>>>> 3.18.2 The maximum in-block EIRP spectral densities (in dBm/(0.2 >>>>>>>> MHz)) that the master WSD, and its associated slaves, actually >>>>>>>> radiate between each reported lower frequency boundary and its >>>>>>>> corresponding upper frequency boundary. >>>>>>>> >>>>>>>> Footnote 13 states: >>>>>>>> >>>>>>>> The use of upper and lower frequency boundaries (defined over a >>>>>>>> 200 kHz >>>>>>>> raster) allows a WSDB to collect more granular information with >>>>>>>> regards to the usage of the frequency resource by narrowband WSD >>>>>>>> technologies. >>>>>>>> The upper and lower frequencies of a boundary pair do not straddle >>>>>>>> a DTT channel boundary. Note that a WSD may transmit over >>>>>>>> multiple, non-contiguous, whole DTT channels or fractions of DTT c= hannels. >>>>>>>> >>>>>>>> 3.19 A master WSD must be able to receive the following >>>>>>>> information^14 from a WSDB: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in the context of 3.= 18, >>>>>>>> that the reported information on the DTT channels and EIRP >>>>>>>> spectral densities actually used by the master and slave WSDs were >>>>>>>> received successfully by the WSDB^18 ]. >>>>>>>> >>>>>>>> Footnote 14 states: >>>>>>>> >>>>>>>> 14 While the communication of some of this information from a WSDB >>>>>>>> to a master WSD is optional, master WSDs must be able to receive >>>>>>>> and interpret these. >>>>>>>> >>>>>>>> Footnote 18 states: >>>>>>>> >>>>>>>> 18 This forms part of a handshake protocol and may be an area >>>>>>>> where industry could harmonise without the need for an explicit >>>>>>>> requirement in the regulations. >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Andy >>>>>>>> >>>>>>>> *From:*paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On >>>>>>>> Behalf Of *Gabor.Bajko@nokia.com >>>>>>>> *Sent:* 05 March 2012 19:46 >>>>>>>> *To:* paws@ietf.org >>>>>>>> *Subject:* [paws] WGLC for >>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >>>>>>>> >>>>>>>> The authors of the use cases and requirements draft have just >>>>>>>> posted a new version of the draft and indicated that there are no >>>>>>>> unresolved comments/issues they are aware of. >>>>>>>> >>>>>>>> Therefore, I'd like to initiate a WG Last Call for comments on >>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-u >>>>>>>> seca >>>>>>>> ses-rqmts-03.txt >>>>>>>> >>>>>>>> >>>>>>>> Please review the draft and send your comments to the list by >>>>>>>> March 20th, 2012. >>>>>>>> >>>>>>>> If you review the draft and have no comments, send a note to the >>>>>>>> list that the draft is good as it is, we need these notes as much >>>>>>>> as we need the actual comments. >>>>>>>> >>>>>>>> Thanks, Gabor >>>>>>>> >>>>>>>> From stpeter@stpeter.im Wed Mar 7 17:25:04 2012 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 7721E21E800C for ; Wed, 7 Mar 2012 17:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=-0.112, 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 uzD6rhqTov2M for ; Wed, 7 Mar 2012 17:25:03 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B4BC021F8548 for ; Wed, 7 Mar 2012 17:25:03 -0800 (PST) Received: from squire.local (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 25D284005B; Wed, 7 Mar 2012 18:37:04 -0700 (MST) Message-ID: <4F580A6E.2090601@stpeter.im> Date: Wed, 07 Mar 2012 18:25:02 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Rosen, Brian" References: <4F5643A8.7000706@joelhalpern.com> <619CDADDCCD2B44380834BE8BF6F71414069146126@EMV62-UKRD.domain1.systemhost.net> <4F58004B.5000201@stpeter.im> <4B086951-E2F9-4775-B671-9ED717971AB3@neustar.biz> In-Reply-To: <4B086951-E2F9-4775-B671-9ED717971AB3@neustar.biz> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "paws@ietf.org" , Pete Resnick , "johnny.dixon@bt.com" , "chris.cheeseman@bt.com" Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 01:25:04 -0000 On 3/7/12 5:57 PM, Rosen, Brian wrote: > I think that this requirement easily fits in: > > In addition, the particular data exchanged between a device and a > database might depend on the ranges of radio spectrum that are to be > used, the REQUIREMENTS OF the database operators and their GOVERNING > REGULATIONS, and other factors. > > emphasis added. As I understood it, the device would query the database for available white space, and the database would reply. We thought that the query would contain at least the device's location: 3. Provide its geolocation and perhaps other data to the database using a well-defined format for querying the database. We also envisioned that extension points would be provided in the protocol so that the "other data" could be provided; the two sentences in the charter right after the one you just quoted are: Therefore, the database access method and the query/response data formats that are exchanged using that method need to be designed for extensibility rather than being tied to any specific spectrum, country, or phy/mac/air interface. For example, the working group should define extension points for the database access method and the query/response formats, so that use cases other than those currently envisioned can be addressed in the future if a community of interest wishes to do so. Correct me if I'm wrong, but what we're discussing here is not a new field in the database query -- it is a reporting mechanism. I would be more comfortable if we said something like "to meet Ofcom requirements, the database query needs to include [FieldX]". The charter does say: Once the device learns of the available white space (e.g., in a TV white space implementation, the list of available channels at that location), it can then select one of the bands from the list and begin to transmit and receive on the selected band. If the device's parameters have changed (e.g., if some amount of time has passed or if the device has changed location beyond a specified threshold), it might need to query the database again to determine what white space is still available. I suppose one could envision the following flow: 1. Device queries database. 2. Database responds with list of available channels. 3. Device queries database again, providing a new parameter: the actual channel it wants to use (which it can't know until it receives the original list of channels or tries to do something with the original list of channels, such as transmit/receive). 4. Database responds with updated list of available channels (where the updated list is based on information the device provided in step 3). That's a bit of a strange way to look at it, though. > It is data exchanged between the device and the database and It > doesn't significantly alter the design of the protocol, and > specifically doesn't tread into areas of concern when the charter was > written. We didn't have the benefit of the OFCOM rules at the time, > or we could have explicitly included it. > > Again, if the whitespace returned somehow depended on this > information, then I think we would be out of scope. But doesn't it? Or is this reporting purely informational? > I defer to your decision, of course. I am not a special person to whom one must defer. I'm just a member of the community who happens to be serving in the AD role for a few years. Peter -- Peter Saint-Andre https://stpeter.im/ From brian.rosen@neustar.biz Wed Mar 7 17:34:05 2012 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 D0F3521E8014 for ; Wed, 7 Mar 2012 17:34:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.025 X-Spam-Level: X-Spam-Status: No, score=-6.025 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 aJzUox+4NQNu for ; Wed, 7 Mar 2012 17:34:04 -0800 (PST) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3FA21E8011 for ; Wed, 7 Mar 2012 17:34:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1331170470; x=1646528902; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=A97iavxhwe8jslDbj0ui2 Kgp0UwmA2rGG1PjsH4rFIk=; b=G4EeDzf3/qdiYpXeGGCfRJxtjr6dDQtvwN9nr +yUHOVVlzmJFDXWL4ANbu4MlLkLmnW/iyd1mGd8ikeqSGRH2Q== Received: from ([10.31.13.229]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.5410212; Wed, 07 Mar 2012 20:34:28 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Wed, 7 Mar 2012 20:33:57 -0500 From: "Rosen, Brian" To: Peter Saint-Andre Date: Wed, 7 Mar 2012 20:33:55 -0500 Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting Thread-Index: Acz8y4dSZ4H45EKuSXiQOj46QMtRGA== Message-ID: References: <4F5643A8.7000706@joelhalpern.com> <619CDADDCCD2B44380834BE8BF6F71414069146126@EMV62-UKRD.domain1.systemhost.net> <4F58004B.5000201@stpeter.im> <4B086951-E2F9-4775-B671-9ED717971AB3@neustar.biz> <4F580A6E.2090601@stpeter.im> In-Reply-To: <4F580A6E.2090601@stpeter.im> 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: mCGvfF1+gBTKA/1jkn3xUQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" , Pete Resnick , "johnny.dixon@bt.com" , "chris.cheeseman@bt.com" Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 01:34:05 -0000 I guess I think we would extend the query to: Request (with device parameters) Response (with available spectrum) Acknowledge (with chosen spectrum) It then completely fits in the definition. I don't think the extra message= is anything particularly special, and a 3 way is a common transaction sequ= ence. As I understand the Ofcom rules, it's purely informational. Someone can co= rrect me if I am wrong. They want to monitor what is being used. Brian On Mar 7, 2012, at 8:25 PM, Peter Saint-Andre wrote: > >=20 > On 3/7/12 5:57 PM, Rosen, Brian wrote: >> I think that this requirement easily fits in: >>=20 >> In addition, the particular data exchanged between a device and a >> database might depend on the ranges of radio spectrum that are to be >> used, the REQUIREMENTS OF the database operators and their GOVERNING >> REGULATIONS, and other factors. >>=20 >> emphasis added. >=20 > As I understood it, the device would query the database for available > white space, and the database would reply. We thought that the query > would contain at least the device's location: >=20 > 3. Provide its geolocation and perhaps other data to the database > using a well-defined format for querying the database. >=20 > We also envisioned that extension points would be provided in the > protocol so that the "other data" could be provided; the two sentences > in the charter right after the one you just quoted are: >=20 > Therefore, the database access method and the query/response data > formats that are exchanged using that method need to be designed for > extensibility rather than being tied to any specific spectrum, > country, or phy/mac/air interface. For example, the working group > should define extension points for the database access method and the > query/response formats, so that use cases other than those currently > envisioned can be addressed in the future if a community of interest > wishes to do so. >=20 > Correct me if I'm wrong, but what we're discussing here is not a new > field in the database query -- it is a reporting mechanism. I would be > more comfortable if we said something like "to meet Ofcom requirements, > the database query needs to include [FieldX]". >=20 > The charter does say: >=20 > Once the device learns of the available white space (e.g., in a TV > white space implementation, the list of available channels at that > location), it can then select one of the bands from the list and > begin to transmit and receive on the selected band. If the device's > parameters have changed (e.g., if some amount of time has passed or if > the device has changed location beyond a specified threshold), it > might need to query the database again to determine what white space > is still available. >=20 > I suppose one could envision the following flow: >=20 > 1. Device queries database. >=20 > 2. Database responds with list of available channels. >=20 > 3. Device queries database again, providing a new parameter: the actual > channel it wants to use (which it can't know until it receives the > original list of channels or tries to do something with the original > list of channels, such as transmit/receive). >=20 > 4. Database responds with updated list of available channels (where the > updated list is based on information the device provided in step 3). >=20 > That's a bit of a strange way to look at it, though. >=20 >> It is data exchanged between the device and the database and It >> doesn't significantly alter the design of the protocol, and >> specifically doesn't tread into areas of concern when the charter was >> written. We didn't have the benefit of the OFCOM rules at the time, >> or we could have explicitly included it. >>=20 >> Again, if the whitespace returned somehow depended on this >> information, then I think we would be out of scope. >=20 > But doesn't it? Or is this reporting purely informational? >=20 >> I defer to your decision, of course. >=20 > I am not a special person to whom one must defer. I'm just a member of > the community who happens to be serving in the AD role for a few years. >=20 > Peter >=20 > -- > Peter Saint-Andre > https://stpeter.im/ From nbravin@earthlink.net Wed Mar 7 19:18:24 2012 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 8C97721E8029 for ; Wed, 7 Mar 2012 19:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.673 X-Spam-Level: X-Spam-Status: No, score=-0.673 tagged_above=-999 required=5 tests=[AWL=-0.701, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, 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 bYrG63nNvJUF for ; Wed, 7 Mar 2012 19:18:23 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 1613B21E800F for ; Wed, 7 Mar 2012 19:18:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=GM6ootxZcMnXH02HJwbcMnSde5BQDJdfUjgTUMck2KT9p2LB7a/6pOtBXGo48ldU; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [98.150.41.129] (helo=[10.0.1.2]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1S5TrN-0000ED-Rn; Wed, 07 Mar 2012 22:17:46 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Nancy Bravin In-Reply-To: <4F58004B.5000201@stpeter.im> Date: Wed, 7 Mar 2012 19:17:43 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6BFE7C73-CCC4-4C96-9B44-1540012A29A5@earthlink.net> References: <4F5643A8.7000706@joelhalpern.com> <619CDADDCCD2B44380834BE8BF6F71414069146126@EMV62-UKRD.domain1.systemhost.net> <4F58004B.5000201@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad86ffc83ff4190851c86aa8f0a677889b44350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.150.41.129 Cc: paws@ietf.org, johnny.dixon@bt.com, chris.cheeseman@bt.com, Pete Resnick Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 03:18:24 -0000 Peter and all,=20 I agree that it is important to revisit now, so that in the future, it = will be easy to align things in their proper place. Every country may = have different regulations, spectrum, policy and what responsibility is in the domain of the system, and what comes = under the PAWS charter is important. Maybe some separation might be possible, and dividing and clarifying issues now will help in the = future. Certainly it seems that the FCC may change some rules, and we know that Ofcom is not yet finished with their regulations. Canada has = their own, and other countries are working on this as well. Just a thought=85Sharing is a realistic goal=85as is off loading... Or you slim line and every 6 months decide what to incorporate in the = protocol based on new information, new ideas, new innovation new = regulations and maybe spend more time than you could if addressed now.=20 That way you leave the door open and outside of referencing what is = known today, by referencing regulations i.e. Ofcom, FCC, Industry Canada = etc as of XX-XX-XXXX date. Out of scope not something we know enough about to say at this point, In = my opinion. My 2 cents.. =20 Sincerely, Nancy On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote: > >=20 > As your responsible Area Director (until March 28, when Pete Resnick > will take over from me), I have reviewed this thread. >=20 > In my opinion (I am happy to be proven wrong), this new requirement = goes > beyond what the charter defined as the scope of this working group, > which was to enable a device to discover the white space available to = it > in its current location. Reporting usage back to the database is = simply > not mentioned in the charter. >=20 > Earlier in this thread, Andy Sago wrote: >=20 > There's no language I can find in the charter that explicitly puts > this out of scope. >=20 > An IETF charter defines what the working group shall work on. Many > interesting features could be developed here. However, it is not the = job > of the charter to mention explicitly that each of those interesting > features is out of scope. >=20 > The charter does say: >=20 > Once the device learns of the available white space (e.g., in a TV > white space implementation, the list of available channels at that > location), it can then select one of the bands from the list and > begin to transmit and receive on the selected band. >=20 > This text might have assumed that no further communication or > authorization was required in order to select one of the bands from = the > list and then transmit/receive. Perhaps that assumption was mistaken. = If > so, it would be good to have a discussion about that, so we can > determine if we need to revisit the assumptions we made early on. If = in > fact we made some faulty or limited assumptions, then let's get that = out > in the open. >=20 > Peter >=20 > On 3/7/12 9:40 AM, Rosen, Brian wrote: >> >> I'd also suggest that our charter limitation is really support for = sharing of whitespace by whitespace devices. Reporting what you use is = not sharing, it's just data gathering. >>=20 >> The point of excluding sharing was to eliminate the complexities of = what constituted fairness, and what kinds of communication might be = needed between databases, where more than one could supply available = whitespace in a band. This doesn't have any of those issues, >> As long as it's just sending information, I don't have a problem. = Once the database is supposed to do anything with it that involves = changing what spectrum it reports, then I think we cross the line. >>=20 >> Brian >>=20 >> On Mar 6, 2012, at 12:28 PM, = wrote: >>=20 >>> Joel >>>=20 >>> Indeed, the regulator has not described the process or provided a = flow diagram, so there may be some wrinkles, but we need to provide for = their intent. To answer your question, the channels that the master will = use are sent in a separate message (described in P.12 ter), that occurs = after the master receives the response to its channel request, but = before the master can transmit. At this point, it knows what channels = are available, and which one it will use. As far as the slaves are = concerned, as they associate, the master will need to gather their = details and send further channel usage messages to the database on their = behalf. >>>=20 >>> Regards >>>=20 >>> Andy >>>=20 >>> -----Original Message----- >>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of Joel M. Halpern >>> Sent: 06 March 2012 17:05 >>> To: scott.probasco@nokia.com >>> Cc: paws@ietf.org; Cheeseman,CJ,Chris,COD R; Dixon,JS,Johnny,COD R >>> Subject: Re: [paws] WGLC for = draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting >>>=20 >>> Ahh. I think I see where the request and my understanding divurge. >>> If the idea here is that the master must provide, in the request, an = indication of what channels it expects to use, I can at least understand = that. I will return to technical concerns in a moment. >>>=20 >>> However, when you say "provide channel usage information, in order = to evaluate interference", what that says to me is providing, during = operation, information as to what channels are being used, and at what = power levels. That is what would be needed to analyze actual = interference effects. >>> And that is out of scope as I understand our scope. >>>=20 >>> I do see a technical difficulty with having the master provide, as = part of either registering or requesting spectrum information, what = channels it intends to use. It doesn;t know what channels it intends to = use. It intends to use some number of available channels. It will = figure out which ones when it is told what is available. How can it = send that information in the request? >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: >>>> Hi, >>>>=20 >>>> There is a similarity here with device ID. In context of PAWS we = are >>>> not concerned with why a device ID is required by a regulator, we >>>> accept it is a requirement from a regulator and include it to the >>>> protocol. Ofcom identifies in 3.18& 3.19 that channel usage >>>> information is required and thus we need to include this = information. >>>> Since the master must provide this information prior to = transmitting, >>>> PAWS will not function in the UK without this information and thus = I >>>> believe channel usage information is integral to the channel = request& response messaging. >>>>=20 >>>> Kind Regards, >>>> Scott >>>>=20 >>>>=20 >>>> On 3/6/12 10:30 AM, "ext Joel M. Halpern" = wrote: >>>>=20 >>>>> I would draw a distinction. Ofcom regulations about whitespace >>>>> requests are very much relevant. >>>>> Ofcom regulations about notification of dynamic behavior (which >>>>> spectrum is being used) are not in scope as I understand the = earlier >>>>> discussions, particularly the chartering discussions. >>>>>=20 >>>>> Yours, >>>>> Joel >>>>>=20 >>>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: >>>>>>=20 >>>>>> The ofcom requirements are very much relevant to the scope of the >>>>>> PAWS WG. >>>>>> The only other regulatory requirements that we have today is the = FCC. >>>>>> Ofcom requirements are a good addition to the set. >>>>>>=20 >>>>>> -Raj >>>>>>=20 >>>>>> On 3/6/12 10:03 AM, "ext andy.sago@bt.com" = wrote: >>>>>>=20 >>>>>>> Hi Joel >>>>>>>=20 >>>>>>> There's no language I can find in the charter that explicitly = puts >>>>>>> this out of scope. On the other hand, the charter says that the >>>>>>> group will "consider input from regulatory entities", and this = is >>>>>>> one of the requirements from Ofcom that they have just = published. >>>>>>> The protocol will be worthless for the UK if it omits some >>>>>>> requirements. >>>>>>>=20 >>>>>>> Regards >>>>>>>=20 >>>>>>> Andy >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>>>>> Sent: 06 March 2012 15:53 >>>>>>> To: Sago,AJ,Andy,COD R >>>>>>> Cc: paws@ietf.org; Gabor.Bajko@nokia.com >>>>>>> Subject: Re: [paws] WGLC for >>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel = reporting >>>>>>>=20 >>>>>>> As I understand, the information you are asking for is = explicitly >>>>>>> out of scope for the working group. >>>>>>> Yours, >>>>>>> Joel >>>>>>>=20 >>>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >>>>>>>> All >>>>>>>>=20 >>>>>>>> Comparing the draft with the Ofcom requirements at >>>>>>>> = http://www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-r >>>>>>>> egul >>>>>>>> atory-requirements-for-white-space-devices-in-the-UHF-TV-band, >>>>>>>> I believe the WG draft is deficient in the area of reporting >>>>>>>> frequencies and powers actually used by masters and slaves = (Ofcom >>>>>>>> requirements 3.18 and 3.19.8). Ofcom intends to collect this = data >>>>>>>> to assesses the impact of aggregate interference into other >>>>>>>> services. It would also provide usage information (frequency in >>>>>>>> use) that would inform the operation of a kill switch = capability. >>>>>>>> I suggest this deficiency can be remedied with the following = changes: >>>>>>>>=20 >>>>>>>> New P requirements (probably best placed following P.12): >>>>>>>>=20 >>>>>>>> P.12bis: The protocol MUST support a channel usage message from >>>>>>>> the slave device to the master device. The channel usage = message >>>>>>>> MUST include parameters as required by local regulatory >>>>>>>> requirement. These parameters MAY include device ID, >>>>>>>> manufacturer's serial number, channel usage and power level = information. >>>>>>>>=20 >>>>>>>> P.12ter: The protocol MUST support a channel usage message from >>>>>>>> the master device to the database. The channel usage message = MUST >>>>>>>> include parameters as required by local regulatory requirement = for >>>>>>>> the master and its associated slaves. These parameters MAY >>>>>>>> include device ID, manufacturer's serial number, channel usage = and >>>>>>>> power level information. >>>>>>>>=20 >>>>>>>> P.12qua: The protocol MUST support a channel usage message >>>>>>>> acknowledgement. >>>>>>>>=20 >>>>>>>> New O requirements (probably best placed following O13): >>>>>>>>=20 >>>>>>>> O.13bis: According to local regulatory policy, after = connecting >>>>>>>> to a master device's radio network a slave device MAY inform = the >>>>>>>> master device of the actual channel usage. The slave MUST = include >>>>>>>> parameters required by local regulatory policy, e.g. device ID, >>>>>>>> manufacturer's serial number, channel usage and power level = information. >>>>>>>>=20 >>>>>>>> O.13ter: According to local regulatory policy, a master device >>>>>>>> MAY inform the database of the actual channel usage of the = master >>>>>>>> and its slaves. The master MUST include parameters required by >>>>>>>> local regulatory policy, e.g. device ID, manufacturer's serial >>>>>>>> number, channel usage and power level information of the master >>>>>>>> and its slaves. >>>>>>>>=20 >>>>>>>> New steps could be introduced into one or more use cases to = cover >>>>>>>> these Ofcom requirements, e.g. new steps 6bis and 9bis in the >>>>>>>> hotspot use case at 4.2.1: >>>>>>>>=20 >>>>>>>> 6bis. Prior to initiating transmission, if required by local >>>>>>>> regulation, the master/AP informs the database of the channel = and >>>>>>>> power level it has chosen. This is repeated for each slave that >>>>>>>> associated with the master. >>>>>>>>=20 >>>>>>>> 9bis. Prior to initiating transmission, if required by local >>>>>>>> regulation, the slave informs the master/AP of the channel and >>>>>>>> power level it has chosen, and the master/AP relays this >>>>>>>> information to the database. >>>>>>>>=20 >>>>>>>> - end of new text - >>>>>>>>=20 >>>>>>>> For information, for those not accessing the url in the first >>>>>>>> paragraph of this email, the full Ofcom requirements leading to >>>>>>>> this new PAWS text are as follows: >>>>>>>>=20 >>>>>>>> 3.18 After receiving instructions from a WSDB in relation to = the >>>>>>>> maximum permitted EIRPs over the DTT channels, and prior to >>>>>>>> initiating transmissions within the UHF TV band, a master WSD = must >>>>>>>> communicate to the WSDB the following information: >>>>>>>>=20 >>>>>>>> 3.18.1 The lower and upper frequency boundaries^13 of the = in-block >>>>>>>> emissions of the master WSD, and those of the in-block = emissions >>>>>>>> of its associated slaves. A lower frequency will be specified = as >>>>>>>> (470 + 8k + >>>>>>>> 0.2n) MHz, with the corresponding upper frequency specified as >>>>>>>> (470 + 8k >>>>>>>> + 0.2m) MHz, where 0 3=8E4 k 3=8E4 39, 0 3=8E4 n 3=8E4 39, 1 = 3=8E4 m 3=8E4 40, and n< m. >>>>>>>>=20 >>>>>>>> 3.18.2 The maximum in-block EIRP spectral densities (in = dBm/(0.2 >>>>>>>> MHz)) that the master WSD, and its associated slaves, actually >>>>>>>> radiate between each reported lower frequency boundary and its >>>>>>>> corresponding upper frequency boundary. >>>>>>>>=20 >>>>>>>> Footnote 13 states: >>>>>>>>=20 >>>>>>>> The use of upper and lower frequency boundaries (defined over a >>>>>>>> 200 kHz >>>>>>>> raster) allows a WSDB to collect more granular information with >>>>>>>> regards to the usage of the frequency resource by narrowband = WSD >>>>>>>> technologies. >>>>>>>> The upper and lower frequencies of a boundary pair do not = straddle >>>>>>>> a DTT channel boundary. Note that a WSD may transmit over >>>>>>>> multiple, non-contiguous, whole DTT channels or fractions of = DTT channels. >>>>>>>>=20 >>>>>>>> 3.19 A master WSD must be able to receive the following >>>>>>>> information^14 from a WSDB: >>>>>>>>=20 >>>>>>>> >>>>>>>>=20 >>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in the context of = 3.18, >>>>>>>> that the reported information on the DTT channels and EIRP >>>>>>>> spectral densities actually used by the master and slave WSDs = were >>>>>>>> received successfully by the WSDB^18 ]. >>>>>>>>=20 >>>>>>>> Footnote 14 states: >>>>>>>>=20 >>>>>>>> 14 While the communication of some of this information from a = WSDB >>>>>>>> to a master WSD is optional, master WSDs must be able to = receive >>>>>>>> and interpret these. >>>>>>>>=20 >>>>>>>> Footnote 18 states: >>>>>>>>=20 >>>>>>>> 18 This forms part of a handshake protocol and may be an area >>>>>>>> where industry could harmonise without the need for an explicit >>>>>>>> requirement in the regulations. >>>>>>>>=20 >>>>>>>> Regards >>>>>>>>=20 >>>>>>>> Andy >>>>>>>>=20 >>>>>>>> *From:*paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On >>>>>>>> Behalf Of *Gabor.Bajko@nokia.com >>>>>>>> *Sent:* 05 March 2012 19:46 >>>>>>>> *To:* paws@ietf.org >>>>>>>> *Subject:* [paws] WGLC for >>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >>>>>>>>=20 >>>>>>>> The authors of the use cases and requirements draft have just >>>>>>>> posted a new version of the draft and indicated that there are = no >>>>>>>> unresolved comments/issues they are aware of. >>>>>>>>=20 >>>>>>>> Therefore, I'd like to initiate a WG Last Call for comments on >>>>>>>> = http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-u >>>>>>>> seca >>>>>>>> ses-rqmts-03.txt >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Please review the draft and send your comments to the list by >>>>>>>> March 20th, 2012. >>>>>>>>=20 >>>>>>>> If you review the draft and have no comments, send a note to = the >>>>>>>> list that the draft is good as it is, we need these notes as = much >>>>>>>> as we need the actual comments. >>>>>>>>=20 >>>>>>>> Thanks, Gabor >>>>>>>>=20 >>>>>>>>=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From gerald.chouinard@sympatico.ca Thu Mar 8 06:41:08 2012 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 216E021F8628 for ; Thu, 8 Mar 2012 06:41:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.295 X-Spam-Level: X-Spam-Status: No, score=-0.295 tagged_above=-999 required=5 tests=[AWL=1.273, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803, 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 Sucg2EpES523 for ; Thu, 8 Mar 2012 06:41:02 -0800 (PST) Received: from blu0-omc3-s33.blu0.hotmail.com (blu0-omc3-s33.blu0.hotmail.com [65.55.116.108]) by ietfa.amsl.com (Postfix) with ESMTP id B850421F860B for ; Thu, 8 Mar 2012 06:41:01 -0800 (PST) Received: from BLU0-SMTP52 ([65.55.116.73]) by blu0-omc3-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 06:41:00 -0800 X-Originating-IP: [174.95.243.14] X-Originating-Email: [gerald.chouinard@sympatico.ca] Message-ID: Received: from Gerald2 ([174.95.243.14]) by BLU0-SMTP52.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 06:40:59 -0800 From: Gerald Chouinard To: References: <66361BFB30EEF84D8D64DC9FB5C2ADE222E2A385@nasanexd02a.na.qualcomm.com> Date: Thu, 8 Mar 2012 09:40:59 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_015C_01CCFD0F.92AD27E0" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <66361BFB30EEF84D8D64DC9FB5C2ADE222E2A385@nasanexd02a.na.qualcomm.com> Thread-Index: Acz8wBBlg4+pa03QTXiFs3QuD9yPOAAd6QHA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 08 Mar 2012 14:41:00.0107 (UTC) FILETIME=[7ABCF9B0:01CCFD39] Subject: Re: [paws] WGLC fordraft-ietf-paws-problem-stmt-usecases-rqmts-03: protocol details X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 14:41:08 -0000 ------=_NextPart_000_015C_01CCFD0F.92AD27E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, I support Horn's proposal. I don't think that the PAWS needs to get involved into the air interface between the master device and its slaves. This is to be covered by the technology standards and many implementations may exist. As long as the information that the master device needs to provide to the database is present at the master and that the master has a way to make the slave device follow the instructions sent back from the base station (and 'possibly' that the master device has the information regarding the spectrum used by its associated slave devices, all this information can be exchanged between the master device and the database using this PAWS protocol. The way this information is obtained by the master from its associated slave devices is, in my view, outside the scope of PAWS. One thing has to be clarified, however. There is not direct relationship between what is a 'slave device' and a 'Mode I' device as defined in the FCC R&O. A slave device is a device that has its RF parameters (e.g., frequency, EIRP) controlled by a master device. This slave device could be portable, fixed, etc. It is assumed that the master device is responsible for the spectrum footprint used by the slave device and act on its behalf in contacting the database. Gerald _____ From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Horn, Gavin Sent: Wednesday, 07 March, 2012 19:13 To: Don Joslyn; Zuniga, Juan Carlos; paws@ietf.org; Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC fordraft-ietf-paws-problem-stmt-usecases-rqmts-03: protocol details Hi all, Some comments on the requirements with respect to the scope of the document The following requirements seem unrelated to the master and database interface and can probably be deleted - P.13: The protocol MUST support a channel query request from the slave device to the master device. The channel query request message MUST include parameters as required by local regulatory requirement. These parameters MAY include device ID and slave device location. - P.16: The protocol MUST support a channel query response from the master device to the slave device. The channel query response message MUST include parameters as required by local regulatory requirement, including a response code and sufficient information to decode an enabling signal. - P.17: The protocol MUST support an enabling signal sent from the master to the slave. This signal MUST allow the slave device to validate that a previously received available channel list is still valid or not. This signal MUST be encoded to allow the slave device to determine the identity if the sending master device. - O.13: After the master device has received a response from the database, the master device MUST respond to the slave device. If all regulatory requirements are met the response will contain an available channel list. If regulatory requirements are not met, the response MUST contain at least a response code. - O.14: If a master device has provided an available channel list to a slave device the master device MAY send a periodic enabling signal to allow the slave device to confirm it is still within reception range of the master device. - O.15: The enabling signal MUST be encoded so that the receiving slave can determine the identity of the sending master. - O.16: Periodically, at an interval according to local regulations, the slave device MUST either receive and enabling signal or MUST successfully repeat the channel request process or MUST cease transmission on the channel. - O.19: If slave devices change their location during operation by more than a limit specified by the local regulator, the slave device MUST query the master device for available operating channels. P.14 already covers the forwarding of information received in P.13 from the slave, so it is not clear why P.13 is needed. The concept of an enabling signal in P.16, P.17, O.14, O.15 and O.16 is air interface specific between the master and slave. Similarly O.13 contains details of masters response to the slave. For O.19, the requirement is subject to local regulation but is also probably not needed for the PAWS work either since it is related to the master and slave only. P.11 and P.19 are very similar and should probably be merged Regards Gavin From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Don Joslyn Sent: Wednesday, March 07, 2012 1:41 PM To: Zuniga, Juan Carlos; paws@ietf.org; Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: protocol details Re: - P.14/P.15 state that the protocol must support a "validation request from the master to the database to validate a slave device". Is this a master relaying a request to the WSDB on behalf of a slave? It is not clear what validation means. It would be good to provide some more explanatory text. In the context of FCC certified databases and devices, Fixed or Mode II TVBD (master devices) must verify that the FCC identifier (FCC ID) of the Mode I device (slave) is valid before sending a channel list to the slave. In other words, before a master device sends a channel list to a slave device, the master device must send a verification request message to the database to validate the slave's reported FCC ID. The master may only send a channel list to the slave device after the database has validated the FCC ID by sending a success in the reply to a verification request message. Don From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Zuniga, Juan Carlos Sent: Tuesday, March 06, 2012 6:18 PM To: paws@ietf.org; Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: protocol details Hi all, I have taken a look at the Ofcom requirements reference on the CEPT site and besides the points raised by Andy I believe the following protocol requirements should also be addressed in the PAWS requirements doc: - Ofcom 3.11 A master WSD must communicate its technology identifier to a WSDB - This is needed to identify the type of RAT being used, beyond the antenna, power and channel characteristics. Having said that, we had some issues in IEEE 802.21 where we were playing a horse race with the constantly evolving 802.11, 3GPP, etc PHY technologies, so perhaps another approach could be to specify directly the modulation, medium access method, etc. instead of the actual RAT ID. We don't need to define the actual solution now, as long as the requirement allows it in the future. Suggested text: o D.5: The Data Model MUST support specifying an ID of the transmitter device. This ID would contain the ID of the transmitter device that has been certified by a regulatory body for its regulatory domain. The Data Model MUST support a device class. The Data Model MUST support specifying information about the type of RAT of the transmitter device. - Ofcom 3.15 A master WSD must communicate to a WSDB whether it, and its associated slave WSDs, are fixed devices or portable/mobile devices - Not sure if this is covered by "device class" in D.5. Since Device Class is not defined in the document, I would suggest either defining it as including fixed vs. mobile/portable characteristics, or adding a sentence at the end of D.5 such as "The Data Model MUST support specifying whether the transmitter device is fixed or mobile/portable." - Ofcom 3.16 A fixed master WSD may communicate to a WSDB whether it, and its associated fixed slave WSDs, are indoor devices or outdoor devices - Similar to the previous 3.15 requirement. I would suggest either adding a definition for Device Class including indoor or outdoor characteristics, or adding a sentence in D.5 like "The Data Model MAY support specifying whether the transmitter is an outdoor or indoor device." Also, I believe we need to add some clarification on the following: - P.14/P.15 state that the protocol must support a "validation request from the master to the database to validate a slave device". Is this a master relaying a request to the WSDB on behalf of a slave? It is not clear what validation means. It would be good to provide some more explanatory text. - Now that the CEPT version of the Ofcom requirements is publicly available we should add a reference to the document in Section 3.3 "Background information on white space in the UK." Regards, Juan Carlos From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com Sent: Monday, March 05, 2012 2:46 PM To: paws@ietf.org Subject: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03 The authors of the use cases and requirements draft have just posted a new version of the draft and indicated that there are no unresolved comments/issues they are aware of. Therefore, I'd like to initiate a WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rq mts-03.txt Please review the draft and send your comments to the list by March 20th, 2012. If you review the draft and have no comments, send a note to the list that the draft is good as it is, we need these notes as much as we need the actual comments. Thanks, Gabor ------=_NextPart_000_015C_01CCFD0F.92AD27E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

I support Horn’s proposal. I = don’t think that the PAWS needs to get involved into the air interface between = the master device and its slaves.  This is to be covered by the = technology standards and many implementations may exist.  As long as the = information that the master device needs to provide to the database is present at = the master and that the master has a way to make the slave device follow the = instructions sent back from the base station (and ‘possibly’ that the = master device has the information regarding the spectrum used by its associated = slave devices, all this information can be exchanged between the master device = and the database using this PAWS protocol.  The way this information is obtained by the master from its associated slave devices is, in my view, outside the scope of PAWS.

 

One thing has to be clarified, = however. There is not direct relationship between what is a ‘slave = device’ and a ‘Mode I’ device as defined in the FCC R&O. A slave = device is a device that has its RF parameters (e.g., frequency, EIRP) = controlled by a master device. This slave device could be portable, fixed, etc. It is = assumed that the master device is responsible for the spectrum footprint used by = the slave device and act on its behalf in contacting the = database.

 

Gerald

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Horn, Gavin
Sent: Wednesday, 07 = March, 2012 19:13
To: Don Joslyn; Zuniga, = Juan Carlos; paws@ietf.org; Gabor.Bajko@nokia.com
Subject: Re: [paws] WGLC fordraft-ietf-paws-problem-stmt-usecases-rqmts-03: protocol = details

 

Hi all,

 

Some comments on the requirements with respect to the scope of the = document

 

The following requirements seem unrelated to the master and database = interface and can probably be deleted

 

-          P.13:  The = protocol MUST support a channel query request from the slave device to the master device.  The channel query request message MUST include parameters = as required by local regulatory requirement.  These parameters MAY = include device ID and slave device location.

 

-           =
;      =
P.16:  The protocol =
MUST support a channel query response from the master device to the =
slave device.  The channel query response message MUST include =
parameters as required by local regulatory requirement, including a =
response code and sufficient information to decode an enabling =
signal.
 
-           =
;      =
P.17:  The protocol =
MUST support an enabling signal sent from the master to the slave.  =
This signal MUST allow the slave device to validate that a previously =
received available channel list is still valid or not.  This signal =
MUST be encoded to allow the slave device to determine the identity if =
the sending master device.
 

 

-           =
;      =
O.13:  After the =
master device has received a response from the database, the master =
device MUST respond to the slave device.  If all regulatory =
requirements are met the response will contain an available channel =
list.  If regulatory requirements are not met, the response MUST =
contain at least a response code.
 
-           =
;      =
O.14:  If a master =
device has provided an available channel list to a slave device the =
master device MAY send a periodic enabling signal to allow the slave =
device to confirm it is still within reception range of the master =
device.
 
-           =
;      =
O.15:  The enabling =
signal MUST be encoded so that the receiving slave can determine the =
identity of the sending master.
 
-           =
;      =
O.16:  Periodically, =
at an interval according to local regulations, the slave device MUST =
either receive and enabling signal or MUST successfully repeat the =
channel request process or MUST cease transmission on the =
channel.
 

 

-           =
;      =
O.19:  If slave =
devices change their location during operation by more than a limit =
specified by the local regulator, the slave device MUST query the master =
device for available operating channels.
 

P.14 already covers the forwarding of information received in P.13 from the = slave, so it is not clear why P.13 is needed.

 

The concept of an enabling signal in P.16, P.17, O.14, O.15 and O.16 is air interface specific between the master and slave. Similarly O.13 contains details of masters response to the slave. For O.19, the requirement is = subject to local regulation but is also probably not needed for the PAWS work = either since it is related to the master and slave = only.

 

P.11 and P.19 are very similar and should probably be = merged

 

Regards

Gavin

 <= /p>

 <= /p>

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Don Joslyn
Sent: Wednesday, March = 07, 2012 1:41 PM
To: Zuniga, Juan Carlos; paws@ietf.org; Gabor.Bajko@nokia.com
Subject: Re: [paws] WGLC = for draft-ietf-paws-problem-stmt-usecases-rqmts-03: protocol = details

 

Re: =

-          P.14/P.15 state that the protocol must support a “validation request from the master to the database to validate a = slave device”. Is this a master relaying a request to the WSDB on behalf = of a slave? It is not clear what validation means. It would be good to = provide some more explanatory text.

 <= /p>

In the context of FCC certified databases and devices, Fixed or Mode II TVBD (master devices) must = verify that the FCC identifier (FCC ID) of the Mode I device (slave) is valid before sending a channel list to the slave.

 <= /p>

In other words, before a master = device sends a channel list to a slave device, the master device must send a verification request message to the database to validate the = slave’s reported FCC ID. The master may only send a channel list to the slave = device after the database has validated the FCC ID by sending a success in the = reply to a verification request message.

 <= /p>

Don

=

 <= /p>

From: = paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On = Behalf Of Zuniga, Juan Carlos
Sent: Tuesday, March 06, = 2012 6:18 PM
To: paws@ietf.org; Gabor.Bajko@nokia.com
Subject: Re: [paws] WGLC = for draft-ietf-paws-problem-stmt-usecases-rqmts-03: protocol = details

 

Hi = all,

 <= /p>

I have taken a look at the = Ofcom requirements reference on the CEPT site and besides the points raised by = Andy I believe the following protocol requirements should also be addressed in = the PAWS requirements doc:

 <= /p>

-          Ofcom 3.11 A master WSD must communicate its = technology identifier to a WSDB – This is needed to identify the type of RAT = being used, beyond the antenna, power and channel characteristics. Having said = that, we had some issues in IEEE 802.21 where we were playing a horse race = with the constantly evolving 802.11, 3GPP, etc PHY technologies, so perhaps another approach = could be to specify directly the modulation, medium access method, etc. = instead of the actual RAT ID. We don’t need to define the actual solution = now, as long as the requirement allows it in the future. Suggested = text:

o        D.5:   The Data Model MUST support = specifying an ID of the transmitter device.  This ID would contain the ID of = the transmitter device that has been certified by a regulatory body for its regulatory domain.  The Data Model MUST support a device class. <Insert> The Data Model MUST support specifying information about = the type of RAT of the transmitter = device.</Insert>

 <= /p>

-          Ofcom 3.15    A master WSD must communicate to a WSDB whether it, and its associated slave WSDs, are = fixed devices or portable/mobile devices – Not sure if this is covered = by “device class” in D.5. Since Device Class is not defined in = the document, I would suggest either defining it as including fixed vs. mobile/portable characteristics, or adding a sentence at the end of D.5 = such as “The Data Model MUST support specifying whether the transmitter = device is fixed or mobile/portable.”

 <= /p>

-          Ofcom 3.16    A fixed master WSD = may communicate to a WSDB whether it, and its associated fixed slave WSDs, = are indoor devices or outdoor devices – Similar to the previous 3.15 requirement. I would suggest either adding a definition for Device Class including indoor or outdoor characteristics, or adding a sentence in D.5 = like “The Data Model MAY support specifying whether the transmitter is = an outdoor or indoor device.”

 <= /p>

Also, I believe we need to add = some clarification on the following:

 <= /p>

-          P.14/P.15 state that the protocol must support a “validation request from the master to the database to validate a = slave device”. Is this a master relaying a request to the WSDB on behalf = of a slave? It is not clear what validation means. It would be good to = provide some more explanatory text.

 <= /p>

-          Now that the CEPT version of the Ofcom = requirements is publicly available we should add a reference to the document in Section = 3.3 “Background information on white space in the UK.”=

 <= /p>

Regards,

 <= /p>

Juan Carlos =

 <= /p>

From: paws-bounces@ietf.org [mailto:paws-bounces@i= etf.org] On Behalf Of Gabor.Bajko@nokia.com
Sent: Monday, March 05, = 2012 2:46 PM
To: paws@ietf.org
Subject: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03

 

The authors of the use cases and requirements draft have just posted a new = version of the draft and indicated that there are no unresolved comments/issues = they are aware of.

 

Therefore, I'd like to initiate a = WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paw= s-problem-stmt-usecases-rqmts-03.txt

 

Please review the draft and send = your comments to the list by March 20th, 2012.

 

If you review the draft and have = no comments, send a note to the list that the draft is good as it is, we = need these notes as much as we need the actual = comments.

 

Thanks, = Gabor

 

------=_NextPart_000_015C_01CCFD0F.92AD27E0-- From JuanCarlos.Zuniga@InterDigital.com Thu Mar 8 07:57:40 2012 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 A8F1A21F8533 for ; Thu, 8 Mar 2012 07:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 84rlE9DAgoTX for ; Thu, 8 Mar 2012 07:57:37 -0800 (PST) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id A1A6821F852B for ; Thu, 8 Mar 2012 07:57:28 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 10:57:27 -0500 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_01CCFD44.290A87A7" Date: Thu, 8 Mar 2012 10:57:26 -0500 Message-ID: In-Reply-To: <8375F6DAEFB09F48815203F1FE23B797113CB4E784@shelby> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:protocol details Thread-Index: Acz7CHkh/FNx3kOiQQWaHcNbcyzaWwAsH3rwADxBwxAAJoj2sA== References: <1ECAFF543A2FED4EA2BEB6CACE08E47601E1A52E@008-AM1MPN1-006.mgdnok.nokia.com> <8375F6DAEFB09F48815203F1FE23B797113CB4E784@shelby> From: "Zuniga, Juan Carlos" To: "Don Joslyn" , , X-OriginalArrivalTime: 08 Mar 2012 15:57:27.0433 (UTC) FILETIME=[28FF5F90:01CCFD44] Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:protocol details X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 15:57:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFD44.290A87A7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Don, =20 Thanks for the explanation. After reading it the text makes sense. However, I still believe the explanation should be included in the text to make it clearer. Perhaps the explanation you provide in the last paragraph can be added in point 8 of Use Case 4.2.2 Wide-Area or Rural Internet broadband access, stating something like "In some regulatory domains, before a master device sends a channel list..." =20 JC =20 =20 From: Don Joslyn [mailto:d.joslyn@spectrumbridge.com]=20 Sent: Wednesday, March 07, 2012 4:41 PM To: Zuniga, Juan Carlos; paws@ietf.org; Gabor.Bajko@nokia.com Subject: RE: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:protocol details =20 Re:=20 - P.14/P.15 state that the protocol must support a "validation request from the master to the database to validate a slave device". Is this a master relaying a request to the WSDB on behalf of a slave? It is not clear what validation means. It would be good to provide some more explanatory text. =20 In the context of FCC certified databases and devices, Fixed or Mode II TVBD (master devices) must verify that the FCC identifier (FCC ID) of the Mode I device (slave) is valid before sending a channel list to the slave. =20 In other words, before a master device sends a channel list to a slave device, the master device must send a verification request message to the database to validate the slave's reported FCC ID. The master may only send a channel list to the slave device after the database has validated the FCC ID by sending a success in the reply to a verification request message. =20 Don =20 From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Zuniga, Juan Carlos Sent: Tuesday, March 06, 2012 6:18 PM To: paws@ietf.org; Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: protocol details =20 Hi all, =20 I have taken a look at the Ofcom requirements reference on the CEPT site and besides the points raised by Andy I believe the following protocol requirements should also be addressed in the PAWS requirements doc: =20 - Ofcom 3.11 A master WSD must communicate its technology identifier to a WSDB - This is needed to identify the type of RAT being used, beyond the antenna, power and channel characteristics. Having said that, we had some issues in IEEE 802.21 where we were playing a horse race with the constantly evolving 802.11, 3GPP, etc PHY technologies, so perhaps another approach could be to specify directly the modulation, medium access method, etc. instead of the actual RAT ID. We don't need to define the actual solution now, as long as the requirement allows it in the future. Suggested text: o D.5: The Data Model MUST support specifying an ID of the transmitter device. This ID would contain the ID of the transmitter device that has been certified by a regulatory body for its regulatory domain. The Data Model MUST support a device class. The Data Model MUST support specifying information about the type of RAT of the transmitter device. =20 - Ofcom 3.15 A master WSD must communicate to a WSDB whether it, and its associated slave WSDs, are fixed devices or portable/mobile devices - Not sure if this is covered by "device class" in D.5. Since Device Class is not defined in the document, I would suggest either defining it as including fixed vs. mobile/portable characteristics, or adding a sentence at the end of D.5 such as "The Data Model MUST support specifying whether the transmitter device is fixed or mobile/portable." =20 - Ofcom 3.16 A fixed master WSD may communicate to a WSDB whether it, and its associated fixed slave WSDs, are indoor devices or outdoor devices - Similar to the previous 3.15 requirement. I would suggest either adding a definition for Device Class including indoor or outdoor characteristics, or adding a sentence in D.5 like "The Data Model MAY support specifying whether the transmitter is an outdoor or indoor device." =20 Also, I believe we need to add some clarification on the following: =20 - P.14/P.15 state that the protocol must support a "validation request from the master to the database to validate a slave device". Is this a master relaying a request to the WSDB on behalf of a slave? It is not clear what validation means. It would be good to provide some more explanatory text. =20 - Now that the CEPT version of the Ofcom requirements is publicly available we should add a reference to the document in Section 3.3 "Background information on white space in the UK." =20 Regards, =20 Juan Carlos=20 =20 From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com Sent: Monday, March 05, 2012 2:46 PM To: paws@ietf.org Subject: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03 =20 The authors of the use cases and requirements draft have just posted a new version of the draft and indicated that there are no unresolved comments/issues they are aware of. =20 Therefore, I'd like to initiate a WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecase s-rqmts-03.txt=20 =20 Please review the draft and send your comments to the list by March 20th, 2012. =20 If you review the draft and have no comments, send a note to the list that the draft is good as it is, we need these notes as much as we need the actual comments. =20 Thanks, Gabor =20 ------_=_NextPart_001_01CCFD44.290A87A7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Don,

 

Thanks for the = explanation. After reading it the text makes sense. However, I still = believe the explanation should be included in the text to make it = clearer. Perhaps the explanation you provide in the last paragraph can = be added in point 8 of Use Case 4.2.2 Wide-Area or Rural Internet = broadband access, stating something like “In some regulatory = domains, before a master device sends a channel = list…”

 

JC

 

 

From:= = Don Joslyn [mailto:d.joslyn@spectrumbridge.com]
Sent: = Wednesday, March 07, 2012 4:41 PM
To: Zuniga, Juan Carlos; = paws@ietf.org; Gabor.Bajko@nokia.com
Subject: RE: [paws] WGLC = for draft-ietf-paws-problem-stmt-usecases-rqmts-03:protocol = details

 

Re:

-          = P.14/P.15 = state that the protocol must support a “validation request from = the master to the database to validate a slave device”. Is this a = master relaying a request to the WSDB on behalf of a slave? It is not = clear what validation means. It would be good to provide some more = explanatory text.

 

In the context of FCC = certified databases and devices, Fixed or Mode II TVBD (master devices) = must verify that the FCC identifier (FCC ID) of the Mode I device = (slave) is valid before sending a channel list to the = slave.

 

In other words, before a = master device sends a channel list to a slave device, the master device = must send a verification request message to the database to validate the = slave’s reported FCC ID. The master may only send a channel list = to the slave device after the database has validated the FCC ID by = sending a success in the reply to a verification request = message.

 

Don

 

From:= = paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of = Zuniga, Juan Carlos
Sent: Tuesday, March 06, 2012 6:18 = PM
To: paws@ietf.org; Gabor.Bajko@nokia.com
Subject: = Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: = protocol details

 

Hi all,

 

I have taken a look at = the Ofcom requirements reference on the CEPT site and besides the points = raised by Andy I believe the following protocol requirements should also = be addressed in the PAWS requirements doc:

 

-          = Ofcom 3.11 = A master WSD must communicate its technology identifier to a WSDB = – This is needed to identify the type of RAT being used, beyond = the antenna, power and channel characteristics. Having said that, we had = some issues in IEEE 802.21 where we were playing a horse race with the = constantly evolving 802.11, 3GPP, etc PHY technologies, so perhaps = another approach could be to specify directly the modulation, medium = access method, etc. instead of the actual RAT ID. We don’t need to = define the actual solution now, as long as the requirement allows it in = the future. Suggested text:

o   = D.5:   The Data Model MUST support = specifying an ID of the transmitter device.  This ID would contain = the ID of the transmitter device that has been certified by a regulatory = body for its regulatory domain.  The Data Model MUST support a = device class. <Insert> The Data Model MUST support specifying = information about the type of RAT of the transmitter = device.</Insert>

 

-          = Ofcom = 3.15    A master WSD must communicate to a WSDB whether = it, and its associated slave WSDs, are fixed devices or portable/mobile = devices – Not sure if this is covered by “device = class” in D.5. Since Device Class is not defined in the document, = I would suggest either defining it as including fixed vs. = mobile/portable characteristics, or adding a sentence at the end of D.5 = such as “The Data Model MUST support specifying whether the = transmitter device is fixed or = mobile/portable.”

 

-          = Ofcom = 3.16    A fixed master WSD may communicate to a WSDB = whether it, and its associated fixed slave WSDs, are indoor devices or = outdoor devices – Similar to the previous 3.15 requirement. I = would suggest either adding a definition for Device Class including = indoor or outdoor characteristics, or adding a sentence in D.5 like = “The Data Model MAY support specifying whether the transmitter is = an outdoor or indoor device.”

 

Also, I believe we need = to add some clarification on the following:

 

-          = P.14/P.15 = state that the protocol must support a “validation request from = the master to the database to validate a slave device”. Is this a = master relaying a request to the WSDB on behalf of a slave? It is not = clear what validation means. It would be good to provide some more = explanatory text.

 

-          = Now that = the CEPT version of the Ofcom requirements is publicly available we = should add a reference to the document in Section 3.3 “Background = information on white space in the UK.”

 

Regards,

 

Juan Carlos =

 

From:= = paws-bounces@ietf.org [mailto:paws-bounces@ietf.= org] On Behalf Of Gabor.Bajko@nokia.com
Sen= t: Monday, March 05, 2012 2:46 PM
To: paws@ietf.org
Subject: = [paws] WGLC for = draft-ietf-paws-problem-stmt-usecases-rqmts-03

 

The authors of the use cases and requirements draft = have just posted a new version of the draft and indicated that there are = no unresolved comments/issues they are aware of.

 

Therefore, I'd like to = initiate a WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paw= s-problem-stmt-usecases-rqmts-03.txt

 

Please review the draft = and send your comments to the list by March 20th, = 2012.

 

If you review the draft = and have no comments, send a note to the list that the draft is good as = it is, we need these notes as much as we need the actual = comments.

 

Thanks, = Gabor

 

------_=_NextPart_001_01CCFD44.290A87A7-- From stpeter@stpeter.im Thu Mar 8 08:59:14 2012 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 181F621F8659 for ; Thu, 8 Mar 2012 08:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.458 X-Spam-Level: X-Spam-Status: No, score=-101.458 tagged_above=-999 required=5 tests=[AWL=-1.486, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, 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 BuWBI2Ij53RJ for ; Thu, 8 Mar 2012 08:59:12 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B2A7F21F8649 for ; Thu, 8 Mar 2012 08:59:12 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A313340058; Thu, 8 Mar 2012 10:11:14 -0700 (MST) Message-ID: <4F58E552.4060608@stpeter.im> Date: Thu, 08 Mar 2012 09:58:58 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Nancy Bravin References: <4F5643A8.7000706@joelhalpern.com> <619CDADDCCD2B44380834BE8BF6F71414069146126@EMV62-UKRD.domain1.systemhost.net> <4F58004B.5000201@stpeter.im> <6BFE7C73-CCC4-4C96-9B44-1540012A29A5@earthlink.net> In-Reply-To: <6BFE7C73-CCC4-4C96-9B44-1540012A29A5@earthlink.net> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: paws@ietf.org, johnny.dixon@bt.com, chris.cheeseman@bt.com, Pete Resnick Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 16:59:14 -0000 Hi Nancy, You are absolutely right that different locales will have different rules and requirements. We need to understand those, and work to address them if possible (although we don't necessarily need to address them all at the same time). I see several kinds of requirements: 1. Some requirements might lead to features beyond the query/response protocol we've envisioned so far. One example might be real-time reporting about the channels that a device is actually using. In my opinion, it would be best to handle those in the next phase of work, because as far as I can see they are outside the scope of our charter. 2. Some requirements might be handled through by defining additional fields that can be included in the query or response. We definitely planned for that when working on the charter with the IESG: In addition, the particular data exchanged between a device and a database might depend on the ranges of radio spectrum that are to be used, the requirements of the database operators and their governing regulations, and other factors. Therefore, the database access method and the query/response data formats that are exchanged using that method need to be designed for extensibility rather than being tied to any specific spectrum, country, or phy/mac/air interface. It's unclear to me right now if the Ofcom requirement fits into #1 or #2, which is why we're having this discussion. :) Peter On 3/7/12 8:17 PM, Nancy Bravin wrote: > Peter and all, > > I agree that it is important to revisit now, so that in the future, > it will be easy to align things in their proper place. Every country > may have different regulations, spectrum, policy and what > responsibility is in the domain of the system, and what comes under > the PAWS charter is important. Maybe some separation might be > possible, and dividing and clarifying issues now will help in the > future. Certainly it seems that the FCC may change some rules, and > we know that Ofcom is not yet finished with their regulations. Canada > has their own, and other countries are working on this as well. Just > a thought…Sharing is a realistic goal…as is off loading... Or you > slim line and every 6 months decide what to incorporate in the > protocol based on new information, new ideas, new innovation new > regulations and maybe spend more time than you could if addressed > now. > > That way you leave the door open and outside of referencing what is > known today, by referencing regulations i.e. Ofcom, FCC, Industry > Canada etc as of XX-XX-XXXX date. Out of scope not something we know > enough about to say at this point, In my opinion. > > My 2 cents.. > > Sincerely, Nancy > > On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote: > >> >> >> As your responsible Area Director (until March 28, when Pete >> Resnick will take over from me), I have reviewed this thread. >> >> In my opinion (I am happy to be proven wrong), this new requirement >> goes beyond what the charter defined as the scope of this working >> group, which was to enable a device to discover the white space >> available to it in its current location. Reporting usage back to >> the database is simply not mentioned in the charter. >> >> Earlier in this thread, Andy Sago wrote: >> >> There's no language I can find in the charter that explicitly puts >> this out of scope. >> >> An IETF charter defines what the working group shall work on. Many >> interesting features could be developed here. However, it is not >> the job of the charter to mention explicitly that each of those >> interesting features is out of scope. >> >> The charter does say: >> >> Once the device learns of the available white space (e.g., in a TV >> white space implementation, the list of available channels at that >> location), it can then select one of the bands from the list and >> begin to transmit and receive on the selected band. >> >> This text might have assumed that no further communication or >> authorization was required in order to select one of the bands from >> the list and then transmit/receive. Perhaps that assumption was >> mistaken. If so, it would be good to have a discussion about that, >> so we can determine if we need to revisit the assumptions we made >> early on. If in fact we made some faulty or limited assumptions, >> then let's get that out in the open. >> >> Peter >> >> On 3/7/12 9:40 AM, Rosen, Brian wrote: >>> I'd also suggest that our >>> charter limitation is really support for sharing of whitespace by >>> whitespace devices. Reporting what you use is not sharing, it's >>> just data gathering. >>> >>> The point of excluding sharing was to eliminate the complexities >>> of what constituted fairness, and what kinds of communication >>> might be needed between databases, where more than one could >>> supply available whitespace in a band. This doesn't have any of >>> those issues, As long as it's just sending information, I don't >>> have a problem. Once the database is supposed to do anything >>> with it that involves changing what spectrum it reports, then I >>> think we cross the line. >>> >>> Brian >>> >>> On Mar 6, 2012, at 12:28 PM, >>> wrote: >>> >>>> Joel >>>> >>>> Indeed, the regulator has not described the process or provided >>>> a flow diagram, so there may be some wrinkles, but we need to >>>> provide for their intent. To answer your question, the channels >>>> that the master will use are sent in a separate message >>>> (described in P.12 ter), that occurs after the master receives >>>> the response to its channel request, but before the master can >>>> transmit. At this point, it knows what channels are available, >>>> and which one it will use. As far as the slaves are concerned, >>>> as they associate, the master will need to gather their details >>>> and send further channel usage messages to the database on >>>> their behalf. >>>> >>>> Regards >>>> >>>> Andy >>>> >>>> -----Original Message----- From: paws-bounces@ietf.org >>>> [mailto:paws-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>> Sent: 06 March 2012 17:05 To: scott.probasco@nokia.com Cc: >>>> paws@ietf.org; Cheeseman,CJ,Chris,COD R; Dixon,JS,Johnny,COD R >>>> Subject: Re: [paws] WGLC for >>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel >>>> reporting >>>> >>>> Ahh. I think I see where the request and my understanding >>>> divurge. If the idea here is that the master must provide, in >>>> the request, an indication of what channels it expects to use, >>>> I can at least understand that. I will return to technical >>>> concerns in a moment. >>>> >>>> However, when you say "provide channel usage information, in >>>> order to evaluate interference", what that says to me is >>>> providing, during operation, information as to what channels >>>> are being used, and at what power levels. That is what would >>>> be needed to analyze actual interference effects. And that is >>>> out of scope as I understand our scope. >>>> >>>> I do see a technical difficulty with having the master provide, >>>> as part of either registering or requesting spectrum >>>> information, what channels it intends to use. It doesn;t know >>>> what channels it intends to use. It intends to use some number >>>> of available channels. It will figure out which ones when it >>>> is told what is available. How can it send that information in >>>> the request? >>>> >>>> Yours, Joel >>>> >>>> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: >>>>> Hi, >>>>> >>>>> There is a similarity here with device ID. In context of PAWS >>>>> we are not concerned with why a device ID is required by a >>>>> regulator, we accept it is a requirement from a regulator and >>>>> include it to the protocol. Ofcom identifies in 3.18& 3.19 >>>>> that channel usage information is required and thus we need >>>>> to include this information. Since the master must provide >>>>> this information prior to transmitting, PAWS will not >>>>> function in the UK without this information and thus I >>>>> believe channel usage information is integral to the channel >>>>> request& response messaging. >>>>> >>>>> Kind Regards, Scott >>>>> >>>>> >>>>> On 3/6/12 10:30 AM, "ext Joel M. >>>>> Halpern" wrote: >>>>> >>>>>> I would draw a distinction. Ofcom regulations about >>>>>> whitespace requests are very much relevant. Ofcom >>>>>> regulations about notification of dynamic behavior (which >>>>>> spectrum is being used) are not in scope as I understand >>>>>> the earlier discussions, particularly the chartering >>>>>> discussions. >>>>>> >>>>>> Yours, Joel >>>>>> >>>>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: >>>>>>> >>>>>>> The ofcom requirements are very much relevant to the >>>>>>> scope of the PAWS WG. The only other regulatory >>>>>>> requirements that we have today is the FCC. Ofcom >>>>>>> requirements are a good addition to the set. >>>>>>> >>>>>>> -Raj >>>>>>> >>>>>>> On 3/6/12 10:03 AM, "ext >>>>>>> andy.sago@bt.com" wrote: >>>>>>> >>>>>>>> Hi Joel >>>>>>>> >>>>>>>> There's no language I can find in the charter that >>>>>>>> explicitly puts this out of scope. On the other hand, >>>>>>>> the charter says that the group will "consider input >>>>>>>> from regulatory entities", and this is one of the >>>>>>>> requirements from Ofcom that they have just published. >>>>>>>> The protocol will be worthless for the UK if it omits >>>>>>>> some requirements. >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Andy >>>>>>>> >>>>>>>> -----Original Message----- From: Joel M. Halpern >>>>>>>> [mailto:jmh@joelhalpern.com] Sent: 06 March 2012 15:53 >>>>>>>> To: Sago,AJ,Andy,COD R Cc: paws@ietf.org; >>>>>>>> Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for >>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel >>>>>>>> reporting >>>>>>>> >>>>>>>> As I understand, the information you are asking for is >>>>>>>> explicitly out of scope for the working group. Yours, >>>>>>>> Joel >>>>>>>> >>>>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >>>>>>>>> All >>>>>>>>> >>>>>>>>> Comparing the draft with the Ofcom requirements at >>>>>>>>> http://www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-r >>>>>>>>> >>>>>>>>> egul >>>>>>>>> atory-requirements-for-white-space-devices-in-the-UHF-TV-band, >>>>>>>>> >>>>>>>>> I believe the WG draft is deficient in the area of reporting >>>>>>>>> frequencies and powers actually used by masters and >>>>>>>>> slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom >>>>>>>>> intends to collect this data to assesses the impact >>>>>>>>> of aggregate interference into other services. It >>>>>>>>> would also provide usage information (frequency in >>>>>>>>> use) that would inform the operation of a kill switch >>>>>>>>> capability. I suggest this deficiency can be remedied >>>>>>>>> with the following changes: >>>>>>>>> >>>>>>>>> New P requirements (probably best placed following >>>>>>>>> P.12): >>>>>>>>> >>>>>>>>> P.12bis: The protocol MUST support a channel usage >>>>>>>>> message from the slave device to the master device. >>>>>>>>> The channel usage message MUST include parameters as >>>>>>>>> required by local regulatory requirement. These >>>>>>>>> parameters MAY include device ID, manufacturer's >>>>>>>>> serial number, channel usage and power level >>>>>>>>> information. >>>>>>>>> >>>>>>>>> P.12ter: The protocol MUST support a channel usage >>>>>>>>> message from the master device to the database. The >>>>>>>>> channel usage message MUST include parameters as >>>>>>>>> required by local regulatory requirement for the >>>>>>>>> master and its associated slaves. These parameters >>>>>>>>> MAY include device ID, manufacturer's serial number, >>>>>>>>> channel usage and power level information. >>>>>>>>> >>>>>>>>> P.12qua: The protocol MUST support a channel usage >>>>>>>>> message acknowledgement. >>>>>>>>> >>>>>>>>> New O requirements (probably best placed following >>>>>>>>> O13): >>>>>>>>> >>>>>>>>> O.13bis: According to local regulatory policy, after >>>>>>>>> connecting to a master device's radio network a slave >>>>>>>>> device MAY inform the master device of the actual >>>>>>>>> channel usage. The slave MUST include parameters >>>>>>>>> required by local regulatory policy, e.g. device ID, >>>>>>>>> manufacturer's serial number, channel usage and power >>>>>>>>> level information. >>>>>>>>> >>>>>>>>> O.13ter: According to local regulatory policy, a >>>>>>>>> master device MAY inform the database of the actual >>>>>>>>> channel usage of the master and its slaves. The >>>>>>>>> master MUST include parameters required by local >>>>>>>>> regulatory policy, e.g. device ID, manufacturer's >>>>>>>>> serial number, channel usage and power level >>>>>>>>> information of the master and its slaves. >>>>>>>>> >>>>>>>>> New steps could be introduced into one or more use >>>>>>>>> cases to cover these Ofcom requirements, e.g. new >>>>>>>>> steps 6bis and 9bis in the hotspot use case at >>>>>>>>> 4.2.1: >>>>>>>>> >>>>>>>>> 6bis. Prior to initiating transmission, if required >>>>>>>>> by local regulation, the master/AP informs the >>>>>>>>> database of the channel and power level it has >>>>>>>>> chosen. This is repeated for each slave that >>>>>>>>> associated with the master. >>>>>>>>> >>>>>>>>> 9bis. Prior to initiating transmission, if required >>>>>>>>> by local regulation, the slave informs the master/AP >>>>>>>>> of the channel and power level it has chosen, and the >>>>>>>>> master/AP relays this information to the database. >>>>>>>>> >>>>>>>>> - end of new text - >>>>>>>>> >>>>>>>>> For information, for those not accessing the url in >>>>>>>>> the first paragraph of this email, the full Ofcom >>>>>>>>> requirements leading to this new PAWS text are as >>>>>>>>> follows: >>>>>>>>> >>>>>>>>> 3.18 After receiving instructions from a WSDB in >>>>>>>>> relation to the maximum permitted EIRPs over the DTT >>>>>>>>> channels, and prior to initiating transmissions >>>>>>>>> within the UHF TV band, a master WSD must communicate >>>>>>>>> to the WSDB the following information: >>>>>>>>> >>>>>>>>> 3.18.1 The lower and upper frequency boundaries^13 of >>>>>>>>> the in-block emissions of the master WSD, and those >>>>>>>>> of the in-block emissions of its associated slaves. A >>>>>>>>> lower frequency will be specified as (470 + 8k + >>>>>>>>> 0.2n) MHz, with the corresponding upper frequency >>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3Ž4 k 3Ž4 >>>>>>>>> 39, 0 3Ž4 n 3Ž4 39, 1 3Ž4 m 3Ž4 40, and n< m. >>>>>>>>> >>>>>>>>> 3.18.2 The maximum in-block EIRP spectral densities >>>>>>>>> (in dBm/(0.2 MHz)) that the master WSD, and its >>>>>>>>> associated slaves, actually radiate between each >>>>>>>>> reported lower frequency boundary and its >>>>>>>>> corresponding upper frequency boundary. >>>>>>>>> >>>>>>>>> Footnote 13 states: >>>>>>>>> >>>>>>>>> The use of upper and lower frequency boundaries >>>>>>>>> (defined over a 200 kHz raster) allows a WSDB to >>>>>>>>> collect more granular information with regards to the >>>>>>>>> usage of the frequency resource by narrowband WSD >>>>>>>>> technologies. The upper and lower frequencies of a >>>>>>>>> boundary pair do not straddle a DTT channel boundary. >>>>>>>>> Note that a WSD may transmit over multiple, >>>>>>>>> non-contiguous, whole DTT channels or fractions of >>>>>>>>> DTT channels. >>>>>>>>> >>>>>>>>> 3.19 A master WSD must be able to receive the >>>>>>>>> following information^14 from a WSDB: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in the >>>>>>>>> context of 3.18, that the reported information on the >>>>>>>>> DTT channels and EIRP spectral densities actually >>>>>>>>> used by the master and slave WSDs were received >>>>>>>>> successfully by the WSDB^18 ]. >>>>>>>>> >>>>>>>>> Footnote 14 states: >>>>>>>>> >>>>>>>>> 14 While the communication of some of this >>>>>>>>> information from a WSDB to a master WSD is optional, >>>>>>>>> master WSDs must be able to receive and interpret >>>>>>>>> these. >>>>>>>>> >>>>>>>>> Footnote 18 states: >>>>>>>>> >>>>>>>>> 18 This forms part of a handshake protocol and may be >>>>>>>>> an area where industry could harmonise without the >>>>>>>>> need for an explicit requirement in the regulations. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> Andy >>>>>>>>> >>>>>>>>> *From:*paws-bounces@ietf.org >>>>>>>>> [mailto:paws-bounces@ietf.org] *On Behalf Of >>>>>>>>> *Gabor.Bajko@nokia.com *Sent:* 05 March 2012 19:46 >>>>>>>>> *To:* paws@ietf.org *Subject:* [paws] WGLC for >>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >>>>>>>>> >>>>>>>>> The authors of the use cases and requirements draft >>>>>>>>> have just posted a new version of the draft and >>>>>>>>> indicated that there are no unresolved >>>>>>>>> comments/issues they are aware of. >>>>>>>>> >>>>>>>>> Therefore, I'd like to initiate a WG Last Call for >>>>>>>>> comments on >>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-u >>>>>>>>> >>>>>>>>> seca >>>>>>>>> ses-rqmts-03.txt >>>>>>>>> >>>>>>>>> >>>>>>>>> Please review the draft and send your comments to the >>>>>>>>> list by March 20th, 2012. >>>>>>>>> >>>>>>>>> If you review the draft and have no comments, send a >>>>>>>>> note to the list that the draft is good as it is, we >>>>>>>>> need these notes as much as we need the actual >>>>>>>>> comments. >>>>>>>>> >>>>>>>>> Thanks, Gabor >>>>>>>>> >>>>>>>>> From jmh@joelhalpern.com Thu Mar 8 09:07:19 2012 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 61AFC21F85A3 for ; Thu, 8 Mar 2012 09:07:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.81 X-Spam-Level: X-Spam-Status: No, score=-100.81 tagged_above=-999 required=5 tests=[AWL=-1.172, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, 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 2FqvdOIPSg5V for ; Thu, 8 Mar 2012 09:07:18 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 00B1C21F85B1 for ; Thu, 8 Mar 2012 09:07:18 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id E67C7CCFEE for ; Thu, 8 Mar 2012 09:07:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id BDEFB1C085C; Thu, 8 Mar 2012 09:07:17 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.100] (pool-71-161-51-182.clppva.btas.verizon.net [71.161.51.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 98D641C0B67; Thu, 8 Mar 2012 09:07:14 -0800 (PST) Message-ID: <4F58E740.10201@joelhalpern.com> Date: Thu, 08 Mar 2012 12:07:12 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Peter Saint-Andre References: <4F5643A8.7000706@joelhalpern.com> <619CDADDCCD2B44380834BE8BF6F71414069146126@EMV62-UKRD.domain1.systemhost.net> <4F58004B.5000201@stpeter.im> <6BFE7C73-CCC4-4C96-9B44-1540012A29A5@earthlink.net> <4F58E552.4060608@stpeter.im> In-Reply-To: <4F58E552.4060608@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: paws@ietf.org, Pete Resnick , johnny.dixon@bt.com, chris.cheeseman@bt.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 17:07:19 -0000 Unfortunately, given the statements that a) This information is provided in additional messages after the master receives the whitespace data; b) That the master has to update this information if the usage changes; both of which were stated to be part of the meaning of the requirements, it follows that we are in category #1 below. Yours, Joel On 3/8/2012 11:58 AM, Peter Saint-Andre wrote: > Hi Nancy, > > You are absolutely right that different locales will have different > rules and requirements. We need to understand those, and work to address > them if possible (although we don't necessarily need to address them all > at the same time). I see several kinds of requirements: > > 1. Some requirements might lead to features beyond the query/response > protocol we've envisioned so far. One example might be real-time > reporting about the channels that a device is actually using. In my > opinion, it would be best to handle those in the next phase of work, > because as far as I can see they are outside the scope of our charter. > > 2. Some requirements might be handled through by defining additional > fields that can be included in the query or response. We definitely > planned for that when working on the charter with the IESG: > > In addition, the particular > data exchanged between a device and a database might depend on the > ranges of radio spectrum that are to be used, the requirements of the > database operators and their governing regulations, and other factors. > Therefore, the database access method and the query/response data > formats that are exchanged using that method need to be designed for > extensibility rather than being tied to any specific spectrum, > country, or phy/mac/air interface. > > It's unclear to me right now if the Ofcom requirement fits into #1 or > #2, which is why we're having this discussion. :) > > Peter > > On 3/7/12 8:17 PM, Nancy Bravin wrote: >> Peter and all, >> >> I agree that it is important to revisit now, so that in the future, >> it will be easy to align things in their proper place. Every country >> may have different regulations, spectrum, policy and what >> responsibility is in the domain of the system, and what comes under >> the PAWS charter is important. Maybe some separation might be >> possible, and dividing and clarifying issues now will help in the >> future. Certainly it seems that the FCC may change some rules, and >> we know that Ofcom is not yet finished with their regulations. Canada >> has their own, and other countries are working on this as well. Just >> a thought…Sharing is a realistic goal…as is off loading... Or you >> slim line and every 6 months decide what to incorporate in the >> protocol based on new information, new ideas, new innovation new >> regulations and maybe spend more time than you could if addressed >> now. >> >> That way you leave the door open and outside of referencing what is >> known today, by referencing regulations i.e. Ofcom, FCC, Industry >> Canada etc as of XX-XX-XXXX date. Out of scope not something we know >> enough about to say at this point, In my opinion. >> >> My 2 cents.. >> >> Sincerely, Nancy >> >> On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote: >> >>> >>> >>> As your responsible Area Director (until March 28, when Pete >>> Resnick will take over from me), I have reviewed this thread. >>> >>> In my opinion (I am happy to be proven wrong), this new requirement >>> goes beyond what the charter defined as the scope of this working >>> group, which was to enable a device to discover the white space >>> available to it in its current location. Reporting usage back to >>> the database is simply not mentioned in the charter. >>> >>> Earlier in this thread, Andy Sago wrote: >>> >>> There's no language I can find in the charter that explicitly puts >>> this out of scope. >>> >>> An IETF charter defines what the working group shall work on. Many >>> interesting features could be developed here. However, it is not >>> the job of the charter to mention explicitly that each of those >>> interesting features is out of scope. >>> >>> The charter does say: >>> >>> Once the device learns of the available white space (e.g., in a TV >>> white space implementation, the list of available channels at that >>> location), it can then select one of the bands from the list and >>> begin to transmit and receive on the selected band. >>> >>> This text might have assumed that no further communication or >>> authorization was required in order to select one of the bands from >>> the list and then transmit/receive. Perhaps that assumption was >>> mistaken. If so, it would be good to have a discussion about that, >>> so we can determine if we need to revisit the assumptions we made >>> early on. If in fact we made some faulty or limited assumptions, >>> then let's get that out in the open. >>> >>> Peter >>> >>> On 3/7/12 9:40 AM, Rosen, Brian wrote: >>>> I'd also suggest that our >>>> charter limitation is really support for sharing of whitespace by >>>> whitespace devices. Reporting what you use is not sharing, it's >>>> just data gathering. >>>> >>>> The point of excluding sharing was to eliminate the complexities >>>> of what constituted fairness, and what kinds of communication >>>> might be needed between databases, where more than one could >>>> supply available whitespace in a band. This doesn't have any of >>>> those issues, As long as it's just sending information, I don't >>>> have a problem. Once the database is supposed to do anything >>>> with it that involves changing what spectrum it reports, then I >>>> think we cross the line. >>>> >>>> Brian >>>> >>>> On Mar 6, 2012, at 12:28 PM, >>>> wrote: >>>> >>>>> Joel >>>>> >>>>> Indeed, the regulator has not described the process or provided >>>>> a flow diagram, so there may be some wrinkles, but we need to >>>>> provide for their intent. To answer your question, the channels >>>>> that the master will use are sent in a separate message >>>>> (described in P.12 ter), that occurs after the master receives >>>>> the response to its channel request, but before the master can >>>>> transmit. At this point, it knows what channels are available, >>>>> and which one it will use. As far as the slaves are concerned, >>>>> as they associate, the master will need to gather their details >>>>> and send further channel usage messages to the database on >>>>> their behalf. >>>>> >>>>> Regards >>>>> >>>>> Andy >>>>> >>>>> -----Original Message----- From: paws-bounces@ietf.org >>>>> [mailto:paws-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>>> Sent: 06 March 2012 17:05 To: scott.probasco@nokia.com Cc: >>>>> paws@ietf.org; Cheeseman,CJ,Chris,COD R; Dixon,JS,Johnny,COD R >>>>> Subject: Re: [paws] WGLC for >>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel >>>>> reporting >>>>> >>>>> Ahh. I think I see where the request and my understanding >>>>> divurge. If the idea here is that the master must provide, in >>>>> the request, an indication of what channels it expects to use, >>>>> I can at least understand that. I will return to technical >>>>> concerns in a moment. >>>>> >>>>> However, when you say "provide channel usage information, in >>>>> order to evaluate interference", what that says to me is >>>>> providing, during operation, information as to what channels >>>>> are being used, and at what power levels. That is what would >>>>> be needed to analyze actual interference effects. And that is >>>>> out of scope as I understand our scope. >>>>> >>>>> I do see a technical difficulty with having the master provide, >>>>> as part of either registering or requesting spectrum >>>>> information, what channels it intends to use. It doesn;t know >>>>> what channels it intends to use. It intends to use some number >>>>> of available channels. It will figure out which ones when it >>>>> is told what is available. How can it send that information in >>>>> the request? >>>>> >>>>> Yours, Joel >>>>> >>>>> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: >>>>>> Hi, >>>>>> >>>>>> There is a similarity here with device ID. In context of PAWS >>>>>> we are not concerned with why a device ID is required by a >>>>>> regulator, we accept it is a requirement from a regulator and >>>>>> include it to the protocol. Ofcom identifies in 3.18& 3.19 >>>>>> that channel usage information is required and thus we need >>>>>> to include this information. Since the master must provide >>>>>> this information prior to transmitting, PAWS will not >>>>>> function in the UK without this information and thus I >>>>>> believe channel usage information is integral to the channel >>>>>> request& response messaging. >>>>>> >>>>>> Kind Regards, Scott >>>>>> >>>>>> >>>>>> On 3/6/12 10:30 AM, "ext Joel M. >>>>>> Halpern" wrote: >>>>>> >>>>>>> I would draw a distinction. Ofcom regulations about >>>>>>> whitespace requests are very much relevant. Ofcom >>>>>>> regulations about notification of dynamic behavior (which >>>>>>> spectrum is being used) are not in scope as I understand >>>>>>> the earlier discussions, particularly the chartering >>>>>>> discussions. >>>>>>> >>>>>>> Yours, Joel >>>>>>> >>>>>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: >>>>>>>> >>>>>>>> The ofcom requirements are very much relevant to the >>>>>>>> scope of the PAWS WG. The only other regulatory >>>>>>>> requirements that we have today is the FCC. Ofcom >>>>>>>> requirements are a good addition to the set. >>>>>>>> >>>>>>>> -Raj >>>>>>>> >>>>>>>> On 3/6/12 10:03 AM, "ext >>>>>>>> andy.sago@bt.com" wrote: >>>>>>>> >>>>>>>>> Hi Joel >>>>>>>>> >>>>>>>>> There's no language I can find in the charter that >>>>>>>>> explicitly puts this out of scope. On the other hand, >>>>>>>>> the charter says that the group will "consider input >>>>>>>>> from regulatory entities", and this is one of the >>>>>>>>> requirements from Ofcom that they have just published. >>>>>>>>> The protocol will be worthless for the UK if it omits >>>>>>>>> some requirements. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> Andy >>>>>>>>> >>>>>>>>> -----Original Message----- From: Joel M. Halpern >>>>>>>>> [mailto:jmh@joelhalpern.com] Sent: 06 March 2012 15:53 >>>>>>>>> To: Sago,AJ,Andy,COD R Cc: paws@ietf.org; >>>>>>>>> Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for >>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel >>>>>>>>> reporting >>>>>>>>> >>>>>>>>> As I understand, the information you are asking for is >>>>>>>>> explicitly out of scope for the working group. Yours, >>>>>>>>> Joel >>>>>>>>> >>>>>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >>>>>>>>>> All >>>>>>>>>> >>>>>>>>>> Comparing the draft with the Ofcom requirements at >>>>>>>>>> http://www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-r >>>>>>>>>> >>>>>>>>>> > egul >>>>>>>>>> atory-requirements-for-white-space-devices-in-the-UHF-TV-band, >>>>>>>>>> >>>>>>>>>> > I believe the WG draft is deficient in the area of reporting >>>>>>>>>> frequencies and powers actually used by masters and >>>>>>>>>> slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom >>>>>>>>>> intends to collect this data to assesses the impact >>>>>>>>>> of aggregate interference into other services. It >>>>>>>>>> would also provide usage information (frequency in >>>>>>>>>> use) that would inform the operation of a kill switch >>>>>>>>>> capability. I suggest this deficiency can be remedied >>>>>>>>>> with the following changes: >>>>>>>>>> >>>>>>>>>> New P requirements (probably best placed following >>>>>>>>>> P.12): >>>>>>>>>> >>>>>>>>>> P.12bis: The protocol MUST support a channel usage >>>>>>>>>> message from the slave device to the master device. >>>>>>>>>> The channel usage message MUST include parameters as >>>>>>>>>> required by local regulatory requirement. These >>>>>>>>>> parameters MAY include device ID, manufacturer's >>>>>>>>>> serial number, channel usage and power level >>>>>>>>>> information. >>>>>>>>>> >>>>>>>>>> P.12ter: The protocol MUST support a channel usage >>>>>>>>>> message from the master device to the database. The >>>>>>>>>> channel usage message MUST include parameters as >>>>>>>>>> required by local regulatory requirement for the >>>>>>>>>> master and its associated slaves. These parameters >>>>>>>>>> MAY include device ID, manufacturer's serial number, >>>>>>>>>> channel usage and power level information. >>>>>>>>>> >>>>>>>>>> P.12qua: The protocol MUST support a channel usage >>>>>>>>>> message acknowledgement. >>>>>>>>>> >>>>>>>>>> New O requirements (probably best placed following >>>>>>>>>> O13): >>>>>>>>>> >>>>>>>>>> O.13bis: According to local regulatory policy, after >>>>>>>>>> connecting to a master device's radio network a slave >>>>>>>>>> device MAY inform the master device of the actual >>>>>>>>>> channel usage. The slave MUST include parameters >>>>>>>>>> required by local regulatory policy, e.g. device ID, >>>>>>>>>> manufacturer's serial number, channel usage and power >>>>>>>>>> level information. >>>>>>>>>> >>>>>>>>>> O.13ter: According to local regulatory policy, a >>>>>>>>>> master device MAY inform the database of the actual >>>>>>>>>> channel usage of the master and its slaves. The >>>>>>>>>> master MUST include parameters required by local >>>>>>>>>> regulatory policy, e.g. device ID, manufacturer's >>>>>>>>>> serial number, channel usage and power level >>>>>>>>>> information of the master and its slaves. >>>>>>>>>> >>>>>>>>>> New steps could be introduced into one or more use >>>>>>>>>> cases to cover these Ofcom requirements, e.g. new >>>>>>>>>> steps 6bis and 9bis in the hotspot use case at >>>>>>>>>> 4.2.1: >>>>>>>>>> >>>>>>>>>> 6bis. Prior to initiating transmission, if required >>>>>>>>>> by local regulation, the master/AP informs the >>>>>>>>>> database of the channel and power level it has >>>>>>>>>> chosen. This is repeated for each slave that >>>>>>>>>> associated with the master. >>>>>>>>>> >>>>>>>>>> 9bis. Prior to initiating transmission, if required >>>>>>>>>> by local regulation, the slave informs the master/AP >>>>>>>>>> of the channel and power level it has chosen, and the >>>>>>>>>> master/AP relays this information to the database. >>>>>>>>>> >>>>>>>>>> - end of new text - >>>>>>>>>> >>>>>>>>>> For information, for those not accessing the url in >>>>>>>>>> the first paragraph of this email, the full Ofcom >>>>>>>>>> requirements leading to this new PAWS text are as >>>>>>>>>> follows: >>>>>>>>>> >>>>>>>>>> 3.18 After receiving instructions from a WSDB in >>>>>>>>>> relation to the maximum permitted EIRPs over the DTT >>>>>>>>>> channels, and prior to initiating transmissions >>>>>>>>>> within the UHF TV band, a master WSD must communicate >>>>>>>>>> to the WSDB the following information: >>>>>>>>>> >>>>>>>>>> 3.18.1 The lower and upper frequency boundaries^13 of >>>>>>>>>> the in-block emissions of the master WSD, and those >>>>>>>>>> of the in-block emissions of its associated slaves. A >>>>>>>>>> lower frequency will be specified as (470 + 8k + >>>>>>>>>> 0.2n) MHz, with the corresponding upper frequency >>>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3Ž4 k 3Ž4 >>>>>>>>>> 39, 0 3Ž4 n 3Ž4 39, 1 3Ž4 m 3Ž4 40, and n< m. >>>>>>>>>> >>>>>>>>>> 3.18.2 The maximum in-block EIRP spectral densities >>>>>>>>>> (in dBm/(0.2 MHz)) that the master WSD, and its >>>>>>>>>> associated slaves, actually radiate between each >>>>>>>>>> reported lower frequency boundary and its >>>>>>>>>> corresponding upper frequency boundary. >>>>>>>>>> >>>>>>>>>> Footnote 13 states: >>>>>>>>>> >>>>>>>>>> The use of upper and lower frequency boundaries >>>>>>>>>> (defined over a 200 kHz raster) allows a WSDB to >>>>>>>>>> collect more granular information with regards to the >>>>>>>>>> usage of the frequency resource by narrowband WSD >>>>>>>>>> technologies. The upper and lower frequencies of a >>>>>>>>>> boundary pair do not straddle a DTT channel boundary. >>>>>>>>>> Note that a WSD may transmit over multiple, >>>>>>>>>> non-contiguous, whole DTT channels or fractions of >>>>>>>>>> DTT channels. >>>>>>>>>> >>>>>>>>>> 3.19 A master WSD must be able to receive the >>>>>>>>>> following information^14 from a WSDB: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in the >>>>>>>>>> context of 3.18, that the reported information on the >>>>>>>>>> DTT channels and EIRP spectral densities actually >>>>>>>>>> used by the master and slave WSDs were received >>>>>>>>>> successfully by the WSDB^18 ]. >>>>>>>>>> >>>>>>>>>> Footnote 14 states: >>>>>>>>>> >>>>>>>>>> 14 While the communication of some of this >>>>>>>>>> information from a WSDB to a master WSD is optional, >>>>>>>>>> master WSDs must be able to receive and interpret >>>>>>>>>> these. >>>>>>>>>> >>>>>>>>>> Footnote 18 states: >>>>>>>>>> >>>>>>>>>> 18 This forms part of a handshake protocol and may be >>>>>>>>>> an area where industry could harmonise without the >>>>>>>>>> need for an explicit requirement in the regulations. >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> >>>>>>>>>> Andy >>>>>>>>>> >>>>>>>>>> *From:*paws-bounces@ietf.org >>>>>>>>>> [mailto:paws-bounces@ietf.org] *On Behalf Of >>>>>>>>>> *Gabor.Bajko@nokia.com *Sent:* 05 March 2012 19:46 >>>>>>>>>> *To:* paws@ietf.org *Subject:* [paws] WGLC for >>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >>>>>>>>>> >>>>>>>>>> The authors of the use cases and requirements draft >>>>>>>>>> have just posted a new version of the draft and >>>>>>>>>> indicated that there are no unresolved >>>>>>>>>> comments/issues they are aware of. >>>>>>>>>> >>>>>>>>>> Therefore, I'd like to initiate a WG Last Call for >>>>>>>>>> comments on >>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-u >>>>>>>>>> >>>>>>>>>> > seca >>>>>>>>>> ses-rqmts-03.txt >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Please review the draft and send your comments to the >>>>>>>>>> list by March 20th, 2012. >>>>>>>>>> >>>>>>>>>> If you review the draft and have no comments, send a >>>>>>>>>> note to the list that the draft is good as it is, we >>>>>>>>>> need these notes as much as we need the actual >>>>>>>>>> comments. >>>>>>>>>> >>>>>>>>>> Thanks, Gabor >>>>>>>>>> >>>>>>>>>> > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From JuanCarlos.Zuniga@InterDigital.com Thu Mar 8 09:11:30 2012 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 D0B4D21F842A for ; Thu, 8 Mar 2012 09:11:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.21 X-Spam-Level: X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[AWL=-1.238, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, 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 lityTIfUlyzw for ; Thu, 8 Mar 2012 09:11:29 -0800 (PST) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFBE21F867E for ; Thu, 8 Mar 2012 09:11:25 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 12:11:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 8 Mar 2012 12:11:23 -0500 Message-ID: In-Reply-To: <4F58E552.4060608@stpeter.im> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting Thread-Index: Acz9TMzSLwej2bXhTCS5faHYr6LKFAAAZOLA References: <4F5643A8.7000706@joelhalpern.com><619CDADDCCD2B44380834BE8BF6F71414069146126@EMV62-UKRD.domain1.systemhost.net><4F58004B.5000201@stpeter.im><6BFE7C73-CCC4-4C96-9B44-1540012A29A5@earthlink.net> <4F58E552.4060608@stpeter.im> From: "Zuniga, Juan Carlos" To: "Peter Saint-Andre" , "Nancy Bravin" X-OriginalArrivalTime: 08 Mar 2012 17:11:24.0766 (UTC) FILETIME=[7DDAA7E0:01CCFD4E] Cc: paws@ietf.org, Pete Resnick , johnny.dixon@bt.com, chris.cheeseman@bt.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 17:11:31 -0000 UGV0ZXIsIE5hbmN5LA0KDQpJIGFncmVlIHNob3VsZCBkZXNpZ24gYSBwcm90b2NvbCB3aXRoIHRo ZSBiZXN0IG9mIG91ciBjdXJyZW50IGtub3dsZWRnZSwgYW5kIHRoYXQgc2hvdWxkIGJlIGFjY291 bnRpbmcgZm9yIGFsbCB0aGUga25vd24gcmVndWxhdGlvbnMgYXQgcHJlc2VudCB0aW1lLiBXZSBz aG91bGQgbm90IGxpbWl0IHRoZSBzY29wZSB3aXRoIHRoZSBwdXJwb3NlIG9mIGRlc2lnbmluZyBh IHByb3RvY29sICdmYXN0ZXInLiBPdXIgZ29hbCBpcyBub3Qgb25seSB0byBkZXNpZ24gYSBXU0RC IHByb3RvY29sLiBPdXIgZ29hbCBpcyB0byBkZXNpZ24gYSBXU0RCIHByb3RvY29sIHRoYXQgaXMg VVNFRlVMIHRvIHRoZSBjb21tdW5pdHkuDQoNClRoZSBjaGFydGVyIGRvZXMgc3RhdGUgdGhhdCAN Cg0KIi4uLnRoZSBncm91cCBzaG91bGQgYWxzbyByZWFjaCBvdXQgdG8gb3RoZXIgcG90ZW50aWFs DQoiY3VzdG9tZXJzIiBmb3IgYSB3aGl0ZSBzcGFjZSBkYXRhYmFzZSBhY2Nlc3MgbWV0aG9kIGFu ZCBjb25zaWRlciBpbnB1dA0KZnJvbSByZWd1bGF0b3J5IGVudGl0aWVzIHRoYXQgYXJlIGludm9s dmVkIGluIHRoZSBzcGVjaWZpY2F0aW9uIG9mIHRoZQ0KcnVsZXMgZm9yIHNlY29uZGFyeSB1c2Ug b2Ygc3BlY3RydW0gaW4gc3BlY2lmaWMgcmFkaW8gYmFuZHMuICINCg0KSSB0aGluayB0aGF0IGlz IGV4YWN0bHkgd2hhdCB3ZSBhcmUgZG9pbmcgbm93Lg0KDQpSZWdhcmRpbmcgd2hldGhlciB0aGUg dHlwZXMgb2YgcmVxdWlyZW1lbnRzIGJlbG9uZyB0byAjMSBvciAjMiwgSSBiZWxpZXZlIGl0IGlz IG1vcmUgb2YgIzEgdHlwZSwgYXMgdGhlIGluZm9ybWF0aW9uIHRvIGJlIGV4Y2hhbmdlZCB3b3Vs ZCBiZSBrbm93biBhZnRlciB0aGUgaW5pdGlhbCBxdWVyeS9yZXNwb25zZS4gDQoNCklmIHdlIGtu b3cgaXQgdG9kYXksIEkgc2VlIG5vIHJlYXNvbiB3aHkgd2Ugc2hvdWxkIG5vdCB3b3JrIG9uIGl0 IGluIHRoZSBmaXJzdCBwaGFzZSBvZiB0aGUgd29yay4NCg0KUmVnYXJkcywNCg0KSnVhbiBDYXJs b3MNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBwYXdzLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBQ ZXRlciBTYWludC1BbmRyZQ0KPiBTZW50OiBUaHVyc2RheSwgTWFyY2ggMDgsIDIwMTIgMTE6NTkg QU0NCj4gVG86IE5hbmN5IEJyYXZpbg0KPiBDYzogcGF3c0BpZXRmLm9yZzsgam9obm55LmRpeG9u QGJ0LmNvbTsgY2hyaXMuY2hlZXNlbWFuQGJ0LmNvbTsgUGV0ZQ0KPiBSZXNuaWNrDQo+IFN1Ympl Y3Q6IFJlOiBbcGF3c10gV0dMQyBmb3IgZHJhZnQtaWV0Zi1wYXdzLXByb2JsZW0tc3RtdC11c2Vj YXNlcy0NCj4gcnFtdHMtMDM6IGNoYW5uZWwgcmVwb3J0aW5nDQo+IA0KPiBIaSBOYW5jeSwNCj4g DQo+IFlvdSBhcmUgYWJzb2x1dGVseSByaWdodCB0aGF0IGRpZmZlcmVudCBsb2NhbGVzIHdpbGwg aGF2ZSBkaWZmZXJlbnQNCj4gcnVsZXMgYW5kIHJlcXVpcmVtZW50cy4gV2UgbmVlZCB0byB1bmRl cnN0YW5kIHRob3NlLCBhbmQgd29yayB0bw0KPiBhZGRyZXNzDQo+IHRoZW0gaWYgcG9zc2libGUg KGFsdGhvdWdoIHdlIGRvbid0IG5lY2Vzc2FyaWx5IG5lZWQgdG8gYWRkcmVzcyB0aGVtDQo+IGFs bA0KPiBhdCB0aGUgc2FtZSB0aW1lKS4gSSBzZWUgc2V2ZXJhbCBraW5kcyBvZiByZXF1aXJlbWVu dHM6DQo+IA0KPiAxLiBTb21lIHJlcXVpcmVtZW50cyBtaWdodCBsZWFkIHRvIGZlYXR1cmVzIGJl eW9uZCB0aGUgcXVlcnkvcmVzcG9uc2UNCj4gcHJvdG9jb2wgd2UndmUgZW52aXNpb25lZCBzbyBm YXIuIE9uZSBleGFtcGxlIG1pZ2h0IGJlIHJlYWwtdGltZQ0KPiByZXBvcnRpbmcgYWJvdXQgdGhl IGNoYW5uZWxzIHRoYXQgYSBkZXZpY2UgaXMgYWN0dWFsbHkgdXNpbmcuIEluIG15DQo+IG9waW5p b24sIGl0IHdvdWxkIGJlIGJlc3QgdG8gaGFuZGxlIHRob3NlIGluIHRoZSBuZXh0IHBoYXNlIG9m IHdvcmssDQo+IGJlY2F1c2UgYXMgZmFyIGFzIEkgY2FuIHNlZSB0aGV5IGFyZSBvdXRzaWRlIHRo ZSBzY29wZSBvZiBvdXIgY2hhcnRlci4NCj4gDQo+IDIuIFNvbWUgcmVxdWlyZW1lbnRzIG1pZ2h0 IGJlIGhhbmRsZWQgdGhyb3VnaCBieSBkZWZpbmluZyBhZGRpdGlvbmFsDQo+IGZpZWxkcyB0aGF0 IGNhbiBiZSBpbmNsdWRlZCBpbiB0aGUgcXVlcnkgb3IgcmVzcG9uc2UuIFdlIGRlZmluaXRlbHkN Cj4gcGxhbm5lZCBmb3IgdGhhdCB3aGVuIHdvcmtpbmcgb24gdGhlIGNoYXJ0ZXIgd2l0aCB0aGUg SUVTRzoNCj4gDQo+ICAgSW4gYWRkaXRpb24sIHRoZSBwYXJ0aWN1bGFyDQo+ICAgZGF0YSBleGNo YW5nZWQgYmV0d2VlbiBhIGRldmljZSBhbmQgYSBkYXRhYmFzZSBtaWdodCBkZXBlbmQgb24gdGhl DQo+ICAgcmFuZ2VzIG9mIHJhZGlvIHNwZWN0cnVtIHRoYXQgYXJlIHRvIGJlIHVzZWQsIHRoZSBy ZXF1aXJlbWVudHMgb2YgdGhlDQo+ICAgZGF0YWJhc2Ugb3BlcmF0b3JzIGFuZCB0aGVpciBnb3Zl cm5pbmcgcmVndWxhdGlvbnMsIGFuZCBvdGhlcg0KPiBmYWN0b3JzLg0KPiAgIFRoZXJlZm9yZSwg dGhlIGRhdGFiYXNlIGFjY2VzcyBtZXRob2QgYW5kIHRoZSBxdWVyeS9yZXNwb25zZSBkYXRhDQo+ ICAgZm9ybWF0cyB0aGF0IGFyZSBleGNoYW5nZWQgdXNpbmcgdGhhdCBtZXRob2QgbmVlZCB0byBi ZSBkZXNpZ25lZCBmb3INCj4gICBleHRlbnNpYmlsaXR5IHJhdGhlciB0aGFuIGJlaW5nIHRpZWQg dG8gYW55IHNwZWNpZmljIHNwZWN0cnVtLA0KPiAgIGNvdW50cnksIG9yIHBoeS9tYWMvYWlyIGlu dGVyZmFjZS4NCj4gDQo+IEl0J3MgdW5jbGVhciB0byBtZSByaWdodCBub3cgaWYgdGhlIE9mY29t IHJlcXVpcmVtZW50IGZpdHMgaW50byAjMSBvcg0KPiAjMiwgd2hpY2ggaXMgd2h5IHdlJ3JlIGhh dmluZyB0aGlzIGRpc2N1c3Npb24uIDopDQo+IA0KPiBQZXRlcg0KPiANCj4gT24gMy83LzEyIDg6 MTcgUE0sIE5hbmN5IEJyYXZpbiB3cm90ZToNCj4gPiBQZXRlciBhbmQgYWxsLA0KPiA+DQo+ID4g SSBhZ3JlZSB0aGF0IGl0IGlzIGltcG9ydGFudCB0byByZXZpc2l0IG5vdywgc28gdGhhdCBpbiB0 aGUgZnV0dXJlLA0KPiA+IGl0IHdpbGwgYmUgZWFzeSB0byBhbGlnbiB0aGluZ3MgaW4gdGhlaXIg cHJvcGVyIHBsYWNlLiBFdmVyeSBjb3VudHJ5DQo+ID4gbWF5IGhhdmUgZGlmZmVyZW50IHJlZ3Vs YXRpb25zLCBzcGVjdHJ1bSwgcG9saWN5IGFuZCB3aGF0DQo+ID4gcmVzcG9uc2liaWxpdHkgaXMg aW4gdGhlIGRvbWFpbiBvZiB0aGUgc3lzdGVtLCBhbmQgd2hhdCBjb21lcyB1bmRlcg0KPiA+IHRo ZSBQQVdTIGNoYXJ0ZXIgaXMgaW1wb3J0YW50LiAgTWF5YmUgc29tZSBzZXBhcmF0aW9uIG1pZ2h0 IGJlDQo+ID4gcG9zc2libGUsIGFuZCBkaXZpZGluZyBhbmQgY2xhcmlmeWluZyBpc3N1ZXMgbm93 IHdpbGwgaGVscCBpbiB0aGUNCj4gPiBmdXR1cmUuICBDZXJ0YWlubHkgaXQgc2VlbXMgdGhhdCB0 aGUgRkNDIG1heSBjaGFuZ2Ugc29tZSBydWxlcywgYW5kDQo+ID4gd2Uga25vdyB0aGF0IE9mY29t IGlzIG5vdCB5ZXQgZmluaXNoZWQgd2l0aCB0aGVpciByZWd1bGF0aW9ucy4gQ2FuYWRhDQo+ID4g aGFzIHRoZWlyIG93biwgYW5kIG90aGVyIGNvdW50cmllcyBhcmUgd29ya2luZyBvbiB0aGlzIGFz IHdlbGwuIEp1c3QNCj4gPiBhIHRob3VnaHTigKZTaGFyaW5nIGlzIGEgcmVhbGlzdGljIGdvYWzi gKZhcyBpcyBvZmYgbG9hZGluZy4uLiBPciB5b3UNCj4gPiBzbGltIGxpbmUgYW5kIGV2ZXJ5IDYg bW9udGhzIGRlY2lkZSB3aGF0IHRvIGluY29ycG9yYXRlIGluIHRoZQ0KPiA+IHByb3RvY29sIGJh c2VkIG9uIG5ldyBpbmZvcm1hdGlvbiwgbmV3IGlkZWFzLCBuZXcgaW5ub3ZhdGlvbiBuZXcNCj4g PiByZWd1bGF0aW9ucyBhbmQgbWF5YmUgc3BlbmQgbW9yZSB0aW1lIHRoYW4geW91IGNvdWxkIGlm IGFkZHJlc3NlZA0KPiA+IG5vdy4NCj4gPg0KPiA+IFRoYXQgd2F5IHlvdSBsZWF2ZSB0aGUgZG9v ciBvcGVuIGFuZCBvdXRzaWRlIG9mIHJlZmVyZW5jaW5nIHdoYXQgaXMNCj4gPiBrbm93biB0b2Rh eSwgYnkgcmVmZXJlbmNpbmcgcmVndWxhdGlvbnMgaS5lLiBPZmNvbSwgRkNDLCBJbmR1c3RyeQ0K PiA+IENhbmFkYSBldGMgYXMgb2YgWFgtWFgtWFhYWCBkYXRlLiBPdXQgb2Ygc2NvcGUgbm90IHNv bWV0aGluZyB3ZSBrbm93DQo+ID4gZW5vdWdoIGFib3V0IHRvIHNheSBhdCB0aGlzIHBvaW50LCBJ biBteSBvcGluaW9uLg0KPiA+DQo+ID4gTXkgMiBjZW50cy4uDQo+ID4NCj4gPiBTaW5jZXJlbHks IE5hbmN5DQo+ID4NCj4gPiBPbiBNYXIgNywgMjAxMiwgYXQgNDo0MSBQTSwgUGV0ZXIgU2FpbnQt QW5kcmUgd3JvdGU6DQo+ID4NCj4gPj4gPGhhdCB0eXBlPSdBRCcvPg0KPiA+Pg0KPiA+PiBBcyB5 b3VyIHJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3IgKHVudGlsIE1hcmNoIDI4LCB3aGVuIFBldGUN Cj4gPj4gUmVzbmljayB3aWxsIHRha2Ugb3ZlciBmcm9tIG1lKSwgSSBoYXZlIHJldmlld2VkIHRo aXMgdGhyZWFkLg0KPiA+Pg0KPiA+PiBJbiBteSBvcGluaW9uIChJIGFtIGhhcHB5IHRvIGJlIHBy b3ZlbiB3cm9uZyksIHRoaXMgbmV3IHJlcXVpcmVtZW50DQo+ID4+IGdvZXMgYmV5b25kIHdoYXQg dGhlIGNoYXJ0ZXIgZGVmaW5lZCBhcyB0aGUgc2NvcGUgb2YgdGhpcyB3b3JraW5nDQo+ID4+IGdy b3VwLCB3aGljaCB3YXMgdG8gZW5hYmxlIGEgZGV2aWNlIHRvIGRpc2NvdmVyIHRoZSB3aGl0ZSBz cGFjZQ0KPiA+PiBhdmFpbGFibGUgdG8gaXQgaW4gaXRzIGN1cnJlbnQgbG9jYXRpb24uIFJlcG9y dGluZyB1c2FnZSBiYWNrIHRvDQo+ID4+IHRoZSBkYXRhYmFzZSBpcyBzaW1wbHkgbm90IG1lbnRp b25lZCBpbiB0aGUgY2hhcnRlci4NCj4gPj4NCj4gPj4gRWFybGllciBpbiB0aGlzIHRocmVhZCwg QW5keSBTYWdvIHdyb3RlOg0KPiA+Pg0KPiA+PiBUaGVyZSdzIG5vIGxhbmd1YWdlIEkgY2FuIGZp bmQgaW4gdGhlIGNoYXJ0ZXIgdGhhdCBleHBsaWNpdGx5IHB1dHMNCj4gPj4gdGhpcyBvdXQgb2Yg c2NvcGUuDQo+ID4+DQo+ID4+IEFuIElFVEYgY2hhcnRlciBkZWZpbmVzIHdoYXQgdGhlIHdvcmtp bmcgZ3JvdXAgc2hhbGwgd29yayBvbi4gTWFueQ0KPiA+PiBpbnRlcmVzdGluZyBmZWF0dXJlcyBj b3VsZCBiZSBkZXZlbG9wZWQgaGVyZS4gSG93ZXZlciwgaXQgaXMgbm90DQo+ID4+IHRoZSBqb2Ig b2YgdGhlIGNoYXJ0ZXIgdG8gbWVudGlvbiBleHBsaWNpdGx5IHRoYXQgZWFjaCBvZiB0aG9zZQ0K PiA+PiBpbnRlcmVzdGluZyBmZWF0dXJlcyBpcyBvdXQgb2Ygc2NvcGUuDQo+ID4+DQo+ID4+IFRo ZSBjaGFydGVyIGRvZXMgc2F5Og0KPiA+Pg0KPiA+PiBPbmNlIHRoZSBkZXZpY2UgbGVhcm5zIG9m IHRoZSBhdmFpbGFibGUgd2hpdGUgc3BhY2UgKGUuZy4sIGluIGEgVFYNCj4gPj4gd2hpdGUgc3Bh Y2UgaW1wbGVtZW50YXRpb24sIHRoZSBsaXN0IG9mIGF2YWlsYWJsZSBjaGFubmVscyBhdCB0aGF0 DQo+ID4+IGxvY2F0aW9uKSwgaXQgY2FuIHRoZW4gc2VsZWN0IG9uZSBvZiB0aGUgYmFuZHMgZnJv bSB0aGUgbGlzdCBhbmQNCj4gPj4gYmVnaW4gdG8gdHJhbnNtaXQgYW5kIHJlY2VpdmUgb24gdGhl IHNlbGVjdGVkIGJhbmQuDQo+ID4+DQo+ID4+IFRoaXMgdGV4dCBtaWdodCBoYXZlIGFzc3VtZWQg dGhhdCBubyBmdXJ0aGVyIGNvbW11bmljYXRpb24gb3INCj4gPj4gYXV0aG9yaXphdGlvbiB3YXMg cmVxdWlyZWQgaW4gb3JkZXIgdG8gc2VsZWN0IG9uZSBvZiB0aGUgYmFuZHMgZnJvbQ0KPiA+PiB0 aGUgbGlzdCBhbmQgdGhlbiB0cmFuc21pdC9yZWNlaXZlLiBQZXJoYXBzIHRoYXQgYXNzdW1wdGlv biB3YXMNCj4gPj4gbWlzdGFrZW4uIElmIHNvLCBpdCB3b3VsZCBiZSBnb29kIHRvIGhhdmUgYSBk aXNjdXNzaW9uIGFib3V0IHRoYXQsDQo+ID4+IHNvIHdlIGNhbiBkZXRlcm1pbmUgaWYgd2UgbmVl ZCB0byByZXZpc2l0IHRoZSBhc3N1bXB0aW9ucyB3ZSBtYWRlDQo+ID4+IGVhcmx5IG9uLiBJZiBp biBmYWN0IHdlIG1hZGUgc29tZSBmYXVsdHkgb3IgbGltaXRlZCBhc3N1bXB0aW9ucywNCj4gPj4g dGhlbiBsZXQncyBnZXQgdGhhdCBvdXQgaW4gdGhlIG9wZW4uDQo+ID4+DQo+ID4+IFBldGVyDQo+ ID4+DQo+ID4+IE9uIDMvNy8xMiA5OjQwIEFNLCBSb3NlbiwgQnJpYW4gd3JvdGU6DQo+ID4+PiA8 YXMgaW5kaXZpZHVhbCwgYXQgbGVhc3QgZm9yIG5vdz4gSSdkIGFsc28gc3VnZ2VzdCB0aGF0IG91 cg0KPiA+Pj4gY2hhcnRlciBsaW1pdGF0aW9uIGlzIHJlYWxseSBzdXBwb3J0IGZvciBzaGFyaW5n IG9mIHdoaXRlc3BhY2UgYnkNCj4gPj4+IHdoaXRlc3BhY2UgZGV2aWNlcy4gIFJlcG9ydGluZyB3 aGF0IHlvdSB1c2UgaXMgbm90IHNoYXJpbmcsIGl0J3MNCj4gPj4+IGp1c3QgZGF0YSBnYXRoZXJp bmcuDQo+ID4+Pg0KPiA+Pj4gVGhlIHBvaW50IG9mIGV4Y2x1ZGluZyBzaGFyaW5nIHdhcyB0byBl bGltaW5hdGUgdGhlIGNvbXBsZXhpdGllcw0KPiA+Pj4gb2Ygd2hhdCBjb25zdGl0dXRlZCBmYWly bmVzcywgYW5kIHdoYXQga2luZHMgb2YgY29tbXVuaWNhdGlvbg0KPiA+Pj4gbWlnaHQgYmUgbmVl ZGVkIGJldHdlZW4gZGF0YWJhc2VzLCB3aGVyZSBtb3JlIHRoYW4gb25lIGNvdWxkDQo+ID4+PiBz dXBwbHkgYXZhaWxhYmxlIHdoaXRlc3BhY2UgaW4gYSBiYW5kLiAgVGhpcyBkb2Vzbid0IGhhdmUg YW55IG9mDQo+ID4+PiB0aG9zZSBpc3N1ZXMsIEFzIGxvbmcgYXMgaXQncyBqdXN0IHNlbmRpbmcg aW5mb3JtYXRpb24sIEkgZG9uJ3QNCj4gPj4+IGhhdmUgYSBwcm9ibGVtLiAgT25jZSB0aGUgZGF0 YWJhc2UgaXMgc3VwcG9zZWQgdG8gZG8gYW55dGhpbmcNCj4gPj4+IHdpdGggaXQgdGhhdCBpbnZv bHZlcyBjaGFuZ2luZyB3aGF0IHNwZWN0cnVtIGl0IHJlcG9ydHMsIHRoZW4gSQ0KPiA+Pj4gdGhp bmsgd2UgY3Jvc3MgdGhlIGxpbmUuDQo+ID4+Pg0KPiA+Pj4gQnJpYW4NCj4gPj4+DQo+ID4+PiBP biBNYXIgNiwgMjAxMiwgYXQgMTI6MjggUE0sIDxhbmR5LnNhZ29AYnQuY29tPg0KPiA+Pj4gPGFu ZHkuc2Fnb0BidC5jb20+IHdyb3RlOg0KPiA+Pj4NCj4gPj4+PiBKb2VsDQo+ID4+Pj4NCj4gPj4+ PiBJbmRlZWQsIHRoZSByZWd1bGF0b3IgaGFzIG5vdCBkZXNjcmliZWQgdGhlIHByb2Nlc3Mgb3Ig cHJvdmlkZWQNCj4gPj4+PiBhIGZsb3cgZGlhZ3JhbSwgc28gdGhlcmUgbWF5IGJlIHNvbWUgd3Jp bmtsZXMsIGJ1dCB3ZSBuZWVkIHRvDQo+ID4+Pj4gcHJvdmlkZSBmb3IgdGhlaXIgaW50ZW50LiBU byBhbnN3ZXIgeW91ciBxdWVzdGlvbiwgdGhlIGNoYW5uZWxzDQo+ID4+Pj4gdGhhdCB0aGUgbWFz dGVyIHdpbGwgdXNlIGFyZSBzZW50IGluIGEgc2VwYXJhdGUgbWVzc2FnZQ0KPiA+Pj4+IChkZXNj cmliZWQgaW4gUC4xMiB0ZXIpLCB0aGF0IG9jY3VycyBhZnRlciB0aGUgbWFzdGVyIHJlY2VpdmVz DQo+ID4+Pj4gdGhlIHJlc3BvbnNlIHRvIGl0cyBjaGFubmVsIHJlcXVlc3QsIGJ1dCBiZWZvcmUg dGhlIG1hc3RlciBjYW4NCj4gPj4+PiB0cmFuc21pdC4gQXQgdGhpcyBwb2ludCwgaXQga25vd3Mg d2hhdCBjaGFubmVscyBhcmUgYXZhaWxhYmxlLA0KPiA+Pj4+IGFuZCB3aGljaCBvbmUgaXQgd2ls bCB1c2UuIEFzIGZhciBhcyB0aGUgc2xhdmVzIGFyZSBjb25jZXJuZWQsDQo+ID4+Pj4gYXMgdGhl eSBhc3NvY2lhdGUsIHRoZSBtYXN0ZXIgd2lsbCBuZWVkIHRvIGdhdGhlciB0aGVpciBkZXRhaWxz DQo+ID4+Pj4gYW5kIHNlbmQgZnVydGhlciBjaGFubmVsIHVzYWdlIG1lc3NhZ2VzIHRvIHRoZSBk YXRhYmFzZSBvbg0KPiA+Pj4+IHRoZWlyIGJlaGFsZi4NCj4gPj4+Pg0KPiA+Pj4+IFJlZ2FyZHMN Cj4gPj4+Pg0KPiA+Pj4+IEFuZHkNCj4gPj4+Pg0KPiA+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tIEZyb206IHBhd3MtYm91bmNlc0BpZXRmLm9yZw0KPiA+Pj4+IFttYWlsdG86cGF3cy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9lbCBNLiBIYWxwZXJuDQo+ID4+Pj4gU2Vu dDogMDYgTWFyY2ggMjAxMiAxNzowNSBUbzogc2NvdHQucHJvYmFzY29Abm9raWEuY29tIENjOg0K PiA+Pj4+IHBhd3NAaWV0Zi5vcmc7IENoZWVzZW1hbixDSixDaHJpcyxDT0QgUjsgRGl4b24sSlMs Sm9obm55LENPRCBSDQo+ID4+Pj4gU3ViamVjdDogUmU6IFtwYXdzXSBXR0xDIGZvcg0KPiA+Pj4+ IGRyYWZ0LWlldGYtcGF3cy1wcm9ibGVtLXN0bXQtdXNlY2FzZXMtcnFtdHMtMDM6IGNoYW5uZWwN Cj4gPj4+PiByZXBvcnRpbmcNCj4gPj4+Pg0KPiA+Pj4+IEFoaC4gIEkgdGhpbmsgSSBzZWUgd2hl cmUgdGhlIHJlcXVlc3QgYW5kIG15IHVuZGVyc3RhbmRpbmcNCj4gPj4+PiBkaXZ1cmdlLiBJZiB0 aGUgaWRlYSBoZXJlIGlzIHRoYXQgdGhlIG1hc3RlciBtdXN0IHByb3ZpZGUsIGluDQo+ID4+Pj4g dGhlIHJlcXVlc3QsIGFuIGluZGljYXRpb24gb2Ygd2hhdCBjaGFubmVscyBpdCBleHBlY3RzIHRv IHVzZSwNCj4gPj4+PiBJIGNhbiBhdCBsZWFzdCB1bmRlcnN0YW5kIHRoYXQuICBJIHdpbGwgcmV0 dXJuIHRvIHRlY2huaWNhbA0KPiA+Pj4+IGNvbmNlcm5zIGluIGEgbW9tZW50Lg0KPiA+Pj4+DQo+ ID4+Pj4gSG93ZXZlciwgd2hlbiB5b3Ugc2F5ICJwcm92aWRlIGNoYW5uZWwgdXNhZ2UgaW5mb3Jt YXRpb24sIGluDQo+ID4+Pj4gb3JkZXIgdG8gZXZhbHVhdGUgaW50ZXJmZXJlbmNlIiwgd2hhdCB0 aGF0IHNheXMgdG8gbWUgaXMNCj4gPj4+PiBwcm92aWRpbmcsIGR1cmluZyBvcGVyYXRpb24sIGlu Zm9ybWF0aW9uIGFzIHRvIHdoYXQgY2hhbm5lbHMNCj4gPj4+PiBhcmUgYmVpbmcgdXNlZCwgYW5k IGF0IHdoYXQgcG93ZXIgbGV2ZWxzLiAgVGhhdCBpcyB3aGF0IHdvdWxkDQo+ID4+Pj4gYmUgbmVl ZGVkIHRvIGFuYWx5emUgYWN0dWFsIGludGVyZmVyZW5jZSBlZmZlY3RzLiBBbmQgdGhhdCBpcw0K PiA+Pj4+IG91dCBvZiBzY29wZSBhcyBJIHVuZGVyc3RhbmQgb3VyIHNjb3BlLg0KPiA+Pj4+DQo+ ID4+Pj4gSSBkbyBzZWUgYSB0ZWNobmljYWwgZGlmZmljdWx0eSB3aXRoIGhhdmluZyB0aGUgbWFz dGVyIHByb3ZpZGUsDQo+ID4+Pj4gYXMgcGFydCBvZiBlaXRoZXIgcmVnaXN0ZXJpbmcgb3IgcmVx dWVzdGluZyBzcGVjdHJ1bQ0KPiA+Pj4+IGluZm9ybWF0aW9uLCB3aGF0IGNoYW5uZWxzIGl0IGlu dGVuZHMgdG8gdXNlLiAgSXQgZG9lc247dCBrbm93DQo+ID4+Pj4gd2hhdCBjaGFubmVscyBpdCBp bnRlbmRzIHRvIHVzZS4gIEl0IGludGVuZHMgdG8gdXNlIHNvbWUgbnVtYmVyDQo+ID4+Pj4gb2Yg YXZhaWxhYmxlIGNoYW5uZWxzLiAgSXQgd2lsbCBmaWd1cmUgb3V0IHdoaWNoIG9uZXMgd2hlbiBp dA0KPiA+Pj4+IGlzIHRvbGQgd2hhdCBpcyBhdmFpbGFibGUuICBIb3cgY2FuIGl0IHNlbmQgdGhh dCBpbmZvcm1hdGlvbiBpbg0KPiA+Pj4+IHRoZSByZXF1ZXN0Pw0KPiA+Pj4+DQo+ID4+Pj4gWW91 cnMsIEpvZWwNCj4gPj4+Pg0KPiA+Pj4+IE9uIDMvNi8yMDEyIDExOjQ4IEFNLCBzY290dC5wcm9i YXNjb0Bub2tpYS5jb20gd3JvdGU6DQo+ID4+Pj4+IEhpLA0KPiA+Pj4+Pg0KPiA+Pj4+PiBUaGVy ZSBpcyBhIHNpbWlsYXJpdHkgaGVyZSB3aXRoIGRldmljZSBJRC4gSW4gY29udGV4dCBvZiBQQVdT DQo+ID4+Pj4+IHdlIGFyZSBub3QgY29uY2VybmVkIHdpdGggd2h5IGEgZGV2aWNlIElEIGlzIHJl cXVpcmVkIGJ5IGENCj4gPj4+Pj4gcmVndWxhdG9yLCB3ZSBhY2NlcHQgaXQgaXMgYSByZXF1aXJl bWVudCBmcm9tIGEgcmVndWxhdG9yIGFuZA0KPiA+Pj4+PiBpbmNsdWRlIGl0IHRvIHRoZSBwcm90 b2NvbC4gT2Zjb20gaWRlbnRpZmllcyBpbiAzLjE4JiAgMy4xOQ0KPiA+Pj4+PiB0aGF0IGNoYW5u ZWwgdXNhZ2UgaW5mb3JtYXRpb24gaXMgcmVxdWlyZWQgYW5kIHRodXMgd2UgbmVlZA0KPiA+Pj4+ PiB0byBpbmNsdWRlIHRoaXMgaW5mb3JtYXRpb24uIFNpbmNlIHRoZSBtYXN0ZXIgbXVzdCBwcm92 aWRlDQo+ID4+Pj4+IHRoaXMgaW5mb3JtYXRpb24gcHJpb3IgdG8gdHJhbnNtaXR0aW5nLCBQQVdT IHdpbGwgbm90DQo+ID4+Pj4+IGZ1bmN0aW9uIGluIHRoZSBVSyB3aXRob3V0IHRoaXMgaW5mb3Jt YXRpb24gYW5kIHRodXMgSQ0KPiA+Pj4+PiBiZWxpZXZlIGNoYW5uZWwgdXNhZ2UgaW5mb3JtYXRp b24gaXMgaW50ZWdyYWwgdG8gdGhlIGNoYW5uZWwNCj4gPj4+Pj4gcmVxdWVzdCYgIHJlc3BvbnNl IG1lc3NhZ2luZy4NCj4gPj4+Pj4NCj4gPj4+Pj4gS2luZCBSZWdhcmRzLCBTY290dA0KPiA+Pj4+ Pg0KPiA+Pj4+Pg0KPiA+Pj4+PiBPbiAzLzYvMTIgMTA6MzAgQU0sICJleHQgSm9lbCBNLg0KPiA+ Pj4+PiBIYWxwZXJuIjxqbWhAam9lbGhhbHBlcm4uY29tPiAgd3JvdGU6DQo+ID4+Pj4+DQo+ID4+ Pj4+PiBJIHdvdWxkIGRyYXcgYSBkaXN0aW5jdGlvbi4gIE9mY29tIHJlZ3VsYXRpb25zIGFib3V0 DQo+ID4+Pj4+PiB3aGl0ZXNwYWNlIHJlcXVlc3RzIGFyZSB2ZXJ5IG11Y2ggcmVsZXZhbnQuIE9m Y29tDQo+ID4+Pj4+PiByZWd1bGF0aW9ucyBhYm91dCBub3RpZmljYXRpb24gb2YgZHluYW1pYyBi ZWhhdmlvciAod2hpY2gNCj4gPj4+Pj4+IHNwZWN0cnVtIGlzIGJlaW5nIHVzZWQpIGFyZSBub3Qg aW4gc2NvcGUgYXMgSSB1bmRlcnN0YW5kDQo+ID4+Pj4+PiB0aGUgZWFybGllciBkaXNjdXNzaW9u cywgcGFydGljdWxhcmx5IHRoZSBjaGFydGVyaW5nDQo+ID4+Pj4+PiBkaXNjdXNzaW9ucy4NCj4g Pj4+Pj4+DQo+ID4+Pj4+PiBZb3VycywgSm9lbA0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IE9uIDMvNi8y MDEyIDExOjIyIEFNLCBCYXNhdmFyYWouUGF0aWxAbm9raWEuY29tIHdyb3RlOg0KPiA+Pj4+Pj4+ DQo+ID4+Pj4+Pj4gVGhlIG9mY29tIHJlcXVpcmVtZW50cyBhcmUgdmVyeSBtdWNoIHJlbGV2YW50 IHRvIHRoZQ0KPiA+Pj4+Pj4+IHNjb3BlIG9mIHRoZSBQQVdTIFdHLiBUaGUgb25seSBvdGhlciBy ZWd1bGF0b3J5DQo+ID4+Pj4+Pj4gcmVxdWlyZW1lbnRzIHRoYXQgd2UgaGF2ZSB0b2RheSBpcyB0 aGUgRkNDLiBPZmNvbQ0KPiA+Pj4+Pj4+IHJlcXVpcmVtZW50cyBhcmUgYSBnb29kIGFkZGl0aW9u IHRvIHRoZSBzZXQuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiAtUmFqDQo+ID4+Pj4+Pj4NCj4gPj4+ Pj4+PiBPbiAzLzYvMTIgMTA6MDMgQU0sICJleHQNCj4gPj4+Pj4+PiBhbmR5LnNhZ29AYnQuY29t IjxhbmR5LnNhZ29AYnQuY29tPiAgIHdyb3RlOg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IEhpIEpv ZWwNCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gVGhlcmUncyBubyBsYW5ndWFnZSBJIGNhbiBmaW5k IGluIHRoZSBjaGFydGVyIHRoYXQNCj4gPj4+Pj4+Pj4gZXhwbGljaXRseSBwdXRzIHRoaXMgb3V0 IG9mIHNjb3BlLiBPbiB0aGUgb3RoZXIgaGFuZCwNCj4gPj4+Pj4+Pj4gdGhlIGNoYXJ0ZXIgc2F5 cyB0aGF0IHRoZSBncm91cCB3aWxsICJjb25zaWRlciBpbnB1dA0KPiA+Pj4+Pj4+PiBmcm9tIHJl Z3VsYXRvcnkgZW50aXRpZXMiLCBhbmQgdGhpcyBpcyBvbmUgb2YgdGhlDQo+ID4+Pj4+Pj4+IHJl cXVpcmVtZW50cyBmcm9tIE9mY29tIHRoYXQgdGhleSBoYXZlIGp1c3QgcHVibGlzaGVkLg0KPiA+ Pj4+Pj4+PiBUaGUgcHJvdG9jb2wgd2lsbCBiZSB3b3J0aGxlc3MgZm9yIHRoZSBVSyBpZiBpdCBv bWl0cw0KPiA+Pj4+Pj4+PiBzb21lIHJlcXVpcmVtZW50cy4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+ Pj4gUmVnYXJkcw0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBBbmR5DQo+ID4+Pj4+Pj4+DQo+ID4+ Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IEpvZWwgTS4gSGFscGVybg0K PiA+Pj4+Pj4+PiBbbWFpbHRvOmptaEBqb2VsaGFscGVybi5jb21dIFNlbnQ6IDA2IE1hcmNoIDIw MTIgMTU6NTMNCj4gPj4+Pj4+Pj4gVG86IFNhZ28sQUosQW5keSxDT0QgUiBDYzogcGF3c0BpZXRm Lm9yZzsNCj4gPj4+Pj4+Pj4gR2Fib3IuQmFqa29Abm9raWEuY29tIFN1YmplY3Q6IFJlOiBbcGF3 c10gV0dMQyBmb3INCj4gPj4+Pj4+Pj4gZHJhZnQtaWV0Zi1wYXdzLXByb2JsZW0tc3RtdC11c2Vj YXNlcy1ycW10cy0wMzogY2hhbm5lbA0KPiA+Pj4+Pj4+PiByZXBvcnRpbmcNCj4gPj4+Pj4+Pj4N Cj4gPj4+Pj4+Pj4gQXMgSSB1bmRlcnN0YW5kLCB0aGUgaW5mb3JtYXRpb24geW91IGFyZSBhc2tp bmcgZm9yIGlzDQo+ID4+Pj4+Pj4+IGV4cGxpY2l0bHkgb3V0IG9mIHNjb3BlIGZvciB0aGUgd29y a2luZyBncm91cC4gWW91cnMsDQo+ID4+Pj4+Pj4+IEpvZWwNCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+ Pj4gT24gMy82LzIwMTIgMTA6NDIgQU0sIGFuZHkuc2Fnb0BidC5jb20gd3JvdGU6DQo+ID4+Pj4+ Pj4+PiBBbGwNCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBDb21wYXJpbmcgdGhlIGRyYWZ0IHdp dGggdGhlIE9mY29tIHJlcXVpcmVtZW50cyBhdA0KPiA+Pj4+Pj4+Pj4gaHR0cDovL3d3dy5jZXB0 Lm9yZy9Eb2N1bWVudHMvc2UtDQo+IDQzLzQxNjEvU0U0MygxMilJbmZvMDNfRHJhZnQtVUstcg0K PiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+DQo+IGVndWwNCj4gPj4+Pj4+Pj4+IGF0b3J5LXJlcXVp cmVtZW50cy1mb3Itd2hpdGUtc3BhY2UtZGV2aWNlcy1pbi10aGUtVUhGLVRWLQ0KPiBiYW5kLA0K PiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+DQo+IEkgYmVsaWV2ZSB0aGUgV0cgZHJhZnQgaXMgZGVm aWNpZW50IGluIHRoZSBhcmVhIG9mIHJlcG9ydGluZw0KPiA+Pj4+Pj4+Pj4gZnJlcXVlbmNpZXMg YW5kIHBvd2VycyBhY3R1YWxseSB1c2VkIGJ5IG1hc3RlcnMgYW5kDQo+ID4+Pj4+Pj4+PiBzbGF2 ZXMgKE9mY29tIHJlcXVpcmVtZW50cyAzLjE4IGFuZCAzLjE5LjgpLiBPZmNvbQ0KPiA+Pj4+Pj4+ Pj4gaW50ZW5kcyB0byBjb2xsZWN0IHRoaXMgZGF0YSB0byBhc3Nlc3NlcyB0aGUgaW1wYWN0DQo+ ID4+Pj4+Pj4+PiBvZiBhZ2dyZWdhdGUgaW50ZXJmZXJlbmNlIGludG8gb3RoZXIgc2VydmljZXMu IEl0DQo+ID4+Pj4+Pj4+PiB3b3VsZCBhbHNvIHByb3ZpZGUgdXNhZ2UgaW5mb3JtYXRpb24gKGZy ZXF1ZW5jeSBpbg0KPiA+Pj4+Pj4+Pj4gdXNlKSB0aGF0IHdvdWxkIGluZm9ybSB0aGUgb3BlcmF0 aW9uIG9mIGEga2lsbCBzd2l0Y2gNCj4gPj4+Pj4+Pj4+IGNhcGFiaWxpdHkuIEkgc3VnZ2VzdCB0 aGlzIGRlZmljaWVuY3kgY2FuIGJlIHJlbWVkaWVkDQo+ID4+Pj4+Pj4+PiB3aXRoIHRoZSBmb2xs b3dpbmcgY2hhbmdlczoNCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBOZXcgUCByZXF1aXJlbWVu dHMgKHByb2JhYmx5IGJlc3QgcGxhY2VkIGZvbGxvd2luZw0KPiA+Pj4+Pj4+Pj4gUC4xMik6DQo+ ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gUC4xMmJpczogVGhlIHByb3RvY29sIE1VU1Qgc3VwcG9y dCBhIGNoYW5uZWwgdXNhZ2UNCj4gPj4+Pj4+Pj4+IG1lc3NhZ2UgZnJvbSB0aGUgc2xhdmUgZGV2 aWNlIHRvIHRoZSBtYXN0ZXIgZGV2aWNlLg0KPiA+Pj4+Pj4+Pj4gVGhlIGNoYW5uZWwgdXNhZ2Ug bWVzc2FnZSBNVVNUIGluY2x1ZGUgcGFyYW1ldGVycyBhcw0KPiA+Pj4+Pj4+Pj4gcmVxdWlyZWQg YnkgbG9jYWwgcmVndWxhdG9yeSByZXF1aXJlbWVudC4gIFRoZXNlDQo+ID4+Pj4+Pj4+PiBwYXJh bWV0ZXJzIE1BWSBpbmNsdWRlIGRldmljZSBJRCwgbWFudWZhY3R1cmVyJ3MNCj4gPj4+Pj4+Pj4+ IHNlcmlhbCBudW1iZXIsIGNoYW5uZWwgdXNhZ2UgYW5kIHBvd2VyIGxldmVsDQo+ID4+Pj4+Pj4+ PiBpbmZvcm1hdGlvbi4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBQLjEydGVyOiBUaGUgcHJv dG9jb2wgTVVTVCBzdXBwb3J0IGEgY2hhbm5lbCB1c2FnZQ0KPiA+Pj4+Pj4+Pj4gbWVzc2FnZSBm cm9tIHRoZSBtYXN0ZXIgZGV2aWNlIHRvIHRoZSBkYXRhYmFzZS4gIFRoZQ0KPiA+Pj4+Pj4+Pj4g Y2hhbm5lbCB1c2FnZSBtZXNzYWdlIE1VU1QgaW5jbHVkZSBwYXJhbWV0ZXJzIGFzDQo+ID4+Pj4+ Pj4+PiByZXF1aXJlZCBieSBsb2NhbCByZWd1bGF0b3J5IHJlcXVpcmVtZW50IGZvciB0aGUNCj4g Pj4+Pj4+Pj4+IG1hc3RlciBhbmQgaXRzIGFzc29jaWF0ZWQgc2xhdmVzLiAgVGhlc2UgcGFyYW1l dGVycw0KPiA+Pj4+Pj4+Pj4gTUFZIGluY2x1ZGUgZGV2aWNlIElELCBtYW51ZmFjdHVyZXIncyBz ZXJpYWwgbnVtYmVyLA0KPiA+Pj4+Pj4+Pj4gY2hhbm5lbCB1c2FnZSBhbmQgcG93ZXIgbGV2ZWwg aW5mb3JtYXRpb24uDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gUC4xMnF1YTogVGhlIHByb3Rv Y29sIE1VU1Qgc3VwcG9ydCBhIGNoYW5uZWwgdXNhZ2UNCj4gPj4+Pj4+Pj4+IG1lc3NhZ2UgYWNr bm93bGVkZ2VtZW50Lg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IE5ldyBPIHJlcXVpcmVtZW50 cyAocHJvYmFibHkgYmVzdCBwbGFjZWQgZm9sbG93aW5nDQo+ID4+Pj4+Pj4+PiBPMTMpOg0KPiA+ Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IE8uMTNiaXM6ICBBY2NvcmRpbmcgdG8gbG9jYWwgcmVndWxh dG9yeSBwb2xpY3ksIGFmdGVyDQo+ID4+Pj4+Pj4+PiBjb25uZWN0aW5nIHRvIGEgbWFzdGVyIGRl dmljZSdzIHJhZGlvIG5ldHdvcmsgYSBzbGF2ZQ0KPiA+Pj4+Pj4+Pj4gZGV2aWNlIE1BWSBpbmZv cm0gdGhlIG1hc3RlciBkZXZpY2Ugb2YgdGhlIGFjdHVhbA0KPiA+Pj4+Pj4+Pj4gY2hhbm5lbCB1 c2FnZS4gVGhlIHNsYXZlIE1VU1QgaW5jbHVkZSBwYXJhbWV0ZXJzDQo+ID4+Pj4+Pj4+PiByZXF1 aXJlZCBieSBsb2NhbCByZWd1bGF0b3J5IHBvbGljeSwgZS5nLiBkZXZpY2UgSUQsDQo+ID4+Pj4+ Pj4+PiBtYW51ZmFjdHVyZXIncyBzZXJpYWwgbnVtYmVyLCBjaGFubmVsIHVzYWdlIGFuZCBwb3dl cg0KPiA+Pj4+Pj4+Pj4gbGV2ZWwgaW5mb3JtYXRpb24uDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+ Pj4gTy4xM3RlcjogIEFjY29yZGluZyB0byBsb2NhbCByZWd1bGF0b3J5IHBvbGljeSwgYQ0KPiA+ Pj4+Pj4+Pj4gbWFzdGVyIGRldmljZSBNQVkgaW5mb3JtIHRoZSBkYXRhYmFzZSBvZiB0aGUgYWN0 dWFsDQo+ID4+Pj4+Pj4+PiBjaGFubmVsIHVzYWdlIG9mIHRoZSBtYXN0ZXIgYW5kIGl0cyBzbGF2 ZXMuIFRoZQ0KPiA+Pj4+Pj4+Pj4gbWFzdGVyIE1VU1QgaW5jbHVkZSBwYXJhbWV0ZXJzIHJlcXVp cmVkIGJ5IGxvY2FsDQo+ID4+Pj4+Pj4+PiByZWd1bGF0b3J5IHBvbGljeSwgZS5nLiBkZXZpY2Ug SUQsIG1hbnVmYWN0dXJlcidzDQo+ID4+Pj4+Pj4+PiBzZXJpYWwgbnVtYmVyLCBjaGFubmVsIHVz YWdlIGFuZCBwb3dlciBsZXZlbA0KPiA+Pj4+Pj4+Pj4gaW5mb3JtYXRpb24gb2YgdGhlIG1hc3Rl ciBhbmQgaXRzIHNsYXZlcy4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBOZXcgc3RlcHMgY291 bGQgYmUgaW50cm9kdWNlZCBpbnRvIG9uZSBvciBtb3JlIHVzZQ0KPiA+Pj4+Pj4+Pj4gY2FzZXMg dG8gY292ZXIgdGhlc2UgT2Zjb20gcmVxdWlyZW1lbnRzLCBlLmcuIG5ldw0KPiA+Pj4+Pj4+Pj4g c3RlcHMgNmJpcyBhbmQgOWJpcyBpbiB0aGUgaG90c3BvdCB1c2UgY2FzZSBhdA0KPiA+Pj4+Pj4+ Pj4gNC4yLjE6DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gNmJpcy4gUHJpb3IgdG8gaW5pdGlh dGluZyB0cmFuc21pc3Npb24sIGlmIHJlcXVpcmVkDQo+ID4+Pj4+Pj4+PiBieSBsb2NhbCByZWd1 bGF0aW9uLCB0aGUgbWFzdGVyL0FQIGluZm9ybXMgdGhlDQo+ID4+Pj4+Pj4+PiBkYXRhYmFzZSBv ZiB0aGUgY2hhbm5lbCBhbmQgcG93ZXIgbGV2ZWwgaXQgaGFzDQo+ID4+Pj4+Pj4+PiBjaG9zZW4u IFRoaXMgaXMgcmVwZWF0ZWQgZm9yIGVhY2ggc2xhdmUgdGhhdA0KPiA+Pj4+Pj4+Pj4gYXNzb2Np YXRlZCB3aXRoIHRoZSBtYXN0ZXIuDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gOWJpcy4gUHJp b3IgdG8gaW5pdGlhdGluZyB0cmFuc21pc3Npb24sIGlmIHJlcXVpcmVkDQo+ID4+Pj4+Pj4+PiBi eSBsb2NhbCByZWd1bGF0aW9uLCB0aGUgc2xhdmUgaW5mb3JtcyB0aGUgbWFzdGVyL0FQDQo+ID4+ Pj4+Pj4+PiBvZiB0aGUgY2hhbm5lbCBhbmQgcG93ZXIgbGV2ZWwgaXQgaGFzIGNob3NlbiwgYW5k IHRoZQ0KPiA+Pj4+Pj4+Pj4gbWFzdGVyL0FQIHJlbGF5cyB0aGlzIGluZm9ybWF0aW9uIHRvIHRo ZSBkYXRhYmFzZS4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiAtIGVuZCBvZiBuZXcgdGV4dCAt DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gRm9yIGluZm9ybWF0aW9uLCBmb3IgdGhvc2Ugbm90 IGFjY2Vzc2luZyB0aGUgdXJsIGluDQo+ID4+Pj4+Pj4+PiB0aGUgZmlyc3QgcGFyYWdyYXBoIG9m IHRoaXMgZW1haWwsIHRoZSBmdWxsIE9mY29tDQo+ID4+Pj4+Pj4+PiByZXF1aXJlbWVudHMgbGVh ZGluZyB0byB0aGlzIG5ldyBQQVdTIHRleHQgYXJlIGFzDQo+ID4+Pj4+Pj4+PiBmb2xsb3dzOg0K PiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IDMuMTggQWZ0ZXIgcmVjZWl2aW5nIGluc3RydWN0aW9u cyBmcm9tIGEgV1NEQiBpbg0KPiA+Pj4+Pj4+Pj4gcmVsYXRpb24gdG8gdGhlIG1heGltdW0gcGVy bWl0dGVkIEVJUlBzIG92ZXIgdGhlIERUVA0KPiA+Pj4+Pj4+Pj4gY2hhbm5lbHMsIGFuZCBwcmlv ciB0byBpbml0aWF0aW5nIHRyYW5zbWlzc2lvbnMNCj4gPj4+Pj4+Pj4+IHdpdGhpbiB0aGUgVUhG IFRWIGJhbmQsIGEgbWFzdGVyIFdTRCBtdXN0IGNvbW11bmljYXRlDQo+ID4+Pj4+Pj4+PiB0byB0 aGUgV1NEQiB0aGUgZm9sbG93aW5nIGluZm9ybWF0aW9uOg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+ Pj4+IDMuMTguMSBUaGUgbG93ZXIgYW5kIHVwcGVyIGZyZXF1ZW5jeSBib3VuZGFyaWVzXjEzIG9m DQo+ID4+Pj4+Pj4+PiB0aGUgaW4tYmxvY2sgZW1pc3Npb25zIG9mIHRoZSBtYXN0ZXIgV1NELCBh bmQgdGhvc2UNCj4gPj4+Pj4+Pj4+IG9mIHRoZSBpbi1ibG9jayBlbWlzc2lvbnMgb2YgaXRzIGFz c29jaWF0ZWQgc2xhdmVzLiBBDQo+ID4+Pj4+Pj4+PiBsb3dlciBmcmVxdWVuY3kgd2lsbCBiZSBz cGVjaWZpZWQgYXMgKDQ3MCArIDhrICsNCj4gPj4+Pj4+Pj4+IDAuMm4pIE1Ieiwgd2l0aCB0aGUg Y29ycmVzcG9uZGluZyB1cHBlciBmcmVxdWVuY3kNCj4gPj4+Pj4+Pj4+IHNwZWNpZmllZCBhcyAo NDcwICsgOGsgKyAwLjJtKSBNSHosIHdoZXJlIDAgM8W9NCBrIDPFvTQNCj4gPj4+Pj4+Pj4+IDM5 LCAwIDPFvTQgbiAzxb00IDM5LCAxIDPFvTQgbSAzxb00IDQwLCBhbmQgbjwgICBtLg0KPiA+Pj4+ Pj4+Pj4NCj4gPj4+Pj4+Pj4+IDMuMTguMiBUaGUgbWF4aW11bSBpbi1ibG9jayBFSVJQIHNwZWN0 cmFsIGRlbnNpdGllcw0KPiA+Pj4+Pj4+Pj4gKGluIGRCbS8oMC4yIE1IeikpIHRoYXQgdGhlIG1h c3RlciBXU0QsIGFuZCBpdHMNCj4gPj4+Pj4+Pj4+IGFzc29jaWF0ZWQgc2xhdmVzLCBhY3R1YWxs eSByYWRpYXRlIGJldHdlZW4gZWFjaA0KPiA+Pj4+Pj4+Pj4gcmVwb3J0ZWQgbG93ZXIgZnJlcXVl bmN5IGJvdW5kYXJ5IGFuZCBpdHMNCj4gPj4+Pj4+Pj4+IGNvcnJlc3BvbmRpbmcgdXBwZXIgZnJl cXVlbmN5IGJvdW5kYXJ5Lg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IEZvb3Rub3RlIDEzIHN0 YXRlczoNCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBUaGUgdXNlIG9mIHVwcGVyIGFuZCBsb3dl ciBmcmVxdWVuY3kgYm91bmRhcmllcw0KPiA+Pj4+Pj4+Pj4gKGRlZmluZWQgb3ZlciBhIDIwMCBr SHogcmFzdGVyKSBhbGxvd3MgYSBXU0RCIHRvDQo+ID4+Pj4+Pj4+PiBjb2xsZWN0IG1vcmUgZ3Jh bnVsYXIgaW5mb3JtYXRpb24gd2l0aCByZWdhcmRzIHRvIHRoZQ0KPiA+Pj4+Pj4+Pj4gdXNhZ2Ug b2YgdGhlIGZyZXF1ZW5jeSByZXNvdXJjZSBieSBuYXJyb3diYW5kIFdTRA0KPiA+Pj4+Pj4+Pj4g dGVjaG5vbG9naWVzLiBUaGUgdXBwZXIgYW5kIGxvd2VyIGZyZXF1ZW5jaWVzIG9mIGENCj4gPj4+ Pj4+Pj4+IGJvdW5kYXJ5IHBhaXIgZG8gbm90IHN0cmFkZGxlIGEgRFRUIGNoYW5uZWwgYm91bmRh cnkuDQo+ID4+Pj4+Pj4+PiBOb3RlIHRoYXQgYSBXU0QgbWF5IHRyYW5zbWl0IG92ZXIgbXVsdGlw bGUsDQo+ID4+Pj4+Pj4+PiBub24tY29udGlndW91cywgd2hvbGUgRFRUIGNoYW5uZWxzIG9yIGZy YWN0aW9ucyBvZg0KPiA+Pj4+Pj4+Pj4gRFRUIGNoYW5uZWxzLg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+ Pj4+Pj4+IDMuMTkgQSBtYXN0ZXIgV1NEIG11c3QgYmUgYWJsZSB0byByZWNlaXZlIHRoZQ0KPiA+ Pj4+Pj4+Pj4gZm9sbG93aW5nIGluZm9ybWF0aW9uXjE0IGZyb20gYSBXU0RCOg0KPiA+Pj4+Pj4+ Pj4NCj4gPj4+Pj4+Pj4+IDxzbmlwPg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IDMuMTkuOCAg ICAgW0FuIGFja25vd2xlZGdlbWVudCBmcm9tIHRoZSBXU0RCLCBpbiB0aGUNCj4gPj4+Pj4+Pj4+ IGNvbnRleHQgb2YgMy4xOCwgdGhhdCB0aGUgcmVwb3J0ZWQgaW5mb3JtYXRpb24gb24gdGhlDQo+ ID4+Pj4+Pj4+PiBEVFQgY2hhbm5lbHMgYW5kIEVJUlAgc3BlY3RyYWwgZGVuc2l0aWVzIGFjdHVh bGx5DQo+ID4+Pj4+Pj4+PiB1c2VkIGJ5IHRoZSBtYXN0ZXIgYW5kIHNsYXZlIFdTRHMgd2VyZSBy ZWNlaXZlZA0KPiA+Pj4+Pj4+Pj4gc3VjY2Vzc2Z1bGx5IGJ5IHRoZSBXU0RCXjE4IF0uDQo+ID4+ Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gRm9vdG5vdGUgMTQgc3RhdGVzOg0KPiA+Pj4+Pj4+Pj4NCj4g Pj4+Pj4+Pj4+IDE0IFdoaWxlIHRoZSBjb21tdW5pY2F0aW9uIG9mIHNvbWUgb2YgdGhpcw0KPiA+ Pj4+Pj4+Pj4gaW5mb3JtYXRpb24gZnJvbSBhIFdTREIgdG8gYSBtYXN0ZXIgV1NEIGlzIG9wdGlv bmFsLA0KPiA+Pj4+Pj4+Pj4gbWFzdGVyIFdTRHMgbXVzdCBiZSBhYmxlIHRvIHJlY2VpdmUgYW5k IGludGVycHJldA0KPiA+Pj4+Pj4+Pj4gdGhlc2UuDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4g Rm9vdG5vdGUgMTggc3RhdGVzOg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IDE4IFRoaXMgZm9y bXMgcGFydCBvZiBhIGhhbmRzaGFrZSBwcm90b2NvbCBhbmQgbWF5IGJlDQo+ID4+Pj4+Pj4+PiBh biBhcmVhIHdoZXJlIGluZHVzdHJ5IGNvdWxkIGhhcm1vbmlzZSB3aXRob3V0IHRoZQ0KPiA+Pj4+ Pj4+Pj4gbmVlZCBmb3IgYW4gZXhwbGljaXQgcmVxdWlyZW1lbnQgaW4gdGhlIHJlZ3VsYXRpb25z Lg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IFJlZ2FyZHMNCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+ Pj4+PiBBbmR5DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gKkZyb206KnBhd3MtYm91bmNlc0Bp ZXRmLm9yZw0KPiA+Pj4+Pj4+Pj4gW21haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBC ZWhhbGYgT2YNCj4gPj4+Pj4+Pj4+ICpHYWJvci5CYWprb0Bub2tpYS5jb20gKlNlbnQ6KiAwNSBN YXJjaCAyMDEyIDE5OjQ2DQo+ID4+Pj4+Pj4+PiAqVG86KiBwYXdzQGlldGYub3JnICpTdWJqZWN0 OiogW3Bhd3NdIFdHTEMgZm9yDQo+ID4+Pj4+Pj4+PiBkcmFmdC1pZXRmLXBhd3MtcHJvYmxlbS1z dG10LXVzZWNhc2VzLXJxbXRzLTAzDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gVGhlIGF1dGhv cnMgb2YgdGhlIHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRzIGRyYWZ0DQo+ID4+Pj4+Pj4+PiBo YXZlIGp1c3QgcG9zdGVkIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0IGFuZA0KPiA+Pj4+Pj4+ Pj4gaW5kaWNhdGVkIHRoYXQgdGhlcmUgYXJlIG5vIHVucmVzb2x2ZWQNCj4gPj4+Pj4+Pj4+IGNv bW1lbnRzL2lzc3VlcyB0aGV5IGFyZSBhd2FyZSBvZi4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+ PiBUaGVyZWZvcmUsIEknZCBsaWtlIHRvIGluaXRpYXRlIGEgV0cgTGFzdCBDYWxsIGZvcg0KPiA+ Pj4+Pj4+Pj4gY29tbWVudHMgb24NCj4gPj4+Pj4+Pj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtcGF3cy1wcm9ibGVtLQ0KPiBzdG10LXUNCj4gPj4+Pj4+ Pj4+DQo+ID4+Pj4+Pj4+Pg0KPiBzZWNhDQo+ID4+Pj4+Pj4+PiBzZXMtcnFtdHMtMDMudHh0DQo+ ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IFBsZWFzZSByZXZpZXcgdGhlIGRy YWZ0IGFuZCBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlDQo+ID4+Pj4+Pj4+PiBsaXN0IGJ5IE1h cmNoIDIwdGgsIDIwMTIuDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gSWYgeW91IHJldmlldyB0 aGUgZHJhZnQgYW5kIGhhdmUgbm8gY29tbWVudHMsIHNlbmQgYQ0KPiA+Pj4+Pj4+Pj4gbm90ZSB0 byB0aGUgbGlzdCB0aGF0IHRoZSBkcmFmdCBpcyBnb29kIGFzIGl0IGlzLCB3ZQ0KPiA+Pj4+Pj4+ Pj4gbmVlZCB0aGVzZSBub3RlcyBhcyBtdWNoIGFzIHdlIG5lZWQgdGhlIGFjdHVhbA0KPiA+Pj4+ Pj4+Pj4gY29tbWVudHMuDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gVGhhbmtzLCBHYWJvcg0K PiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IHBhd3MgbWFpbGluZyBsaXN0DQo+IHBhd3NAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo= From scott.probasco@nokia.com Thu Mar 8 09:18:46 2012 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 7E17521F867E for ; Thu, 8 Mar 2012 09:18:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.468 X-Spam-Level: X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4, 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 YeQHExI6Q6wG for ; Thu, 8 Mar 2012 09:18:44 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 086B821F8650 for ; Thu, 8 Mar 2012 09:18:43 -0800 (PST) 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 q28HI1aX032395; Thu, 8 Mar 2012 19:18:02 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.23]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 19:18:01 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.129]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.01.0355.003; Thu, 8 Mar 2012 18:18:00 +0100 From: To: , , Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting Thread-Index: AQHM/U9pVDIWW94XR02640QOS6jbCA== Date: Thu, 8 Mar 2012 17:17:59 +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.14.0.111121 x-originating-ip: [10.243.0.216] Content-Type: text/plain; charset="iso-8859-2" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Mar 2012 17:18:01.0364 (UTC) FILETIME=[6A3EB540:01CCFD4F] X-Nokia-AV: Clean Cc: paws@ietf.org, presnick@qualcomm.com, johnny.dixon@bt.com, chris.cheeseman@bt.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 17:18:46 -0000 Hi, The point from Brian is very relevant: Channel request Channel response Channel acknowledgement What Ofcom does with the information in the acknowledgement does not matter. As the regulator in UK, they write rules that must be followed in order to operate a whitespace radio in the UK. I believe the scope of the WG must be focused on a working solution. If this is simple channel request & response in one regulator's domain, PAWS can support this. If it means a channel request, response and acknowledgement in another regulator's domain, PAWS can support this. As a participating member of the work group, I believe the scope should be basic working solution, not limited to a specific number of messages. Kind Regards, Scott On 3/8/12 11:11 AM, "ext Zuniga, Juan Carlos" wrote: >Peter, Nancy, > >I agree should design a protocol with the best of our current knowledge, >and that should be accounting for all the known regulations at present >time. We should not limit the scope with the purpose of designing a >protocol 'faster'. Our goal is not only to design a WSDB protocol. Our >goal is to design a WSDB protocol that is USEFUL to the community. > >The charter does state that > >"...the group should also reach out to other potential >"customers" for a white space database access method and consider input >from regulatory entities that are involved in the specification of the >rules for secondary use of spectrum in specific radio bands. " > >I think that is exactly what we are doing now. > >Regarding whether the types of requirements belong to #1 or #2, I believe >it is more of #1 type, as the information to be exchanged would be known >after the initial query/response. > >If we know it today, I see no reason why we should not work on it in the >first phase of the work. > >Regards, > >Juan Carlos > >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >> Peter Saint-Andre >> Sent: Thursday, March 08, 2012 11:59 AM >> To: Nancy Bravin >> Cc: paws@ietf.org; johnny.dixon@bt.com; chris.cheeseman@bt.com; Pete >> Resnick >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >> rqmts-03: channel reporting >>=20 >> Hi Nancy, >>=20 >> You are absolutely right that different locales will have different >> rules and requirements. We need to understand those, and work to >> address >> them if possible (although we don't necessarily need to address them >> all >> at the same time). I see several kinds of requirements: >>=20 >> 1. Some requirements might lead to features beyond the query/response >> protocol we've envisioned so far. One example might be real-time >> reporting about the channels that a device is actually using. In my >> opinion, it would be best to handle those in the next phase of work, >> because as far as I can see they are outside the scope of our charter. >>=20 >> 2. Some requirements might be handled through by defining additional >> fields that can be included in the query or response. We definitely >> planned for that when working on the charter with the IESG: >>=20 >> In addition, the particular >> data exchanged between a device and a database might depend on the >> ranges of radio spectrum that are to be used, the requirements of the >> database operators and their governing regulations, and other >> factors. >> Therefore, the database access method and the query/response data >> formats that are exchanged using that method need to be designed for >> extensibility rather than being tied to any specific spectrum, >> country, or phy/mac/air interface. >>=20 >> It's unclear to me right now if the Ofcom requirement fits into #1 or >> #2, which is why we're having this discussion. :) >>=20 >> Peter >>=20 >> On 3/7/12 8:17 PM, Nancy Bravin wrote: >> > Peter and all, >> > >> > I agree that it is important to revisit now, so that in the future, >> > it will be easy to align things in their proper place. Every country >> > may have different regulations, spectrum, policy and what >> > responsibility is in the domain of the system, and what comes under >> > the PAWS charter is important. Maybe some separation might be >> > possible, and dividing and clarifying issues now will help in the >> > future. Certainly it seems that the FCC may change some rules, and >> > we know that Ofcom is not yet finished with their regulations. Canada >> > has their own, and other countries are working on this as well. Just >> > a thought...Sharing is a realistic goal...as is off loading... Or you >> > slim line and every 6 months decide what to incorporate in the >> > protocol based on new information, new ideas, new innovation new >> > regulations and maybe spend more time than you could if addressed >> > now. >> > >> > That way you leave the door open and outside of referencing what is >> > known today, by referencing regulations i.e. Ofcom, FCC, Industry >> > Canada etc as of XX-XX-XXXX date. Out of scope not something we know >> > enough about to say at this point, In my opinion. >> > >> > My 2 cents.. >> > >> > Sincerely, Nancy >> > >> > On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote: >> > >> >> >> >> >> >> As your responsible Area Director (until March 28, when Pete >> >> Resnick will take over from me), I have reviewed this thread. >> >> >> >> In my opinion (I am happy to be proven wrong), this new requirement >> >> goes beyond what the charter defined as the scope of this working >> >> group, which was to enable a device to discover the white space >> >> available to it in its current location. Reporting usage back to >> >> the database is simply not mentioned in the charter. >> >> >> >> Earlier in this thread, Andy Sago wrote: >> >> >> >> There's no language I can find in the charter that explicitly puts >> >> this out of scope. >> >> >> >> An IETF charter defines what the working group shall work on. Many >> >> interesting features could be developed here. However, it is not >> >> the job of the charter to mention explicitly that each of those >> >> interesting features is out of scope. >> >> >> >> The charter does say: >> >> >> >> Once the device learns of the available white space (e.g., in a TV >> >> white space implementation, the list of available channels at that >> >> location), it can then select one of the bands from the list and >> >> begin to transmit and receive on the selected band. >> >> >> >> This text might have assumed that no further communication or >> >> authorization was required in order to select one of the bands from >> >> the list and then transmit/receive. Perhaps that assumption was >> >> mistaken. If so, it would be good to have a discussion about that, >> >> so we can determine if we need to revisit the assumptions we made >> >> early on. If in fact we made some faulty or limited assumptions, >> >> then let's get that out in the open. >> >> >> >> Peter >> >> >> >> On 3/7/12 9:40 AM, Rosen, Brian wrote: >> >>> I'd also suggest that our >> >>> charter limitation is really support for sharing of whitespace by >> >>> whitespace devices. Reporting what you use is not sharing, it's >> >>> just data gathering. >> >>> >> >>> The point of excluding sharing was to eliminate the complexities >> >>> of what constituted fairness, and what kinds of communication >> >>> might be needed between databases, where more than one could >> >>> supply available whitespace in a band. This doesn't have any of >> >>> those issues, As long as it's just sending information, I don't >> >>> have a problem. Once the database is supposed to do anything >> >>> with it that involves changing what spectrum it reports, then I >> >>> think we cross the line. >> >>> >> >>> Brian >> >>> >> >>> On Mar 6, 2012, at 12:28 PM, >> >>> wrote: >> >>> >> >>>> Joel >> >>>> >> >>>> Indeed, the regulator has not described the process or provided >> >>>> a flow diagram, so there may be some wrinkles, but we need to >> >>>> provide for their intent. To answer your question, the channels >> >>>> that the master will use are sent in a separate message >> >>>> (described in P.12 ter), that occurs after the master receives >> >>>> the response to its channel request, but before the master can >> >>>> transmit. At this point, it knows what channels are available, >> >>>> and which one it will use. As far as the slaves are concerned, >> >>>> as they associate, the master will need to gather their details >> >>>> and send further channel usage messages to the database on >> >>>> their behalf. >> >>>> >> >>>> Regards >> >>>> >> >>>> Andy >> >>>> >> >>>> -----Original Message----- From: paws-bounces@ietf.org >> >>>> [mailto:paws-bounces@ietf.org] On Behalf Of Joel M. Halpern >> >>>> Sent: 06 March 2012 17:05 To: scott.probasco@nokia.com Cc: >> >>>> paws@ietf.org; Cheeseman,CJ,Chris,COD R; Dixon,JS,Johnny,COD R >> >>>> Subject: Re: [paws] WGLC for >> >>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel >> >>>> reporting >> >>>> >> >>>> Ahh. I think I see where the request and my understanding >> >>>> divurge. If the idea here is that the master must provide, in >> >>>> the request, an indication of what channels it expects to use, >> >>>> I can at least understand that. I will return to technical >> >>>> concerns in a moment. >> >>>> >> >>>> However, when you say "provide channel usage information, in >> >>>> order to evaluate interference", what that says to me is >> >>>> providing, during operation, information as to what channels >> >>>> are being used, and at what power levels. That is what would >> >>>> be needed to analyze actual interference effects. And that is >> >>>> out of scope as I understand our scope. >> >>>> >> >>>> I do see a technical difficulty with having the master provide, >> >>>> as part of either registering or requesting spectrum >> >>>> information, what channels it intends to use. It doesn;t know >> >>>> what channels it intends to use. It intends to use some number >> >>>> of available channels. It will figure out which ones when it >> >>>> is told what is available. How can it send that information in >> >>>> the request? >> >>>> >> >>>> Yours, Joel >> >>>> >> >>>> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: >> >>>>> Hi, >> >>>>> >> >>>>> There is a similarity here with device ID. In context of PAWS >> >>>>> we are not concerned with why a device ID is required by a >> >>>>> regulator, we accept it is a requirement from a regulator and >> >>>>> include it to the protocol. Ofcom identifies in 3.18& 3.19 >> >>>>> that channel usage information is required and thus we need >> >>>>> to include this information. Since the master must provide >> >>>>> this information prior to transmitting, PAWS will not >> >>>>> function in the UK without this information and thus I >> >>>>> believe channel usage information is integral to the channel >> >>>>> request& response messaging. >> >>>>> >> >>>>> Kind Regards, Scott >> >>>>> >> >>>>> >> >>>>> On 3/6/12 10:30 AM, "ext Joel M. >> >>>>> Halpern" wrote: >> >>>>> >> >>>>>> I would draw a distinction. Ofcom regulations about >> >>>>>> whitespace requests are very much relevant. Ofcom >> >>>>>> regulations about notification of dynamic behavior (which >> >>>>>> spectrum is being used) are not in scope as I understand >> >>>>>> the earlier discussions, particularly the chartering >> >>>>>> discussions. >> >>>>>> >> >>>>>> Yours, Joel >> >>>>>> >> >>>>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: >> >>>>>>> >> >>>>>>> The ofcom requirements are very much relevant to the >> >>>>>>> scope of the PAWS WG. The only other regulatory >> >>>>>>> requirements that we have today is the FCC. Ofcom >> >>>>>>> requirements are a good addition to the set. >> >>>>>>> >> >>>>>>> -Raj >> >>>>>>> >> >>>>>>> On 3/6/12 10:03 AM, "ext >> >>>>>>> andy.sago@bt.com" wrote: >> >>>>>>> >> >>>>>>>> Hi Joel >> >>>>>>>> >> >>>>>>>> There's no language I can find in the charter that >> >>>>>>>> explicitly puts this out of scope. On the other hand, >> >>>>>>>> the charter says that the group will "consider input >> >>>>>>>> from regulatory entities", and this is one of the >> >>>>>>>> requirements from Ofcom that they have just published. >> >>>>>>>> The protocol will be worthless for the UK if it omits >> >>>>>>>> some requirements. >> >>>>>>>> >> >>>>>>>> Regards >> >>>>>>>> >> >>>>>>>> Andy >> >>>>>>>> >> >>>>>>>> -----Original Message----- From: Joel M. Halpern >> >>>>>>>> [mailto:jmh@joelhalpern.com] Sent: 06 March 2012 15:53 >> >>>>>>>> To: Sago,AJ,Andy,COD R Cc: paws@ietf.org; >> >>>>>>>> Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for >> >>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel >> >>>>>>>> reporting >> >>>>>>>> >> >>>>>>>> As I understand, the information you are asking for is >> >>>>>>>> explicitly out of scope for the working group. Yours, >> >>>>>>>> Joel >> >>>>>>>> >> >>>>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >> >>>>>>>>> All >> >>>>>>>>> >> >>>>>>>>> Comparing the draft with the Ofcom requirements at >> >>>>>>>>> http://www.cept.org/Documents/se- >> 43/4161/SE43(12)Info03_Draft-UK-r >> >>>>>>>>> >> >>>>>>>>> >> egul >> >>>>>>>>> atory-requirements-for-white-space-devices-in-the-UHF-TV- >> band, >> >>>>>>>>> >> >>>>>>>>> >> I believe the WG draft is deficient in the area of reporting >> >>>>>>>>> frequencies and powers actually used by masters and >> >>>>>>>>> slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom >> >>>>>>>>> intends to collect this data to assesses the impact >> >>>>>>>>> of aggregate interference into other services. It >> >>>>>>>>> would also provide usage information (frequency in >> >>>>>>>>> use) that would inform the operation of a kill switch >> >>>>>>>>> capability. I suggest this deficiency can be remedied >> >>>>>>>>> with the following changes: >> >>>>>>>>> >> >>>>>>>>> New P requirements (probably best placed following >> >>>>>>>>> P.12): >> >>>>>>>>> >> >>>>>>>>> P.12bis: The protocol MUST support a channel usage >> >>>>>>>>> message from the slave device to the master device. >> >>>>>>>>> The channel usage message MUST include parameters as >> >>>>>>>>> required by local regulatory requirement. These >> >>>>>>>>> parameters MAY include device ID, manufacturer's >> >>>>>>>>> serial number, channel usage and power level >> >>>>>>>>> information. >> >>>>>>>>> >> >>>>>>>>> P.12ter: The protocol MUST support a channel usage >> >>>>>>>>> message from the master device to the database. The >> >>>>>>>>> channel usage message MUST include parameters as >> >>>>>>>>> required by local regulatory requirement for the >> >>>>>>>>> master and its associated slaves. These parameters >> >>>>>>>>> MAY include device ID, manufacturer's serial number, >> >>>>>>>>> channel usage and power level information. >> >>>>>>>>> >> >>>>>>>>> P.12qua: The protocol MUST support a channel usage >> >>>>>>>>> message acknowledgement. >> >>>>>>>>> >> >>>>>>>>> New O requirements (probably best placed following >> >>>>>>>>> O13): >> >>>>>>>>> >> >>>>>>>>> O.13bis: According to local regulatory policy, after >> >>>>>>>>> connecting to a master device's radio network a slave >> >>>>>>>>> device MAY inform the master device of the actual >> >>>>>>>>> channel usage. The slave MUST include parameters >> >>>>>>>>> required by local regulatory policy, e.g. device ID, >> >>>>>>>>> manufacturer's serial number, channel usage and power >> >>>>>>>>> level information. >> >>>>>>>>> >> >>>>>>>>> O.13ter: According to local regulatory policy, a >> >>>>>>>>> master device MAY inform the database of the actual >> >>>>>>>>> channel usage of the master and its slaves. The >> >>>>>>>>> master MUST include parameters required by local >> >>>>>>>>> regulatory policy, e.g. device ID, manufacturer's >> >>>>>>>>> serial number, channel usage and power level >> >>>>>>>>> information of the master and its slaves. >> >>>>>>>>> >> >>>>>>>>> New steps could be introduced into one or more use >> >>>>>>>>> cases to cover these Ofcom requirements, e.g. new >> >>>>>>>>> steps 6bis and 9bis in the hotspot use case at >> >>>>>>>>> 4.2.1: >> >>>>>>>>> >> >>>>>>>>> 6bis. Prior to initiating transmission, if required >> >>>>>>>>> by local regulation, the master/AP informs the >> >>>>>>>>> database of the channel and power level it has >> >>>>>>>>> chosen. This is repeated for each slave that >> >>>>>>>>> associated with the master. >> >>>>>>>>> >> >>>>>>>>> 9bis. Prior to initiating transmission, if required >> >>>>>>>>> by local regulation, the slave informs the master/AP >> >>>>>>>>> of the channel and power level it has chosen, and the >> >>>>>>>>> master/AP relays this information to the database. >> >>>>>>>>> >> >>>>>>>>> - end of new text - >> >>>>>>>>> >> >>>>>>>>> For information, for those not accessing the url in >> >>>>>>>>> the first paragraph of this email, the full Ofcom >> >>>>>>>>> requirements leading to this new PAWS text are as >> >>>>>>>>> follows: >> >>>>>>>>> >> >>>>>>>>> 3.18 After receiving instructions from a WSDB in >> >>>>>>>>> relation to the maximum permitted EIRPs over the DTT >> >>>>>>>>> channels, and prior to initiating transmissions >> >>>>>>>>> within the UHF TV band, a master WSD must communicate >> >>>>>>>>> to the WSDB the following information: >> >>>>>>>>> >> >>>>>>>>> 3.18.1 The lower and upper frequency boundaries^13 of >> >>>>>>>>> the in-block emissions of the master WSD, and those >> >>>>>>>>> of the in-block emissions of its associated slaves. A >> >>>>>>>>> lower frequency will be specified as (470 + 8k + >> >>>>>>>>> 0.2n) MHz, with the corresponding upper frequency >> >>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3=AE4 k 3=AE4 >> >>>>>>>>> 39, 0 3=AE4 n 3=AE4 39, 1 3=AE4 m 3=AE4 40, and n< m. >> >>>>>>>>> >> >>>>>>>>> 3.18.2 The maximum in-block EIRP spectral densities >> >>>>>>>>> (in dBm/(0.2 MHz)) that the master WSD, and its >> >>>>>>>>> associated slaves, actually radiate between each >> >>>>>>>>> reported lower frequency boundary and its >> >>>>>>>>> corresponding upper frequency boundary. >> >>>>>>>>> >> >>>>>>>>> Footnote 13 states: >> >>>>>>>>> >> >>>>>>>>> The use of upper and lower frequency boundaries >> >>>>>>>>> (defined over a 200 kHz raster) allows a WSDB to >> >>>>>>>>> collect more granular information with regards to the >> >>>>>>>>> usage of the frequency resource by narrowband WSD >> >>>>>>>>> technologies. The upper and lower frequencies of a >> >>>>>>>>> boundary pair do not straddle a DTT channel boundary. >> >>>>>>>>> Note that a WSD may transmit over multiple, >> >>>>>>>>> non-contiguous, whole DTT channels or fractions of >> >>>>>>>>> DTT channels. >> >>>>>>>>> >> >>>>>>>>> 3.19 A master WSD must be able to receive the >> >>>>>>>>> following information^14 from a WSDB: >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in the >> >>>>>>>>> context of 3.18, that the reported information on the >> >>>>>>>>> DTT channels and EIRP spectral densities actually >> >>>>>>>>> used by the master and slave WSDs were received >> >>>>>>>>> successfully by the WSDB^18 ]. >> >>>>>>>>> >> >>>>>>>>> Footnote 14 states: >> >>>>>>>>> >> >>>>>>>>> 14 While the communication of some of this >> >>>>>>>>> information from a WSDB to a master WSD is optional, >> >>>>>>>>> master WSDs must be able to receive and interpret >> >>>>>>>>> these. >> >>>>>>>>> >> >>>>>>>>> Footnote 18 states: >> >>>>>>>>> >> >>>>>>>>> 18 This forms part of a handshake protocol and may be >> >>>>>>>>> an area where industry could harmonise without the >> >>>>>>>>> need for an explicit requirement in the regulations. >> >>>>>>>>> >> >>>>>>>>> Regards >> >>>>>>>>> >> >>>>>>>>> Andy >> >>>>>>>>> >> >>>>>>>>> *From:*paws-bounces@ietf.org >> >>>>>>>>> [mailto:paws-bounces@ietf.org] *On Behalf Of >> >>>>>>>>> *Gabor.Bajko@nokia.com *Sent:* 05 March 2012 19:46 >> >>>>>>>>> *To:* paws@ietf.org *Subject:* [paws] WGLC for >> >>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >> >>>>>>>>> >> >>>>>>>>> The authors of the use cases and requirements draft >> >>>>>>>>> have just posted a new version of the draft and >> >>>>>>>>> indicated that there are no unresolved >> >>>>>>>>> comments/issues they are aware of. >> >>>>>>>>> >> >>>>>>>>> Therefore, I'd like to initiate a WG Last Call for >> >>>>>>>>> comments on >> >>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-paws-problem- >> stmt-u >> >>>>>>>>> >> >>>>>>>>> >> seca >> >>>>>>>>> ses-rqmts-03.txt >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> Please review the draft and send your comments to the >> >>>>>>>>> list by March 20th, 2012. >> >>>>>>>>> >> >>>>>>>>> If you review the draft and have no comments, send a >> >>>>>>>>> note to the list that the draft is good as it is, we >> >>>>>>>>> need these notes as much as we need the actual >> >>>>>>>>> comments. >> >>>>>>>>> >> >>>>>>>>> Thanks, Gabor >> >>>>>>>>> >> >>>>>>>>> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From scott.probasco@nokia.com Thu Mar 8 09:19:26 2012 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 4C91121F864E for ; Thu, 8 Mar 2012 09:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.677 X-Spam-Level: X-Spam-Status: No, score=-4.677 tagged_above=-999 required=5 tests=[AWL=1.694, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 KXHtegeIaOQs for ; Thu, 8 Mar 2012 09:19:24 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 53EFC21F8650 for ; Thu, 8 Mar 2012 09:19:24 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q28HJHqE000947; Thu, 8 Mar 2012 19:19:21 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 19:19:19 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.129]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0355.003; Thu, 8 Mar 2012 18:19:18 +0100 From: To: , , Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03 Thread-Index: Acz7CHkh/FNx3kOiQQWaHcNbcyzaWwArxp5AAFdV14A= Date: Thu, 8 Mar 2012 17:19:17 +0000 Message-ID: In-Reply-To: <619CDADDCCD2B44380834BE8BF6F7141406914613F@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.14.0.111121 x-originating-ip: [10.243.0.216] Content-Type: multipart/alternative; boundary="_000_CB7E3B9B13BBBscottprobasconokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 08 Mar 2012 17:19:19.0238 (UTC) FILETIME=[98A95660:01CCFD4F] X-Nokia-AV: Clean Cc: johnny.dixon@bt.com, chris.cheeseman@bt.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 17:19:26 -0000 --_000_CB7E3B9B13BBBscottprobasconokiacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Andy, I will include this in the update. Kind Regards, Scott From: ext com > Date: Tue, 6 Mar 2012 17:45:13 +0000 To: "paws@ietf.org" >, Gabor Bajko > Cc: >, > Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03 All I believe that the WG draft has an omission in P.11 relating to the paramet= ers that MAY be sent from the master device to the database. The data model= in D.1 allows for location uncertainty, height and height uncertainty. The= se items are not mentioned in the parameters in P.11, and all (except heigh= t uncertainty) are required by Ofcom in http://www.cept.org/Documents/se-43= /4161/SE43(12)Info03_Draft-UK-regulatory-requirements-for-white-space-devic= es-in-the-UHF-TV-band. I propose the following change: P.11: The protocol MUST support a channel query request from the master de= vice to the database. The channel query request message MUST include param= eters as required by local regulatory requirement. These parameters MAY in= clude device location, location uncertainty, device height, height = uncertainty, device ID, manufacturer's serial number, and antenna = characteristic information. Regards Andy From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com Sent: 05 March 2012 19:46 To: paws@ietf.org Subject: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03 The authors of the use cases and requirements draft have just posted a new = version of the draft and indicated that there are no unresolved comments/is= sues they are aware of. Therefore, I'd like to initiate a WG Last Call for comments on http://www.i= etf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rqmts-03.txt Please review the draft and send your comments to the list by March 20th, 2= 012. If you review the draft and have no comments, send a note to the list that = the draft is good as it is, we need these notes as much as we need the actu= al comments. Thanks, Gabor _______________________________________________ paws mailing list paws@ietf= .org https://www.ietf.org/mailman/listinfo/paws --_000_CB7E3B9B13BBBscottprobasconokiacom_ Content-Type: text/html; charset="us-ascii" Content-ID: <36D353652CD36549AA7C43172E0F8A08@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable
Thanks Andy, I will include this in the update.

Kind Regards,
Scott

From: ext com <andy.sago@bt.com>
Date: Tue, 6 Mar 2012 17:45:13 += ;0000
To: "paws@ietf.org" <paws@i= etf.org>, Gabor Bajko <G= abor.Bajko@nokia.com>
Cc: <johnny.dixon@bt.com>, <chris.cheeseman@bt.com>
Subject: Re: [paws] WGLC for draft-= ietf-paws-problem-stmt-usecases-rqmts-03

All

=  

I bel= ieve that the WG draft has an omission in P.11 relating to the parameters t= hat MAY be sent from the master device to the database. The data model in D= .1 allows for location uncertainty, height and height uncertainty. These items are not mentioned in the parame= ters in P.11, and all (except height uncertainty) are required by Ofcom in http://www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-regulatory= -requirements-for-white-space-devices-in-the-UHF-TV-band. I propose the= following change:

=  

P.11:=   The protocol MUST support a channel query request from the master de= vice to the database.  The channel query request message MUST include = parameters as required by local regulatory requirement.  These parameters MAY include device location, <Insert>location uncer= tainty, device height, height uncertainty, </Insert>device ID, manufa= cturer's serial number, and antenna characteristic information.<= /span>

=  

Regar= ds

=  

Andy<= o:p>

=  

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@no= kia.com
Sent: 05 March 2012 19:46
To: paws@ietf.org
Subject: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts= -03

 

The authors of the use cases= and requirements draft have just posted a new version of the draft and ind= icated that there are no unresolved comments/issues they are aware of.=

&= nbsp;

Theref= ore, I'd like to initiate a WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-r= qmts-03.txt

&= nbsp;

Please= review the draft and send your comments to the list by March 20th, 2012.

&= nbsp;

If you= review the draft and have no comments, send a note to the list that the dr= aft is good as it is, we need these notes as much as we need the actual com= ments.

&= nbsp;

Thanks= , Gabor

 

_______________________________________________ paws mailing list paws@ietf.org ht= tps://www.ietf.org/mailman/listinfo/paws --_000_CB7E3B9B13BBBscottprobasconokiacom_-- From scott.probasco@nokia.com Thu Mar 8 09:20:06 2012 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 4981121F847D for ; Thu, 8 Mar 2012 09:20:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, 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 u+sw+GyMXieP for ; Thu, 8 Mar 2012 09:20:03 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 644B721F847C for ; Thu, 8 Mar 2012 09:20:03 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q28HK1MN001684; Thu, 8 Mar 2012 19:20:01 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.26]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 19:20:00 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.129]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.01.0355.003; Thu, 8 Mar 2012 18:19:55 +0100 From: To: Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting Thread-Index: AQHM+7qBJZkKE/OsEE6WAJSH4Dz7PpZdfy+A//+SKwCAAHc5wP//kfoAgAB2qjCAAqFTAA== Date: Thu, 8 Mar 2012 17:19:54 +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.14.0.111121 x-originating-ip: [10.243.0.216] Content-Type: multipart/alternative; boundary="_000_CB7E3CE913BD6scottprobasconokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 08 Mar 2012 17:20:00.0565 (UTC) FILETIME=[B14B5650:01CCFD4F] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 17:20:06 -0000 --_000_CB7E3CE913BD6scottprobasconokiacom_ Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGkgR2VyYWxkLA0KDQpJIGFncmVlIHRoYXQgc29tZSB3aXJlbGVzcyBzdGFuZGFyZHMgd2lsbCBl bGVjdCB0byBpbXBsZW1lbnQgc2lnbmFsaW5nIHJlbGF0ZWQgdG8gZGF0YWJhc2UgYWNjZXNzLCBl LmcuIHNpZ25hbGluZyBiZXR3ZWVuIHRoZSBzbGF2ZSB0aGUgYW5kIHRoZSBtYXN0ZXIuIEJ1dCBQ QVdTIGlzIGluZGVwZW5kZW50IG9mIHRoZSByYWRpbyBhbmQgdGhlcmVmb3JlIGNhbm5vdCBleHBl Y3QgdGhhdCBwb3J0aW9ucyBvZiB0aGUgbmVjZXNzYXJ5IHNpZ25hbGluZyB3aWxsIGJlIGltcGxl bWVudGVkIGVsc2V3aGVyZS4gSW4gdGhlIHNjb3BlIG9mIHRoZSBXRyB3ZSBkb24ndCBkaWZmZXJl bnRpYXRlIGJldHdlZW4gYSBtYXN0ZXIgb3Igc2xhdmUsIHdlIHNpbXBseSBhZGRyZXNzIHByb3Zp ZGluZyBjaGFubmVsIGxpc3RzIHRvIGVuc3VyZSBwcm9wZXIgb3BlcmF0aW9uIG9mIGEgd2hpdGUg c3BhY2UgcmFkaW8gbmV0d29yay4NCg0KUGVyaGFwcyB0aGUgY2hhaXJzIGNvdWxkIGFsbG9jYXRl IHNvbWUgdGltZSBvbiB0aGUgYWdlbmRhIGluIHRoZSBjb21pbmcgbWVldGluZyB0byBkaXNjdXNz IHRoaXMgdG9waWMuDQoNCktpbmQgUmVnYXJkcywNClNjb3R0DQoNCg0KRnJvbTogZXh0IENob3Vp bmFyZCA8Z2VyYWxkLmNob3VpbmFyZEBzeW1wYXRpY28uY2E8bWFpbHRvOmdlcmFsZC5jaG91aW5h cmRAc3ltcGF0aWNvLmNhPj4NCkRhdGU6IFR1ZSwgNiBNYXIgMjAxMiAxMzoxODoyNSAtMDUwMA0K VG86IFNjb3R0IFByb2Jhc2NvIDxzY290dC5wcm9iYXNjb0Bub2tpYS5jb208bWFpbHRvOnNjb3R0 LnByb2Jhc2NvQG5va2lhLmNvbT4+DQpDYzogInBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0 Zi5vcmc+IiA8cGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBS RTogW3Bhd3NdIFdHTEMgZm9yIGRyYWZ0LWlldGYtcGF3cy1wcm9ibGVtLXN0bXQtdXNlY2FzZXMt cnFtdHMtMDM6IGNoYW5uZWwgcmVwb3J0aW5nDQoNClNjb3R0LA0KDQpJIGJlbGlldmUgdGhhdCB0 aGlzIGNvdWxkIGJlIGtlcHQgc2ltcGxlIGJ5IGFzc3VtaW5nIHRoYXQgaWYgYSBkZXZpY2UgbmVl ZHMgdG8gZGlyZWN0bHkgY29tbXVuaWNhdGUgaXRzIGluZm9ybWF0aW9uIHRvIHRoZSBkYXRhYmFz ZSwgaXQgY2FuIGJlIGNvbnNpZGVyZWQgZm9yIHRoZSBwdXJwb3NlIG9mIFBBV1MgYXMgYSChsG1h c3RlcqGxIGRldmljZS4gSWYgdGhpcyBjYW4gYmUgZG9uZSB0aHJvdWdoIGEgcHJveHkgZGV2aWNl IGluIGJldHdlZW4sIHRoZW4gdGhlIGRldmljZSBuZWVkcyB0byBiZSBzbGF2ZWQgdG8gdGhpcyBk ZXZpY2UgaW4gYmV0d2VlbiB3aGljaCB3aWxsIHRoZW4gYmUgY29uc2lkZXJlZCBhcyB0aGUgobBt YXN0ZXKhsS4gSW4gc3VjaCBjYXNlLCB0aGUgd2lyZWxlc3Mgc3RhbmRhcmQgdXNlZCBiZXR3ZWVu IHRoZXNlIGRldmljZXMgbmVlZHMgdG8gaGF2ZSBhbGwgdGhlIG5lY2Vzc2FyeSBtZWFucyB0byB0 cmFuc21pdCB0aGUgbmVjZXNzYXJ5IGluZm9ybWF0aW9uIGZyb20gdGhlIKGwc2xhdmWhsSB0byBp dHMgobBtYXN0ZXKhsSB0byBtZWV0IHRoZSByZXF1aXJlbWVudHMgb2Ygd2hpdGUgc3BhY2Ugb3Bl cmF0aW9uLiAgVGhlIHdheSBpdCBpcyBkb25lIGNhbiB2YXJ5IGZyb20gb25lIHRlY2hub2xvZ3kg dG8gYW5vdGhlci4gVGhpcyB3YXMsIHRoZSBzY29wZSBvZiBQQVdTIGlzIGxpbWl0ZWQgdG8gdGhl IGxpbmsgYmV0d2VlbiB0aGUgbWFzdGVyIGFuZCB0aGUgZGF0YWJhc2UgYW5kIG5vdCBiZXR3ZWVu IHRoZSBzbGF2ZSBhbmQgdGhlIG1hc3Rlci4NCg0KR2VyYWxkDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpGcm9tOiBzY290dC5wcm9iYXNjb0Bub2tpYS5jb208bWFpbHRvOnNj b3R0LnByb2Jhc2NvQG5va2lhLmNvbT4gW21haWx0bzpzY290dC5wcm9iYXNjb0Bub2tpYS5jb21d DQpTZW50OiBUdWVzZGF5LCAwNiBNYXJjaCwgMjAxMiAxMzowNQ0KVG86IGdlcmFsZC5jaG91aW5h cmRAc3ltcGF0aWNvLmNhPG1haWx0bzpnZXJhbGQuY2hvdWluYXJkQHN5bXBhdGljby5jYT4NCkNj OiBwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtwYXdz XSBXR0xDIGZvciBkcmFmdC1pZXRmLXBhd3MtcHJvYmxlbS1zdG10LXVzZWNhc2VzLXJxbXRzLTAz OiBjaGFubmVsIHJlcG9ydGluZw0KDQpIaSBHZXJhbGQsDQoNCkkgYWdyZWUgd2l0aCB5b3UgdGhh dCBzb21lIHdpcmVsZXNzIHN0YW5kYXJkcyB3aWxsIGluY2x1ZGUgc2lnbmFsaW5nIHRoYXQgc3Vw cG9ydHMgZGF0YWJhc2UgYWNjZXNzLiBCdXQgUEFXUyBpcyBub3Qgc3BlY2lmaWMgdG8gYW55IHBh cnRpY3VsYXIgcmFkaW8gdGVjaG5vbG9neSwgd2UgY2Fubm90IGV4cGVjdCB0aGF0IGFsbCByYWRp byB0ZWNobm9sb2dpZXMgd2lsbCBpbmNsdWRlIHNvbWUgY29tcG9uZW50cyBvZiB0aGUgc2lnbmFs aW5nIGZvciBkYXRhYmFzZSBhY2Nlc3MuIFBBV1Mgc2hvdWxkIGluY2x1ZGUgYWxsIG5lY2Vzc2Fy eSBtZXNzYWdlcyBmb3IgY29udGFjdCBiZXR3ZWVuIHRoZSBkZXZpY2UgYW5kIHRoZSBkYXRhYmFz ZSwgd2l0aG91dCBwcmVzdW1wdGlvbiBvZiB0aGUgdW5kZXJseWluZyByYWRpbyB0ZWNobm9sb2d5 Lg0KDQpLaW5kIFJlZ2FyZHMsDQpTY290dA0KDQpGcm9tOiBleHQgQ2hvdWluYXJkIDxnZXJhbGQu Y2hvdWluYXJkQHN5bXBhdGljby5jYTxtYWlsdG86Z2VyYWxkLmNob3VpbmFyZEBzeW1wYXRpY28u Y2E+Pg0KRGF0ZTogVHVlLCA2IE1hciAyMDEyIDEyOjQ0OjA5IC0wNTAwDQpUbzogU2NvdHQgUHJv YmFzY28gPHNjb3R0LnByb2Jhc2NvQG5va2lhLmNvbTxtYWlsdG86c2NvdHQucHJvYmFzY29Abm9r aWEuY29tPj4NCkNjOiAicGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4iIDxwYXdz QGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBbcGF3c10gV0dM QyBmb3IgZHJhZnQtaWV0Zi1wYXdzLXByb2JsZW0tc3RtdC11c2VjYXNlcy1ycW10cy0wMzogY2hh bm5lbCByZXBvcnRpbmcNCg0KU2NvdHQsDQoNCkkgYW0gZmluZSB3aXRoIHlvdXIgc2Vjb25kIHNl bnRlbmNlLiAgSG93ZXZlciwgSSBoYXZlIHNvbWUgZGlmZmljdWx0eSB3aXRoIHlvdXIgdGhpcmQg c2VudGVuY2Ugc2luY2UgdGhpcyB3b3VsZCBtZWFuIHRoYXQgdGhlIElFVEYtUEFXUyB3b3VsZCBn ZXQgaW50byBkZWZpbmluZyB0aGUgc2lnbmFsaW5nIGRldGFpbHMgYmV0d2VlbiB0aGUgc2xhdmUg YW5kIHRoZSBtYXN0ZXIgZGV2aWNlcy4gSSBiZWxpZXZlIHRoaXMgc2hvdWxkIGJlIGxlZnQgdG8g dGhlIHdpcmVsZXNzIHN0YW5kYXJkLiAgT2J2aW91c2x5LCBoYXZpbmcgdGhpcyBpbmZvcm1hdGlv biBhdmFpbGFibGUgYXQgdGhlIG1hc3RlciB3b3VsZCBiZWNvbWUgYSByZXF1aXJlbWVudCB0aGF0 IHRoZSB3aXJlbGVzcyBzdGFuZGFyZCB3b3VsZCBoYXZlIHRvIG1lZXQgdG8gYmUgYWJsZSB0byBv cGVyYXRlIGluIHdoaXRlIHNwYWNlLiBUaGUgd2F5IGl0IHdvdWxkIGJlIGRvbmUgd291bGQgYmUg aW50ZXJuYWwgdG8gdGhlIHdpcmVsZXNzIHN0YW5kYXJkLiAgUEFXUyB3b3VsZCB0YWtlIGl0IGZy b20gdGhlIG1hc3RlciB0byB0aGUgZGF0YWJhc2UuDQoNCkdlcmFsZA0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KRnJvbTogc2NvdHQucHJvYmFzY29ATm9raWEuY29tPG1haWx0 bzpzY290dC5wcm9iYXNjb0BOb2tpYS5jb20+IFttYWlsdG86c2NvdHQucHJvYmFzY29ATm9raWEu Y29tXQ0KU2VudDogVHVlc2RheSwgMDYgTWFyY2gsIDIwMTIgMTI6MzINClRvOiBnZXJhbGQuY2hv dWluYXJkQHN5bXBhdGljby5jYTxtYWlsdG86Z2VyYWxkLmNob3VpbmFyZEBzeW1wYXRpY28uY2E+ DQpDYzogcGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb cGF3c10gV0dMQyBmb3IgZHJhZnQtaWV0Zi1wYXdzLXByb2JsZW0tc3RtdC11c2VjYXNlcy1ycW10 cy0wMzogY2hhbm5lbCByZXBvcnRpbmcNCg0KSGkgR2VyYWxkLA0KDQpJIGJlbGlldmUgQW5keSdz IHByb3Bvc2FsIGFncmVlcyB3aXRoIHlvdXIgc3VnZ2VzdGlvbiBiZWxvdy4gTG9va2luZyBhdCBP LjEzYmlzLCB0aGUgc2xhdmUgTUFZIHNlbmQgdGhlIGNoYW5uZWwgdXNhZ2UgaW5mb3JtYXRpb24g YW5kIGlmIGl0IGRvZXMgc28sIGl0IE1VU1QgaW5jbHVkZSB0aGUgZm9sbG93aW5nIHZhcmlhYmxl cy4gSSB0aGluayBQLjEyYmlzIGlzIGFwcHJvcHJpYXRlIHNpbmNlIHRoZSBtZXNzYWdlIE1VU1Qg YmUgZGVmaW5lZCBieSB0aGUgcHJvdG9jb2wgaW5vcmRlciB0byBoYXZlIHRoZSBPUFRJT04gb2Yg c2VuZGluZyBpdC4gV2hlbiB0aGVzZSB0d28gcmVxdWlyZW1lbnRzIGFyZSBjb25zaWRlcmVkIGpv aW50bHkgZG9lcyB0aGlzIHByb3ZpZGUgdGhlIGltcGxlbWVudGF0aW9uIGZsZXhpYmlsaXR5IHlv dSBhcmV0aGlua2luZyBvZj8NCg0KS2luZCBSZWdhcmRzLA0KU2NvdHQNCg0KRnJvbTogZXh0IENo b3VpbmFyZCA8Z2VyYWxkLmNob3VpbmFyZEBzeW1wYXRpY28uY2E8bWFpbHRvOmdlcmFsZC5jaG91 aW5hcmRAc3ltcGF0aWNvLmNhPj4NCkRhdGU6IFR1ZSwgNiBNYXIgMjAxMiAxMjoxMzowNSAtMDUw MA0KVG86IFNjb3R0IFByb2Jhc2NvIDxzY290dC5wcm9iYXNjb0Bub2tpYS5jb208bWFpbHRvOnNj b3R0LnByb2Jhc2NvQG5va2lhLmNvbT4+DQpDYzogInBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NA aWV0Zi5vcmc+IiA8cGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4+DQpTdWJqZWN0 OiBSRTogW3Bhd3NdIFdHTEMgZm9yIGRyYWZ0LWlldGYtcGF3cy1wcm9ibGVtLXN0bXQtdXNlY2Fz ZXMtcnFtdHMtMDM6IGNoYW5uZWwgcmVwb3J0aW5nDQoNClNjb3R0LA0KDQpJIGFtIGZpbmUgd2l0 aCB5b3VyIGFwcHJvYWNoIGFzIGxvbmcgYXMgdGhlIHRleHQgc2F5cyBzb21ldGhpbmcgYXMgZm9s bG93czogobB0aGUgb3BlcmF0aW5nIGNoYW5uZWwgb2YgdGhlIHNsYXZlIG5lZWRzIHRvIGJlIHBy b3ZpZGVkIHRvIHRoZSBkYXRhYmFzZaGxIHJhdGhlciB0aGFuOiChsHRoZSBzbGF2ZSBuZWVkcyB0 byBwcm92aWRlIHRoZSBkYXRhYmFzZSB3aXRoIGl0cyBvcGVyYXRpbmcgY2hhbm5lbKGxLiAgVGhp cyB3YXksIHRoaXMgaW5mb3JtYXRpb24gY2FuIGJlIHByb3ZpZGVkIGJ5IGVpdGhlciB0aGUgc2xh dmUgb3IgdGhlIG1hc3Rlciwgbm90IG1ha2luZyBpdCBtYW5kYXRvcnkgdGhhdCB0aGUgobBzbGF2 ZaGxIGhhcyB0byBkbyBpdCBpZiB0aGUgbWFzdGVyIGtub3dzIHRoZSBpbmZvcm1hdGlvbi4NCg0K VGhlIHRleHQgcHJvcG9zZWQgYnkgQW5keTogobBUaGUgcHJvdG9jb2wgTVVTVCBzdXBwb3J0IGEg Y2hhbm5lbCB1c2FnZSBtZXNzYWdlIGZyb20gdGhlIHNsYXZlIGRldmljZSB0byB0aGUgbWFzdGVy IGRldmljZS6hsSBJbXBsaWVzIHRoYXQgdGhlIHByb3RvY29sIHRvIGJlIGRldmVsb3BlZCBuZWVk cyB0byBhcHBseSBvbiB0aGUgY29ubmVjdGlvbiBiZXR3ZWVuIHRoZSBzbGF2ZSBhbmQgdGhlIG1h c3Rlci4gU3VjaCBjb25uZWN0aW9uIHNob3VsZCBiZSBpbXBsZW1lbnRhdGlvbiBkZXBlbmRhbnQu ICBXaGF0IGlzIHJlcXVpcmVkIGlzIHRoYXQgdGhlIGluZm9ybWF0aW9uIGJlYXZhaWxhYmxlIHRv IHRoZSBtYXN0ZXIgZm9yIGl0IHRvIHRyYW5zbWl0IGl0IHRvIHRoZSBkYXRhYmFzZSwgbmV2ZXIg bWluZCB0aGUgZm9ybWF0IHRoYXQgaXN1c2VkIGJldHdlZW4gdGhlIHNsYXZlIGFuZCB0aGUgbWFz dGVyIHRvIGNhcnJ5IHRoaXMgaW5mb3JtYXRpb24uDQoNCkdlcmFsZA0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KRnJvbTogc2NvdHQucHJvYmFzY29Abm9raWEuY29tPG1haWx0 bzpzY290dC5wcm9iYXNjb0Bub2tpYS5jb20+IFttYWlsdG86c2NvdHQucHJvYmFzY29Abm9raWEu Y29tXQ0KU2VudDogVHVlc2RheSwgMDYgTWFyY2gsIDIwMTIgMTI6MDANClRvOiBnZXJhbGQuY2hv dWluYXJkQHN5bXBhdGljby5jYTxtYWlsdG86Z2VyYWxkLmNob3VpbmFyZEBzeW1wYXRpY28uY2E+ OyBhbmR5LnNhZ29AYnQuY29tPG1haWx0bzphbmR5LnNhZ29AYnQuY29tPg0KQ2M6IHBhd3NAaWV0 Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3Bhd3NdIFdHTEMgZm9y IGRyYWZ0LWlldGYtcGF3cy1wcm9ibGVtLXN0bXQtdXNlY2FzZXMtcnFtdHMtMDM6IGNoYW5uZWwg cmVwb3J0aW5nDQoNCkhpIEdlcmFsZCwNCg0KQXQgbGVhc3QgYWNjb3JkaW5nIHRvIHRoZSBGQ0Ms IGEgc2xhdmUgKE1vZGUgSSkgZGV2aWNlIG1heSB1dGlsaXplIGNoYW5uZWxzIHRoYXQgdGhlIG1h c3RlciAoZml4ZWQgZGV2aWNlKSBjYW5ub3QgdXNlLCBzZWUgodcxNS43MDcgYW5kIDE1LjcxMi4g VGh1cyB0aGVyZSBhcmUgcG90ZW50aWFsIHNpdHVhdGlvbnMgd2hlcmUgdGhlIG1hc3RlciBjYW5u b3QgYmUgYXNzdW1lZCB0byBrbm93IHdoYXQgY2hhbm5lbCB0aGUgc2xhdmUgaXMgdXNpbmcuIEFs dGhvdWdoIHRoaXMgaXMgYSBiaXQgZXNvdGVyaWMgYXMgdGhlIEZDQyBpcyBzaWxlbnQgYWJvdXQg d2hhdCB0aGUgc2xhdmUgbWlnaHQgZG8gb24gdGhvc2UgY2hhbm5lbHMsIGl0IGlzIG5vbmV0aGVs ZXNzIGluY2x1ZGVkIGluIHRoZSBGQ0MgcmVndWxhdGlvbnMuDQoNClNvIEkgc3VnZ2VzdCB3ZSBo YXZlIG5vIHJlYXNvbiB0byBvdmVycnVsZSBPZmNvbSByZXF1aXJlbWVudHMgZm9yIGNoYW5uZWwg dXNhZ2UgaW5mb3JtYXRpb24uIEFsc28gQW5keSdzIGNob2ljZSBvZiB3b3JkcyBkb2VzIGVuc3Vy ZSB0aGF0IHRoaXMgaW5mb3JtYXRpb24gaXMgbm90IHJlcXVpcmVkIHRvIGJlIHVzZWQgaW4gZXZl cnkgb3BlcmF0aW9uYWwgc2NlbmFyaW8uDQoNCktpbmQgUmVnYXJkcywNClNjb3R0DQoNCg0KDQpG cm9tOiBleHQgQ2hvdWluYXJkIDxnZXJhbGQuY2hvdWluYXJkQHN5bXBhdGljby5jYTxtYWlsdG86 Z2VyYWxkLmNob3VpbmFyZEBzeW1wYXRpY28uY2E+Pg0KRGF0ZTogVHVlLCA2IE1hciAyMDEyIDEx OjQ0OjA3IC0wNTAwDQpUbzogZXh0IGNvbSA8YW5keS5zYWdvQGJ0LmNvbTxtYWlsdG86YW5keS5z YWdvQGJ0LmNvbT4+DQpDYzogInBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+IiA8 cGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3Bhd3Nd IFdHTEMgZm9yIGRyYWZ0LWlldGYtcGF3cy1wcm9ibGVtLXN0bXQtdXNlY2FzZXMtcnFtdHMtMDM6 IGNoYW5uZWwgcmVwb3J0aW5nDQoNCkFuZHksDQoNCkxvb2tpbmcgYXQgeW91ciBzdWdnZXN0aW9u cyBiZWxvdywgaXQgc2VlbXMgdGhhdCB0aGVyZSBpcyBhIG5lZWQgdG8gZGVmaW5lIG1vcmUgcHJl Y2lzZWx5IHdoYXQgYSChsHNsYXZlobEgZGV2aWNlIGlzIHJlbGF0aXZlIHRvIGl0cyChsG1hc3Rl cqGxLg0KDQpJbiBteSB2aWV3LCBhIHNsYXZlIGNhbiBvbmx5IHVzZSB0aGUgc2FtZSB0cmFuc21p c3Npb24gY2hhbm5lbCBhcyB0aGF0IHVzZWQgYnkgdGhlIG1hc3RlciB0byB3aGljaCBpdCBpcyBh c3NvY2lhdGVkIChvdGhlcndpc2UsIG1hc3RlciBhbmQgc2xhdmVzIHdvdWxkIG5vdCBiZSBhYmxl IHRvIHRhbGsgdG8gZWFjaCBvdGhlcikuIEFzIGEgY29uc2VxdWVuY2UsIHRoZSBzbGF2ZSBkb2Vz IG5vdCBoYXZlIHRvIGluZGljYXRlIHRvIHRoZSBtYXN0ZXIgdGhlIGNoYW5uZWwgb24gd2hpY2gg aXQgaXMgb3BlcmF0aW5nIHNpbmNlIHRoZSBtYXN0ZXIga25vd3MgaXQgYW5kIGNhbiBwcm92aWRl ZCBpdCB0byB0aGUgZGF0YWJhc2UgZS4NCg0KU2ltaWxhcmx5LCBtb2Rlcm4gYmlkaXJlY3Rpb25h bCBjb21tdW5pY2F0aW9uIHN5c3RlbXMgYmV0d2VlbiBhIG1hc3RlciBhbmQgYSBzbGF2ZSBkZXZp Y2UgYXNzdW1lcyB0aGF0IHRoZXJlIHdpbGwgYmUgYSB0cmFuc21pdCBwb3dlciBjb250cm9sIChU UEMpIGxvb3AgYmV0d2VlbiB0aGUgdHdvIGRldmljZXMgdG8gbWluaW1pemUgdGhlIHJlcXVpcmVk IHRyYW5zbWl0IHBvd2VyIGluIHZhcmlvdXMgcHJvcGFnYXRpb24gZW52aXJvbm1lbnRzLiBUaGUg ZHJpdmluZyBkZXZpY2UgaW4gdGhpcyBjbG9zZWQtbG9vcCBwcm9jZXNzIHdpbGwgYmUgdGhlIG1h c3RlciBhbmQgYXMgYSByZXN1bHQsIHRoZSBFSVJQIHRyYW5zbWl0dGVkIGJ5IHRoZSBzbGF2ZSBk ZXZpY2Ugd2lsbCBiZSBrbm93biB0byB0aGUgbWFzdGVyIGFzIGxvbmcgYXMgdGhlcmUgaXMgYSBr bm93biBmYWN0b3IgbGlua2luZyB0aGUgcG93ZXIgc3BlY2lmaWNhdGlvbiBzZW50IGJ5IHRoZSBt YXN0ZXIgdG8gdGhlIHNsYXZlIGFuZCB0aGUgYWN0dWFsIEVJUlAgdHJhbnNtaXR0ZWQgYnkgdGhl IHNsYXZlLiAgU3VjaCBmYWN0b3Igd2hpY2ggaXMgYSBjb25zdGFudCBmb3IgZWFjaCBkZXZpY2Ug Y2FuIGJlIHByb3ZpZGVkIGZyb20gdGhlIHNsYXZlIHRvIHRoZSBtYXN0ZXIgb25jZSBhdCBhc3Nv Y2lhdGlvbi4gIEFzIGEgcmVzdWx0LCB0aGUgc2xhdmUgZG9lcyBub3QgbmVlZCB0byBpbmZvcm0g dGhlIG1hc3RlciBvZiBpdHMgY3VycmVudCAoYW5kIHByb3ZhYmx5IGNvbnRpbnVvdXNseSB2YXJ5 aW5nKSBFSVJQIHNpbmNlIHRoZSBtYXN0ZXIgd2lsbCBoYXZldGhpcyBpbmZvcm1hdGlvbiBmcm9t IGl0cyBUUEMgcHJvY2VzcyBhbmQgY2FuIHByb3ZpZGUgaXQgdG8gdGhlIGRhdGFiYXNlIG9uYmVo YWxmIG9mIHRoZSBzbGF2ZSBkZXZpY2UuDQoNCkdlcmFsZA0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KRnJvbTogcGF3cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpwYXdzLWJv dW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgYW5keS5zYWdvQGJ0LmNvbTxtYWlsdG86YW5keS5zYWdvQGJ0LmNvbT4NClNlbnQ6IFR1ZXNk YXksIDA2IE1hcmNoLCAyMDEyIDEwOjQyDQpUbzogcGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0Bp ZXRmLm9yZz47IEdhYm9yLkJhamtvQG5va2lhLmNvbTxtYWlsdG86R2Fib3IuQmFqa29Abm9raWEu Y29tPg0KU3ViamVjdDogUmU6IFtwYXdzXSBXR0xDIGZvciBkcmFmdC1pZXRmLXBhd3MtcHJvYmxl bS1zdG10LXVzZWNhc2VzLXJxbXRzLTAzOiBjaGFubmVsIHJlcG9ydGluZw0KDQpBbGwNCg0KQ29t cGFyaW5nIHRoZSBkcmFmdCB3aXRoIHRoZSBPZmNvbSByZXF1aXJlbWVudHMgYXQgaHR0cDovL3d3 dy5jZXB0Lm9yZy9Eb2N1bWVudHMvc2UtNDMvNDE2MS9TRTQzKDEyKUluZm8wM19EcmFmdC1VSy1y ZWd1bGF0b3J5LXJlcXVpcmVtZW50cy1mb3Itd2hpdGUtc3BhY2UtZGV2aWNlcy1pbi10aGUtVUhG LVRWLWJhbmQsIEkgYmVsaWV2ZSB0aGUgV0cgZHJhZnQgaXMgZGVmaWNpZW50IGluIHRoZSBhcmVh IG9mIHJlcG9ydGluZyBmcmVxdWVuY2llcyBhbmQgcG93ZXJzIGFjdHVhbGx5IHVzZWQgYnkgbWFz dGVycyBhbmQgc2xhdmVzIChPZmNvbSByZXF1aXJlbWVudHMgMy4xOCBhbmQgMy4xOS44KS4gT2Zj b20gaW50ZW5kcyB0byBjb2xsZWN0IHRoaXMgZGF0YSB0byBhc3Nlc3NlcyB0aGUgaW1wYWN0IG9m IGFnZ3JlZ2F0ZSBpbnRlcmZlcmVuY2UgaW50byBvdGhlciBzZXJ2aWNlcy4gSXQgd291bGQgYWxz byBwcm92aWRlIHVzYWdlIGluZm9ybWF0aW9uIChmcmVxdWVuY3kgaW4gdXNlKSB0aGF0IHdvdWxk IGluZm9ybSB0aGUgb3BlcmF0aW9uIG9mIGEga2lsbCBzd2l0Y2ggY2FwYWJpbGl0eS4gSSBzdWdn ZXN0IHRoaXMgZGVmaWNpZW5jeSBjYW4gYmUgcmVtZWRpZWQgd2l0aCB0aGUgZm9sbG93aW5nIGNo YW5nZXM6DQoNCk5ldyBQIHJlcXVpcmVtZW50cyAocHJvYmFibHkgYmVzdCBwbGFjZWQgZm9sbG93 aW5nIFAuMTIpOg0KDQpQLjEyYmlzOiBUaGUgcHJvdG9jb2wgTVVTVCBzdXBwb3J0IGEgY2hhbm5l bCB1c2FnZSBtZXNzYWdlIGZyb20gdGhlIHNsYXZlIGRldmljZSB0byB0aGUgbWFzdGVyIGRldmlj ZS4gIFRoZSBjaGFubmVsIHVzYWdlIG1lc3NhZ2UgTVVTVCBpbmNsdWRlIHBhcmFtZXRlcnMgYXMg cmVxdWlyZWQgYnkgbG9jYWwgcmVndWxhdG9yeSByZXF1aXJlbWVudC4gIFRoZXNlIHBhcmFtZXRl cnMgTUFZIGluY2x1ZGUgZGV2aWNlIElELCBtYW51ZmFjdHVyZXIncyBzZXJpYWwgbnVtYmVyLCBj aGFubmVsIHVzYWdlIGFuZCBwb3dlciBsZXZlbCBpbmZvcm1hdGlvbi4NCg0KUC4xMnRlcjogVGhl IHByb3RvY29sIE1VU1Qgc3VwcG9ydCBhIGNoYW5uZWwgdXNhZ2UgbWVzc2FnZSBmcm9tIHRoZSBt YXN0ZXIgZGV2aWNlIHRvIHRoZSBkYXRhYmFzZS4gIFRoZSBjaGFubmVsIHVzYWdlIG1lc3NhZ2Ug TVVTVCBpbmNsdWRlIHBhcmFtZXRlcnMgYXMgcmVxdWlyZWQgYnkgbG9jYWwgcmVndWxhdG9yeSBy ZXF1aXJlbWVudCBmb3IgdGhlIG1hc3RlciBhbmQgaXRzIGFzc29jaWF0ZWQgc2xhdmVzLiAgVGhl c2UgcGFyYW1ldGVycyBNQVkgaW5jbHVkZSBkZXZpY2UgSUQsIG1hbnVmYWN0dXJlcidzIHNlcmlh bCBudW1iZXIsIGNoYW5uZWwgdXNhZ2UgYW5kIHBvd2VyIGxldmVsIGluZm9ybWF0aW9uLg0KDQpQ LjEycXVhOiBUaGUgcHJvdG9jb2wgTVVTVCBzdXBwb3J0IGEgY2hhbm5lbCB1c2FnZSBtZXNzYWdl IGFja25vd2xlZGdlbWVudC4NCg0KTmV3IE8gcmVxdWlyZW1lbnRzIChwcm9iYWJseSBiZXN0IHBs YWNlZCBmb2xsb3dpbmcgTzEzKToNCg0KTy4xM2JpczogIEFjY29yZGluZyB0byBsb2NhbCByZWd1 bGF0b3J5IHBvbGljeSwgYWZ0ZXIgY29ubmVjdGluZyB0byBhIG1hc3RlciBkZXZpY2Unc3JhZGlv IG5ldHdvcmsgYSBzbGF2ZSBkZXZpY2UgTUFZIGluZm9ybSB0aGUgbWFzdGVyIGRldmljZSBvZiB0 aGUgYWN0dWFsIGNoYW5uZWwgdXNhZ2UuIFRoZSBzbGF2ZSBNVVNUIGluY2x1ZGUgcGFyYW1ldGVy cyByZXF1aXJlZCBieSBsb2NhbCByZWd1bGF0b3J5IHBvbGljeSwgZS5nLiBkZXZpY2UgSUQsIG1h bnVmYWN0dXJlcidzIHNlcmlhbCBudW1iZXIsIGNoYW5uZWwgdXNhZ2UgYW5kIHBvd2VyIGxldmVs aW5mb3JtYXRpb24uDQoNCk8uMTN0ZXI6ICBBY2NvcmRpbmcgdG8gbG9jYWwgcmVndWxhdG9yeSBw b2xpY3ksIGEgbWFzdGVyIGRldmljZSBNQVkgaW5mb3JtIHRoZSBkYXRhYmFzZSBvZiB0aGUgYWN0 dWFsIGNoYW5uZWwgdXNhZ2Ugb2YgdGhlIG1hc3RlciBhbmQgaXRzIHNsYXZlcy4gVGhlIG1hc3Rl ciBNVVNUIGluY2x1ZGUgcGFyYW1ldGVycyByZXF1aXJlZCBieSBsb2NhbCByZWd1bGF0b3J5IHBv bGljeSwgZS5nLiBkZXZpY2UgSUQsIG1hbnVmYWN0dXJlcidzIHNlcmlhbCBudW1iZXIsIGNoYW5u ZWwgdXNhZ2UgYW5kIHBvd2VyIGxldmVsIGluZm9ybWF0aW9uIG9mIHRoZSBtYXN0ZXIgYW5kIGl0 cyBzbGF2ZXMuDQoNCk5ldyBzdGVwcyBjb3VsZCBiZSBpbnRyb2R1Y2VkIGludG8gb25lIG9yIG1v cmUgdXNlIGNhc2VzIHRvIGNvdmVyIHRoZXNlIE9mY29tIHJlcXVpcmVtZW50cywgZS5nLiBuZXcg c3RlcHMgNmJpcyBhbmQgOWJpcyBpbiB0aGUgaG90c3BvdCB1c2UgY2FzZSBhdCA0LjIuMToNCg0K NmJpcy4gUHJpb3IgdG8gaW5pdGlhdGluZyB0cmFuc21pc3Npb24sIGlmIHJlcXVpcmVkIGJ5IGxv Y2FsIHJlZ3VsYXRpb24sIHRoZSBtYXN0ZXIvQVAgaW5mb3JtcyB0aGUgZGF0YWJhc2Ugb2YgdGhl IGNoYW5uZWwgYW5kIHBvd2VyIGxldmVsIGl0IGhhcyBjaG9zZW4uIFRoaXMgaXMgcmVwZWF0ZWQg Zm9yIGVhY2ggc2xhdmUgdGhhdCBhc3NvY2lhdGVkIHdpdGggdGhlIG1hc3Rlci4NCg0KOWJpcy4g UHJpb3IgdG8gaW5pdGlhdGluZyB0cmFuc21pc3Npb24sIGlmIHJlcXVpcmVkIGJ5IGxvY2FsIHJl Z3VsYXRpb24sIHRoZSBzbGF2ZSBpbmZvcm1zIHRoZSBtYXN0ZXIvQVAgb2YgdGhlIGNoYW5uZWwg YW5kIHBvd2VyIGxldmVsIGl0IGhhcyBjaG9zZW4sIGFuZCB0aGVtYXN0ZXIvQVAgcmVsYXlzIHRo aXMgaW5mb3JtYXRpb24gdG8gdGhlIGRhdGFiYXNlLg0KDQotIGVuZCBvZiBuZXcgdGV4dCAtDQoN CkZvciBpbmZvcm1hdGlvbiwgZm9yIHRob3NlIG5vdCBhY2Nlc3NpbmcgdGhlIHVybCBpbiB0aGUg Zmlyc3QgcGFyYWdyYXBoIG9mIHRoaXMgZW1haWwsIHRoZSBmdWxsIE9mY29tIHJlcXVpcmVtZW50 cyBsZWFkaW5nIHRvIHRoaXMgbmV3IFBBV1MgdGV4dCBhcmUgYXMgZm9sbG93czoNCg0KMy4xOCBB ZnRlciByZWNlaXZpbmcgaW5zdHJ1Y3Rpb25zIGZyb20gYSBXU0RCIGluIHJlbGF0aW9uIHRvIHRo ZSBtYXhpbXVtIHBlcm1pdHRlZCBFSVJQcyBvdmVyIHRoZSBEVFQgY2hhbm5lbHMsIGFuZCBwcmlv ciB0byBpbml0aWF0aW5nIHRyYW5zbWlzc2lvbnMgd2l0aGluIHRoZSBVSEYgVFYgYmFuZCwgYSBt YXN0ZXIgV1NEIG11c3Rjb21tdW5pY2F0ZSB0byB0aGUgV1NEQiB0aGUgZm9sbG93aW5nIGluZm9y bWF0aW9uOg0KMy4xOC4xIFRoZSBsb3dlciBhbmQgdXBwZXIgZnJlcXVlbmN5IGJvdW5kYXJpZXMx MyBvZiB0aGUgaW4tYmxvY2sgZW1pc3Npb25zIG9mIHRoZSBtYXN0ZXIgV1NELCBhbmQgdGhvc2Ug b2YgdGhlIGluLWJsb2NrIGVtaXNzaW9ucyBvZiBpdHMgYXNzb2NpYXRlZCBzbGF2ZXMuIEEgbG93 ZXIgZnJlcXVlbmN5IHdpbGwgYmUgc3BlY2lmaWVkIGFzICg0NzAgKyA4ayArIDAuMm4pIE1Ieiwg d2l0aCB0aGUgY29ycmVzcG9uZGluZyB1cHBlciBmcmVxdWVuY3kgc3BlY2lmaWVkIGFzICg0NzAg KyA4ayArIDAuMm0pIE1Ieiwgd2hlcmUgMCChwiBrIKHCIDM5LCAwIKHCIG4gocIgMzksIDEgocIg bSChwiA0MCwgYW5kIG4gPCBtLg0KMy4xOC4yIFRoZSBtYXhpbXVtIGluLWJsb2NrIEVJUlAgc3Bl Y3RyYWwgZGVuc2l0aWVzIChpbiBkQm0vKDAuMiBNSHopKSB0aGF0IHRoZSBtYXN0ZXJXU0QsIGFu ZCBpdHMgYXNzb2NpYXRlZCBzbGF2ZXMsIGFjdHVhbGx5IHJhZGlhdGUgYmV0d2VlbiBlYWNoIHJl cG9ydGVkIGxvd2VyIGZyZXF1ZW5jeSBib3VuZGFyeSBhbmQgaXRzIGNvcnJlc3BvbmRpbmcgdXBw ZXIgZnJlcXVlbmN5IGJvdW5kYXJ5Lg0KDQpGb290bm90ZSAxMyBzdGF0ZXM6DQpUaGUgdXNlIG9m IHVwcGVyIGFuZCBsb3dlciBmcmVxdWVuY3kgYm91bmRhcmllcyAoZGVmaW5lZCBvdmVyIGEgMjAw IGtIeiByYXN0ZXIpIGFsbG93cyBhIFdTREIgdG8gY29sbGVjdCBtb3JlIGdyYW51bGFyIGluZm9y bWF0aW9uIHdpdGggcmVnYXJkcyB0byB0aGUgdXNhZ2Ugb2YgdGhlIGZyZXF1ZW5jeSByZXNvdXJj ZSBieW5hcnJvd2JhbmQgV1NEIHRlY2hub2xvZ2llcy4gVGhlIHVwcGVyIGFuZCBsb3dlciBmcmVx dWVuY2llcyBvZiBhIGJvdW5kYXJ5IHBhaXIgZG8gbm90c3RyYWRkbGUgYSBEVFQgY2hhbm5lbCBi b3VuZGFyeS4gTm90ZSB0aGF0IGEgV1NEIG1heSB0cmFuc21pdCBvdmVyIG11bHRpcGxlLCBub24t Y29udGlndW91cywgd2hvbGUgRFRUIGNoYW5uZWxzIG9yIGZyYWN0aW9ucyBvZiBEVFQgY2hhbm5l bHMuDQoNCjMuMTkgQSBtYXN0ZXIgV1NEIG11c3QgYmUgYWJsZSB0byByZWNlaXZlIHRoZSBmb2xs b3dpbmcgaW5mb3JtYXRpb24xNCBmcm9tIGEgV1NEQjoNCjxzbmlwPg0KMy4xOS44ICAgICBbQW4g YWNrbm93bGVkZ2VtZW50IGZyb20gdGhlIFdTREIsIGluIHRoZSBjb250ZXh0IG9mIDMuMTgsIHRo YXQgdGhlIHJlcG9ydGVkIGluZm9ybWF0aW9uIG9uIHRoZSBEVFQgY2hhbm5lbHMgYW5kIEVJUlAg c3BlY3RyYWwgZGVuc2l0aWVzIGFjdHVhbGx5IHVzZWQgYnkgdGhlIG1hc3RlciBhbmQgc2xhdmUg V1NEcyB3ZXJlIHJlY2VpdmVkIHN1Y2Nlc3NmdWxseSBieSB0aGUgV1NEQjE4XS4NCg0KRm9vdG5v dGUgMTQgc3RhdGVzOg0KMTQgV2hpbGUgdGhlIGNvbW11bmljYXRpb24gb2Ygc29tZSBvZiB0aGlz IGluZm9ybWF0aW9uIGZyb20gYSBXU0RCIHRvIGEgbWFzdGVyIFdTRCBpcyBvcHRpb25hbCwgbWFz dGVyIFdTRHMgbXVzdCBiZSBhYmxlIHRvIHJlY2VpdmUgYW5kIGludGVycHJldCB0aGVzZS4NCg0K Rm9vdG5vdGUgMTggc3RhdGVzOg0KMTggVGhpcyBmb3JtcyBwYXJ0IG9mIGEgaGFuZHNoYWtlIHBy b3RvY29sIGFuZCBtYXkgYmUgYW4gYXJlYSB3aGVyZSBpbmR1c3RyeSBjb3VsZCBoYXJtb25pc2Ug d2l0aG91dCB0aGUgbmVlZCBmb3IgYW4gZXhwbGljaXQgcmVxdWlyZW1lbnQgaW4gdGhlIHJlZ3Vs YXRpb25zLg0KDQpSZWdhcmRzDQoNCkFuZHkNCg0KRnJvbTogcGF3cy1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86cGF3cy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgR2Fib3IuQmFqa29Abm9raWEuY29tPG1haWx0bzpHYWJvci5CYWpr b0Bub2tpYS5jb20+DQpTZW50OiAwNSBNYXJjaCAyMDEyIDE5OjQ2DQpUbzogcGF3c0BpZXRmLm9y ZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4NClN1YmplY3Q6IFtwYXdzXSBXR0xDIGZvciBkcmFmdC1p ZXRmLXBhd3MtcHJvYmxlbS1zdG10LXVzZWNhc2VzLXJxbXRzLTAzDQoNCg0KVGhlIGF1dGhvcnMg b2YgdGhlIHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRzIGRyYWZ0IGhhdmUganVzdCBwb3N0ZWQg YSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQgYW5kIGluZGljYXRlZCB0aGF0IHRoZXJlIGFyZSBu byB1bnJlc29sdmVkIGNvbW1lbnRzL2lzc3VlcyB0aGV5IGFyZSBhd2FyZSBvZi4NCg0KDQoNClRo ZXJlZm9yZSwgSSdkIGxpa2UgdG8gaW5pdGlhdGUgYSBXRyBMYXN0IENhbGwgZm9yIGNvbW1lbnRz IG9uIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtcGF3cy1w cm9ibGVtLXN0bXQtdXNlY2FzZXMtcnFtdHMtMDMudHh0DQoNCg0KDQpQbGVhc2UgcmV2aWV3IHRo ZSBkcmFmdCBhbmQgc2VuZCB5b3VyY29tbWVudHMgdG8gdGhlIGxpc3QgYnkgTWFyY2ggMjB0aCwg MjAxMi4NCg0KDQoNCklmIHlvdSByZXZpZXcgdGhlIGRyYWZ0IGFuZCBoYXZlIG5vIGNvbW1lbnRz LCBzZW5kIGEgbm90ZSB0byB0aGUgbGlzdCB0aGF0IHRoZSBkcmFmdCBpcyBnb29kIGFzIGl0IGlz LCB3ZSBuZWVkIHRoZXNlIG5vdGVzIGFzIG11Y2ggYXMgd2UgbmVlZCB0aGUgYWN0dWFsIGNvbW1l bnRzLg0KDQoNCg0KVGhhbmtzLCBHYWJvcg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXyBwYXdzIG1haWxpbmcgbGlzdCBwYXdzQGlldGYub3JnPG1haWx0 bzpwYXdzQGlldGYub3JnPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bh d3MNCg== --_000_CB7E3CE913BD6scottprobasconokiacom_ Content-Type: text/html; charset="ks_c_5601-1987" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Gerald,

I agree that some wireless standards will elect to implement signaling= related to database access, e.g. signaling between the slave the and the m= aster. But PAWS is independent of the radio and therefore cannot expect tha= t portions of the necessary signaling will be implemented elsewhere. In the scope of the WG we don't differentia= te between a master or slave, we simply address providing channel lists to = ensure proper operation of a white space radio network.

Perhaps the chairs could allocate some time on the agenda in the comin= g meeting to discuss this topic.

Kind Regards,
Scott


From: ext Chouinard <gerald.chouinard@sympatico.ca>=
Date: Tue, 6 Mar 2012 13:18:25 -050= 0
To: Scott Probasco <scott.probasco@nokia.com>
Cc: "paws@ietf.org" <paws@i= etf.org>
Subject: RE: [paws] WGLC for draft-= ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting

Scott,

 

I believe that this could be kept simp= le by assuming that if a device needs to directly communicate its informati= on to the database, it can be considered for the purpose of PAWS as a =A1=B0master=A1=B1 devic= e. If this can be done through a proxy device in between, then the device n= eeds to be slaved to this device in between which will then be considered a= s the =A1=B0master=A1=B1. In such case, the wireless standard used between these devices needs to have all the necessary means = to transmit the necessary information from the =A1=B0slave=A1=B1 to its =A1= =B0master=A1=B1 to meet the requirements of white space operation.  Th= e way it is done can vary from one technology to another. This was, the scope of PAWS is limited to the link between the master and = the database and not between the slave and the master.

 

Gerald

 

From: scott.probasco@nokia.com [<= a href=3D"mailto:scott.probasco@nokia.com">mailto:scott.probasco@nokia.com<= /a>]
Sent: Tuesday, 06 March, 201= 2 13:05
To: gerald.chouinard@sympa= tico.ca
Cc: paws@ietf.org
Subject: Re: [paws] WGLC for= draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting

 

Hi Gerald,

 <= /p>

I agree with you that some wirel= ess standards will include signaling that supports database access. But PAW= S is not specific to any particular radio technology, we cannot expect that all radio technologies will include some= components of the signaling for database access. PAWS should include all n= ecessary messages for contact between the device and the database, without = presumption of the underlying radio technology.

 <= /p>

Kind Regards,<= /font>

Scott

 <= /p>

From: = ext Chouinard <gerald.c= houinard@sympatico.ca>
Date: Tue, 6 Mar 2012 12:44:= 09 -0500
To: Scott Probasco <scott.probasco@nokia.com>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] WGLC for= draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting

 <= /p>

Scott,

 

I am fine with your second sentence. &= nbsp;However, I have some difficulty with your third sentence since this wo= uld mean that the IETF-PAWS would get into defining the signaling details between the slave and the ma= ster devices. I believe this should be left to the wireless standard.  = ;Obviously, having this information available at the master would become a = requirement that the wireless standard would have to meet to be able to operate in white space. The way it would = be done would be internal to the wireless standard.  PAWS would take i= t from the master to the database.

 

Gerald

 

= From: scott.probasco@Nokia.com [<= a href=3D"mailto:scott.probasco@Nokia.com">mailto:scott.probasco@Nokia.com<= /a>]
Sent: Tuesday, 06 March, 201= 2 12:32
To: gerald.chouinard@symp= atico.ca
Cc: paws@ietf.org
Subject: Re: [paws] WGLC for= draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting

 

Hi Gerald,

 

I believe Andy's proposal agrees= with your suggestion below. Looking at O.13bis, the slave MAY send the cha= nnel usage information and if it does so, it MUST include the following variables. I think P.12bis is appropriate si= nce the message MUST be defined by the protocol inorder to have the OPTION = of sending it. When these two requirements are considered jointly does this= provide the implementation flexibility you arethinking of?

 

Kind Regards,

Scott= =

 

From: = ext Chouinard <gerald.c= houinard@sympatico.ca>
Date: Tue, 6 Mar 2012 12:13:= 05 -0500
To: Scott Probasco <scott.probasco@nokia.com>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] WGLC for= draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting

 

Scott,

 

I am fine with your approach as long a= s the text says something as follows: =A1=B0the operating channel of the sl= ave needs to be provided to the database=A1=B1 rather than: =A1=B0the slave needs to provide the da= tabase with its operating channel=A1=B1.  This way, this information c= an be provided by either the slave or the master, not making it mandatory t= hat the =A1=B0slave=A1=B1 has to do it if the master knows the information.

 

The text proposed by Andy: =A1=B0The protocol MUST support a channel usage message from the slave device to the= master device.=A1=B1 Implies that the protocol to be developed needs to ap= ply on the connection between the slave and the master. Such connection sho= uld be implementation dependant.  What is required is that the information beavailable to the master for it to tr= ansmit it to the database, never mind the format that isused between the sl= ave and the master to carry this information.

 

Gerald

 

= From: scott.probasco@nokia.com [<= a href=3D"mailto:scott.probasco@nokia.com">mailto:scott.probasco@nokia.com<= /a>]
Sent: Tuesday, 06 March, 201= 2 12:00
To: gerald.chouinard@symp= atico.ca; andy.sago@bt.com
Cc: paws@ietf.org
Subject: Re: [paws] WGLC for= draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting<= /u1:p>

 =

Hi Gerald,

 =

At least according to the FCC, a= slave (Mode I) device may utilize channels that the master (fixed device) = cannot use, see =A1=D715.707 and 15.712. Thus there are potential situations where the master cannot be assumed to know what c= hannel the slave is using. Although this is a bit esoteric as the FCC is si= lent about what the slave might do on those channels, it is nonetheless inc= luded in the FCC regulations.

 =

So I suggest we have no reason t= o overrule Ofcom requirements for channel usage information. Also Andy's ch= oice of words does ensure that this information is not required to be used in every operational scenario.

 =

Kind Regards,

Scott= <= /span>

 =

 =

 =

From: = ext Chouinard <gerald.c= houinard@sympatico.ca>
Date: Tue, 6 Mar 2012 11:44:= 07 -0500
To: ext com <andy.sago@bt.com>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] WGLC for= draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting

 =

Andy,=

 

Looking at your suggestions below, it = seems that there is a need to define more precisely what a =A1=B0slave=A1= =B1 device is relative to its =A1=B0master=A1=B1.

 

In my view, a slave can only use the s= ame transmission channel as that used by the master to which it is associat= ed (otherwise, master and slaves would not be able to talk to each other). As a consequence, the= slave does not have to indicate to the master the channel on which it is o= perating since the master knows it and can provided it to the database e.

 

Similarly, modern bidirectional commun= ication systems between a master and a slave device assumes that there will= be a transmit power control (TPC) loop between the two devices to minimize the required transm= it power in various propagation environments. The driving device in this cl= osed-loop process will be the master and as a result, the EIRP transmitted = by the slave device will be known to the master as long as there is a known factor linking the power specifi= cation sent by the master to the slave and the actual EIRP transmitted by t= he slave.  Such factor which is a constant for each device can be prov= ided from the slave to the master once at association.  As a result, the slave does not need to inform the m= aster of its current (and provably continuously varying) EIRP since the mas= ter will havethis information from its TPC process and can provide it to th= e database onbehalf of the slave device.

 

Gerald

 

= From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of andy.sago@bt.com
Sent: Tuesday, 06 March, 201= 2 10:42
To: paws@ietf.org; Gabor.Bajko@nokia.com
Subject: Re: [paws] WGLC for= draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting<= /u3:p>

 =

= All

=  <= /u5:p>

= Comparing the= draft with the Ofcom requirements at ht= tp://www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-regulatory-r= equirements-for-white-space-devices-in-the-UHF-TV-band, I believe the WG draft is deficient in the area of reporting frequencies a= nd powers actually used by masters and slaves (Ofcom requirements 3.18 and = 3.19.8). Ofcom intends to collect this data to assesses the impact of aggre= gate interference into other services. It would also provide usage information (frequency in use) that would info= rm the operation of a kill switch capability. I suggest this deficiency can= be remedied with the following changes:

=  <= /u5:p>

= New P require= ments (probably best placed following P.12):

=  <= /u5:p>

P.12bis: The protocol MUST support a channel usage message= from the slave device to the master device.  The channel usage message MUST include parameters as required by local regulat= ory requirement.  These parameters MAY include device ID, manufacturer= 's serial number, channel usage and power level information.=

 

P.12ter: The protocol MUST support a channel usage message= from the master device to the database.  The channel usage message MUST include parameters as required by local regulatory requ= irement for the master and its associated slaves.  These parameters MA= Y include device ID, manufacturer's serial number, channel usage and power = level information.

 

P.12qua: The protocol MUST support a channel usage message= acknowledgement.

=  <= /u5:p>

= New O require= ments (probably best placed following O13):

=  <= /u5:p>

O.13bis:  According to local regulatory policy, after= connecting to a master device'sradio network a slave device MAY inform the master device of the actual channel usage. The slave= MUST include parameters required by local regulatory policy, e.g. device I= D, manufacturer's serial number, channel usage and power levelinformation.<= u5:p>

 

O.13ter:  According to local regulatory policy, a mas= ter device MAY inform the database of the actual channel usage of the master and its slaves. The master MUST include parameters req= uired by local regulatory policy, e.g. device ID, manufacturer's serial num= ber, channel usage and power level information of the master and its slaves= .

=  <= /u5:p>

= New steps cou= ld be introduced into one or more use cases to cover these Ofcom requiremen= ts, e.g. new steps 6bis and 9bis in the hotspot use case at 4.2.1:

=  <= /u5:p>

6bis. Prior to initiating transmission, if required by loc= al regulation, the master/AP informs the database of the channel and power level it has chosen. This is repeated for each sl= ave that associated with the master.

 

9bis. Prior to initiating transmission, if required by loc= al regulation, the slave informs the master/AP of the channel and power level it has chosen, and themaster/AP relays this= information to the database.

=  <= /u5:p>

= - end of new = text -

=  <= /u5:p>

= For informati= on, for those not accessing the url in the first paragraph of this email, t= he full Ofcom requirements leading to this new PAWS text are as follows:=

=  <= /u5:p>

= 3.18 After re= ceiving instructions from a WSDB in relation to the maximum permitted EIRPs= over the DTT channels, and prior to initiating transmissions within the UHF TV band, a master WSD mustcommunicate to the = WSDB the following information:

3.18.1 The lower and upper frequency boundaries13 of the in-block emissions of the master WSD, and those of the in-block emissions of its associated slaves. A lower freq= uency will be specified as (470 + 8k + 0.2n) MHz, with the correspo= nding upper frequency specified as (470 + 8k + 0.2m) MHz, where 0 = =A1=C2 k =A1=C2 39, 0 =A1=C2 n =A1=C2 39, 1 =A1=C2 m =A1=C2 40, and n < = m.

3.18.2 The maximum in-block EIRP spectral densities (in dB= m/(0.2 MHz)) that the masterWSD, and its associated slaves, actually radiate between each reported lower frequency boundary an= d its corresponding upper frequency boundary.

=  <= /u5:p>

= Footnote 13 s= tates:

= The use of up= per and lower frequency boundaries (defined over a 200 kHz raster) allows a= WSDB to collect more granular information with regards to the usage of the frequency resource bynarrowband WSD technologi= es. The upper and lower frequencies of a boundary pair do notstraddle a DTT= channel boundary. Note that a WSD may transmit over multiple, non-contiguo= us, whole DTT channels or fractions of DTT channels.

=  <= /u5:p>

= 3.19 A master= WSD must be able to receive the following information14 from a = WSDB:

= <snip><= u5:p>

3.19.8     [An acknowledgement from th= e WSDB, in the context of 3.18, that the reported information on the DTT channels and EIRP spectral densities actually used by the master and s= lave WSDs were received successfully by the WSDB18].

=  <= /u5:p>

= Footnote 14 s= tates:

= 14 While the = communication of some of this information from a WSDB to a master WSD is op= tional, master WSDs must be able to receive and interpret these.<= /p>

=  <= /u5:p>

= Footnote 18 s= tates:

= 18 This forms= part of a handshake protocol and may be an area where industry could harmo= nise without the need for an explicit requirement in the regulations.

=  <= /u5:p>

= Regards=

=  <= /u5:p>

= Andy<= /u3:p>

=  <= /u5:p>

= From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com
Sent: 05 March 2012 19:46 To: paws@ietf.org
Subject: [paws] WGLC for dra= ft-ietf-paws-problem-stmt-usecases-rqmts-03

 

The authors of the use cases = and requirements draft have just posted a new version of the draft and indi= cated that there are no unresolved comments/issues they are aware of.

 

Therefore, I'd like to initia= te a WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-r= qmts-03.txt

 

Please review the draft and s= end yourcomments to the list by March 20th, 2012.=

 

If you review the draft and h= ave no comments, send a note to the list that the draft is good as it is, w= e need these notes as much as we need the actual comments.<= /font>

 

Thanks, Gabor

 =

________________________________= _______________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws

--_000_CB7E3CE913BD6scottprobasconokiacom_-- From stpeter@stpeter.im Thu Mar 8 09:39:14 2012 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 91A9F21F86C8 for ; Thu, 8 Mar 2012 09:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.447 X-Spam-Level: X-Spam-Status: No, score=-101.447 tagged_above=-999 required=5 tests=[AWL=-1.475, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, 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 LUMULh5wXFiy for ; Thu, 8 Mar 2012 09:39:13 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id EF6E221F86C6 for ; Thu, 8 Mar 2012 09:39:12 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0E8F24005B; Thu, 8 Mar 2012 10:51:14 -0700 (MST) Message-ID: <4F58EEBE.8070101@stpeter.im> Date: Thu, 08 Mar 2012 10:39:10 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: scott.probasco@nokia.com References: In-Reply-To: X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: paws@ietf.org, presnick@qualcomm.com, johnny.dixon@bt.com, chris.cheeseman@bt.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 17:39:14 -0000 Hi Scott, I have two clarifying questions: 1. Does the device know, when it receives the channel response, which channel it will actually use? 2. If the device then uses another channel or a different channel, does it need to report that change to the database? Thanks! Peter On 3/8/12 10:17 AM, scott.probasco@nokia.com wrote: > Hi, > > The point from Brian is very relevant: > > Channel request > Channel response > Channel acknowledgement > > What Ofcom does with the information in the acknowledgement does not > matter. As the regulator in UK, they write rules that must be followed in > order to operate a whitespace radio in the UK. I believe the scope of the > WG must be focused on a working solution. If this is simple channel > request & response in one regulator's domain, PAWS can support this. If it > means a channel request, response and acknowledgement in another > regulator's domain, PAWS can support this. As a participating member of > the work group, I believe the scope should be basic working solution, not > limited to a specific number of messages. > > Kind Regards, > Scott > > > > On 3/8/12 11:11 AM, "ext Zuniga, Juan Carlos" > wrote: > >> Peter, Nancy, >> >> I agree should design a protocol with the best of our current knowledge, >> and that should be accounting for all the known regulations at present >> time. We should not limit the scope with the purpose of designing a >> protocol 'faster'. Our goal is not only to design a WSDB protocol. Our >> goal is to design a WSDB protocol that is USEFUL to the community. >> >> The charter does state that >> >> "...the group should also reach out to other potential >> "customers" for a white space database access method and consider input >>from regulatory entities that are involved in the specification of the >> rules for secondary use of spectrum in specific radio bands. " >> >> I think that is exactly what we are doing now. >> >> Regarding whether the types of requirements belong to #1 or #2, I believe >> it is more of #1 type, as the information to be exchanged would be known >> after the initial query/response. >> >> If we know it today, I see no reason why we should not work on it in the >> first phase of the work. >> >> Regards, >> >> Juan Carlos >> >>> -----Original Message----- >>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >>> Peter Saint-Andre >>> Sent: Thursday, March 08, 2012 11:59 AM >>> To: Nancy Bravin >>> Cc: paws@ietf.org; johnny.dixon@bt.com; chris.cheeseman@bt.com; Pete >>> Resnick >>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >>> rqmts-03: channel reporting >>> >>> Hi Nancy, >>> >>> You are absolutely right that different locales will have different >>> rules and requirements. We need to understand those, and work to >>> address >>> them if possible (although we don't necessarily need to address them >>> all >>> at the same time). I see several kinds of requirements: >>> >>> 1. Some requirements might lead to features beyond the query/response >>> protocol we've envisioned so far. One example might be real-time >>> reporting about the channels that a device is actually using. In my >>> opinion, it would be best to handle those in the next phase of work, >>> because as far as I can see they are outside the scope of our charter. >>> >>> 2. Some requirements might be handled through by defining additional >>> fields that can be included in the query or response. We definitely >>> planned for that when working on the charter with the IESG: >>> >>> In addition, the particular >>> data exchanged between a device and a database might depend on the >>> ranges of radio spectrum that are to be used, the requirements of the >>> database operators and their governing regulations, and other >>> factors. >>> Therefore, the database access method and the query/response data >>> formats that are exchanged using that method need to be designed for >>> extensibility rather than being tied to any specific spectrum, >>> country, or phy/mac/air interface. >>> >>> It's unclear to me right now if the Ofcom requirement fits into #1 or >>> #2, which is why we're having this discussion. :) >>> >>> Peter >>> >>> On 3/7/12 8:17 PM, Nancy Bravin wrote: >>>> Peter and all, >>>> >>>> I agree that it is important to revisit now, so that in the future, >>>> it will be easy to align things in their proper place. Every country >>>> may have different regulations, spectrum, policy and what >>>> responsibility is in the domain of the system, and what comes under >>>> the PAWS charter is important. Maybe some separation might be >>>> possible, and dividing and clarifying issues now will help in the >>>> future. Certainly it seems that the FCC may change some rules, and >>>> we know that Ofcom is not yet finished with their regulations. Canada >>>> has their own, and other countries are working on this as well. Just >>>> a thought...Sharing is a realistic goal...as is off loading... Or you >>>> slim line and every 6 months decide what to incorporate in the >>>> protocol based on new information, new ideas, new innovation new >>>> regulations and maybe spend more time than you could if addressed >>>> now. >>>> >>>> That way you leave the door open and outside of referencing what is >>>> known today, by referencing regulations i.e. Ofcom, FCC, Industry >>>> Canada etc as of XX-XX-XXXX date. Out of scope not something we know >>>> enough about to say at this point, In my opinion. >>>> >>>> My 2 cents.. >>>> >>>> Sincerely, Nancy >>>> >>>> On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote: >>>> >>>>> >>>>> >>>>> As your responsible Area Director (until March 28, when Pete >>>>> Resnick will take over from me), I have reviewed this thread. >>>>> >>>>> In my opinion (I am happy to be proven wrong), this new requirement >>>>> goes beyond what the charter defined as the scope of this working >>>>> group, which was to enable a device to discover the white space >>>>> available to it in its current location. Reporting usage back to >>>>> the database is simply not mentioned in the charter. >>>>> >>>>> Earlier in this thread, Andy Sago wrote: >>>>> >>>>> There's no language I can find in the charter that explicitly puts >>>>> this out of scope. >>>>> >>>>> An IETF charter defines what the working group shall work on. Many >>>>> interesting features could be developed here. However, it is not >>>>> the job of the charter to mention explicitly that each of those >>>>> interesting features is out of scope. >>>>> >>>>> The charter does say: >>>>> >>>>> Once the device learns of the available white space (e.g., in a TV >>>>> white space implementation, the list of available channels at that >>>>> location), it can then select one of the bands from the list and >>>>> begin to transmit and receive on the selected band. >>>>> >>>>> This text might have assumed that no further communication or >>>>> authorization was required in order to select one of the bands from >>>>> the list and then transmit/receive. Perhaps that assumption was >>>>> mistaken. If so, it would be good to have a discussion about that, >>>>> so we can determine if we need to revisit the assumptions we made >>>>> early on. If in fact we made some faulty or limited assumptions, >>>>> then let's get that out in the open. >>>>> >>>>> Peter >>>>> >>>>> On 3/7/12 9:40 AM, Rosen, Brian wrote: >>>>>> I'd also suggest that our >>>>>> charter limitation is really support for sharing of whitespace by >>>>>> whitespace devices. Reporting what you use is not sharing, it's >>>>>> just data gathering. >>>>>> >>>>>> The point of excluding sharing was to eliminate the complexities >>>>>> of what constituted fairness, and what kinds of communication >>>>>> might be needed between databases, where more than one could >>>>>> supply available whitespace in a band. This doesn't have any of >>>>>> those issues, As long as it's just sending information, I don't >>>>>> have a problem. Once the database is supposed to do anything >>>>>> with it that involves changing what spectrum it reports, then I >>>>>> think we cross the line. >>>>>> >>>>>> Brian >>>>>> >>>>>> On Mar 6, 2012, at 12:28 PM, >>>>>> wrote: >>>>>> >>>>>>> Joel >>>>>>> >>>>>>> Indeed, the regulator has not described the process or provided >>>>>>> a flow diagram, so there may be some wrinkles, but we need to >>>>>>> provide for their intent. To answer your question, the channels >>>>>>> that the master will use are sent in a separate message >>>>>>> (described in P.12 ter), that occurs after the master receives >>>>>>> the response to its channel request, but before the master can >>>>>>> transmit. At this point, it knows what channels are available, >>>>>>> and which one it will use. As far as the slaves are concerned, >>>>>>> as they associate, the master will need to gather their details >>>>>>> and send further channel usage messages to the database on >>>>>>> their behalf. >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Andy >>>>>>> >>>>>>> -----Original Message----- From: paws-bounces@ietf.org >>>>>>> [mailto:paws-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>>>>> Sent: 06 March 2012 17:05 To: scott.probasco@nokia.com Cc: >>>>>>> paws@ietf.org; Cheeseman,CJ,Chris,COD R; Dixon,JS,Johnny,COD R >>>>>>> Subject: Re: [paws] WGLC for >>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel >>>>>>> reporting >>>>>>> >>>>>>> Ahh. I think I see where the request and my understanding >>>>>>> divurge. If the idea here is that the master must provide, in >>>>>>> the request, an indication of what channels it expects to use, >>>>>>> I can at least understand that. I will return to technical >>>>>>> concerns in a moment. >>>>>>> >>>>>>> However, when you say "provide channel usage information, in >>>>>>> order to evaluate interference", what that says to me is >>>>>>> providing, during operation, information as to what channels >>>>>>> are being used, and at what power levels. That is what would >>>>>>> be needed to analyze actual interference effects. And that is >>>>>>> out of scope as I understand our scope. >>>>>>> >>>>>>> I do see a technical difficulty with having the master provide, >>>>>>> as part of either registering or requesting spectrum >>>>>>> information, what channels it intends to use. It doesn;t know >>>>>>> what channels it intends to use. It intends to use some number >>>>>>> of available channels. It will figure out which ones when it >>>>>>> is told what is available. How can it send that information in >>>>>>> the request? >>>>>>> >>>>>>> Yours, Joel >>>>>>> >>>>>>> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> There is a similarity here with device ID. In context of PAWS >>>>>>>> we are not concerned with why a device ID is required by a >>>>>>>> regulator, we accept it is a requirement from a regulator and >>>>>>>> include it to the protocol. Ofcom identifies in 3.18& 3.19 >>>>>>>> that channel usage information is required and thus we need >>>>>>>> to include this information. Since the master must provide >>>>>>>> this information prior to transmitting, PAWS will not >>>>>>>> function in the UK without this information and thus I >>>>>>>> believe channel usage information is integral to the channel >>>>>>>> request& response messaging. >>>>>>>> >>>>>>>> Kind Regards, Scott >>>>>>>> >>>>>>>> >>>>>>>> On 3/6/12 10:30 AM, "ext Joel M. >>>>>>>> Halpern" wrote: >>>>>>>> >>>>>>>>> I would draw a distinction. Ofcom regulations about >>>>>>>>> whitespace requests are very much relevant. Ofcom >>>>>>>>> regulations about notification of dynamic behavior (which >>>>>>>>> spectrum is being used) are not in scope as I understand >>>>>>>>> the earlier discussions, particularly the chartering >>>>>>>>> discussions. >>>>>>>>> >>>>>>>>> Yours, Joel >>>>>>>>> >>>>>>>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: >>>>>>>>>> >>>>>>>>>> The ofcom requirements are very much relevant to the >>>>>>>>>> scope of the PAWS WG. The only other regulatory >>>>>>>>>> requirements that we have today is the FCC. Ofcom >>>>>>>>>> requirements are a good addition to the set. >>>>>>>>>> >>>>>>>>>> -Raj >>>>>>>>>> >>>>>>>>>> On 3/6/12 10:03 AM, "ext >>>>>>>>>> andy.sago@bt.com" wrote: >>>>>>>>>> >>>>>>>>>>> Hi Joel >>>>>>>>>>> >>>>>>>>>>> There's no language I can find in the charter that >>>>>>>>>>> explicitly puts this out of scope. On the other hand, >>>>>>>>>>> the charter says that the group will "consider input >>>>>>>>>>> from regulatory entities", and this is one of the >>>>>>>>>>> requirements from Ofcom that they have just published. >>>>>>>>>>> The protocol will be worthless for the UK if it omits >>>>>>>>>>> some requirements. >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> >>>>>>>>>>> Andy >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- From: Joel M. Halpern >>>>>>>>>>> [mailto:jmh@joelhalpern.com] Sent: 06 March 2012 15:53 >>>>>>>>>>> To: Sago,AJ,Andy,COD R Cc: paws@ietf.org; >>>>>>>>>>> Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for >>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel >>>>>>>>>>> reporting >>>>>>>>>>> >>>>>>>>>>> As I understand, the information you are asking for is >>>>>>>>>>> explicitly out of scope for the working group. Yours, >>>>>>>>>>> Joel >>>>>>>>>>> >>>>>>>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >>>>>>>>>>>> All >>>>>>>>>>>> >>>>>>>>>>>> Comparing the draft with the Ofcom requirements at >>>>>>>>>>>> http://www.cept.org/Documents/se- >>> 43/4161/SE43(12)Info03_Draft-UK-r >>>>>>>>>>>> >>>>>>>>>>>> >>> egul >>>>>>>>>>>> atory-requirements-for-white-space-devices-in-the-UHF-TV- >>> band, >>>>>>>>>>>> >>>>>>>>>>>> >>> I believe the WG draft is deficient in the area of reporting >>>>>>>>>>>> frequencies and powers actually used by masters and >>>>>>>>>>>> slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom >>>>>>>>>>>> intends to collect this data to assesses the impact >>>>>>>>>>>> of aggregate interference into other services. It >>>>>>>>>>>> would also provide usage information (frequency in >>>>>>>>>>>> use) that would inform the operation of a kill switch >>>>>>>>>>>> capability. I suggest this deficiency can be remedied >>>>>>>>>>>> with the following changes: >>>>>>>>>>>> >>>>>>>>>>>> New P requirements (probably best placed following >>>>>>>>>>>> P.12): >>>>>>>>>>>> >>>>>>>>>>>> P.12bis: The protocol MUST support a channel usage >>>>>>>>>>>> message from the slave device to the master device. >>>>>>>>>>>> The channel usage message MUST include parameters as >>>>>>>>>>>> required by local regulatory requirement. These >>>>>>>>>>>> parameters MAY include device ID, manufacturer's >>>>>>>>>>>> serial number, channel usage and power level >>>>>>>>>>>> information. >>>>>>>>>>>> >>>>>>>>>>>> P.12ter: The protocol MUST support a channel usage >>>>>>>>>>>> message from the master device to the database. The >>>>>>>>>>>> channel usage message MUST include parameters as >>>>>>>>>>>> required by local regulatory requirement for the >>>>>>>>>>>> master and its associated slaves. These parameters >>>>>>>>>>>> MAY include device ID, manufacturer's serial number, >>>>>>>>>>>> channel usage and power level information. >>>>>>>>>>>> >>>>>>>>>>>> P.12qua: The protocol MUST support a channel usage >>>>>>>>>>>> message acknowledgement. >>>>>>>>>>>> >>>>>>>>>>>> New O requirements (probably best placed following >>>>>>>>>>>> O13): >>>>>>>>>>>> >>>>>>>>>>>> O.13bis: According to local regulatory policy, after >>>>>>>>>>>> connecting to a master device's radio network a slave >>>>>>>>>>>> device MAY inform the master device of the actual >>>>>>>>>>>> channel usage. The slave MUST include parameters >>>>>>>>>>>> required by local regulatory policy, e.g. device ID, >>>>>>>>>>>> manufacturer's serial number, channel usage and power >>>>>>>>>>>> level information. >>>>>>>>>>>> >>>>>>>>>>>> O.13ter: According to local regulatory policy, a >>>>>>>>>>>> master device MAY inform the database of the actual >>>>>>>>>>>> channel usage of the master and its slaves. The >>>>>>>>>>>> master MUST include parameters required by local >>>>>>>>>>>> regulatory policy, e.g. device ID, manufacturer's >>>>>>>>>>>> serial number, channel usage and power level >>>>>>>>>>>> information of the master and its slaves. >>>>>>>>>>>> >>>>>>>>>>>> New steps could be introduced into one or more use >>>>>>>>>>>> cases to cover these Ofcom requirements, e.g. new >>>>>>>>>>>> steps 6bis and 9bis in the hotspot use case at >>>>>>>>>>>> 4.2.1: >>>>>>>>>>>> >>>>>>>>>>>> 6bis. Prior to initiating transmission, if required >>>>>>>>>>>> by local regulation, the master/AP informs the >>>>>>>>>>>> database of the channel and power level it has >>>>>>>>>>>> chosen. This is repeated for each slave that >>>>>>>>>>>> associated with the master. >>>>>>>>>>>> >>>>>>>>>>>> 9bis. Prior to initiating transmission, if required >>>>>>>>>>>> by local regulation, the slave informs the master/AP >>>>>>>>>>>> of the channel and power level it has chosen, and the >>>>>>>>>>>> master/AP relays this information to the database. >>>>>>>>>>>> >>>>>>>>>>>> - end of new text - >>>>>>>>>>>> >>>>>>>>>>>> For information, for those not accessing the url in >>>>>>>>>>>> the first paragraph of this email, the full Ofcom >>>>>>>>>>>> requirements leading to this new PAWS text are as >>>>>>>>>>>> follows: >>>>>>>>>>>> >>>>>>>>>>>> 3.18 After receiving instructions from a WSDB in >>>>>>>>>>>> relation to the maximum permitted EIRPs over the DTT >>>>>>>>>>>> channels, and prior to initiating transmissions >>>>>>>>>>>> within the UHF TV band, a master WSD must communicate >>>>>>>>>>>> to the WSDB the following information: >>>>>>>>>>>> >>>>>>>>>>>> 3.18.1 The lower and upper frequency boundaries^13 of >>>>>>>>>>>> the in-block emissions of the master WSD, and those >>>>>>>>>>>> of the in-block emissions of its associated slaves. A >>>>>>>>>>>> lower frequency will be specified as (470 + 8k + >>>>>>>>>>>> 0.2n) MHz, with the corresponding upper frequency >>>>>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3Ž4 k 3Ž4 >>>>>>>>>>>> 39, 0 3Ž4 n 3Ž4 39, 1 3Ž4 m 3Ž4 40, and n< m. >>>>>>>>>>>> >>>>>>>>>>>> 3.18.2 The maximum in-block EIRP spectral densities >>>>>>>>>>>> (in dBm/(0.2 MHz)) that the master WSD, and its >>>>>>>>>>>> associated slaves, actually radiate between each >>>>>>>>>>>> reported lower frequency boundary and its >>>>>>>>>>>> corresponding upper frequency boundary. >>>>>>>>>>>> >>>>>>>>>>>> Footnote 13 states: >>>>>>>>>>>> >>>>>>>>>>>> The use of upper and lower frequency boundaries >>>>>>>>>>>> (defined over a 200 kHz raster) allows a WSDB to >>>>>>>>>>>> collect more granular information with regards to the >>>>>>>>>>>> usage of the frequency resource by narrowband WSD >>>>>>>>>>>> technologies. The upper and lower frequencies of a >>>>>>>>>>>> boundary pair do not straddle a DTT channel boundary. >>>>>>>>>>>> Note that a WSD may transmit over multiple, >>>>>>>>>>>> non-contiguous, whole DTT channels or fractions of >>>>>>>>>>>> DTT channels. >>>>>>>>>>>> >>>>>>>>>>>> 3.19 A master WSD must be able to receive the >>>>>>>>>>>> following information^14 from a WSDB: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in the >>>>>>>>>>>> context of 3.18, that the reported information on the >>>>>>>>>>>> DTT channels and EIRP spectral densities actually >>>>>>>>>>>> used by the master and slave WSDs were received >>>>>>>>>>>> successfully by the WSDB^18 ]. >>>>>>>>>>>> >>>>>>>>>>>> Footnote 14 states: >>>>>>>>>>>> >>>>>>>>>>>> 14 While the communication of some of this >>>>>>>>>>>> information from a WSDB to a master WSD is optional, >>>>>>>>>>>> master WSDs must be able to receive and interpret >>>>>>>>>>>> these. >>>>>>>>>>>> >>>>>>>>>>>> Footnote 18 states: >>>>>>>>>>>> >>>>>>>>>>>> 18 This forms part of a handshake protocol and may be >>>>>>>>>>>> an area where industry could harmonise without the >>>>>>>>>>>> need for an explicit requirement in the regulations. >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> >>>>>>>>>>>> Andy >>>>>>>>>>>> >>>>>>>>>>>> *From:*paws-bounces@ietf.org >>>>>>>>>>>> [mailto:paws-bounces@ietf.org] *On Behalf Of >>>>>>>>>>>> *Gabor.Bajko@nokia.com *Sent:* 05 March 2012 19:46 >>>>>>>>>>>> *To:* paws@ietf.org *Subject:* [paws] WGLC for >>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >>>>>>>>>>>> >>>>>>>>>>>> The authors of the use cases and requirements draft >>>>>>>>>>>> have just posted a new version of the draft and >>>>>>>>>>>> indicated that there are no unresolved >>>>>>>>>>>> comments/issues they are aware of. >>>>>>>>>>>> >>>>>>>>>>>> Therefore, I'd like to initiate a WG Last Call for >>>>>>>>>>>> comments on >>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-paws-problem- >>> stmt-u >>>>>>>>>>>> >>>>>>>>>>>> >>> seca >>>>>>>>>>>> ses-rqmts-03.txt >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Please review the draft and send your comments to the >>>>>>>>>>>> list by March 20th, 2012. >>>>>>>>>>>> >>>>>>>>>>>> If you review the draft and have no comments, send a >>>>>>>>>>>> note to the list that the draft is good as it is, we >>>>>>>>>>>> need these notes as much as we need the actual >>>>>>>>>>>> comments. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, Gabor >>>>>>>>>>>> >>>>>>>>>>>> From scott.probasco@nokia.com Thu Mar 8 10:10:15 2012 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 CD9A121F8557 for ; Thu, 8 Mar 2012 10:10:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.518 X-Spam-Level: X-Spam-Status: No, score=-3.518 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4, 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 emPXXIwN5o9X for ; Thu, 8 Mar 2012 10:10:12 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4C021F84B9 for ; Thu, 8 Mar 2012 10:10:09 -0800 (PST) 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 q28IA0LQ032020; Thu, 8 Mar 2012 20:10:01 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 20:10:00 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.129]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0355.003; Thu, 8 Mar 2012 19:09:57 +0100 From: To: Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting Thread-Index: AQHM/U9pVDIWW94XR02640QOS6jbCJZgmVoA//+kAoA= Date: Thu, 8 Mar 2012 18:09:57 +0000 Message-ID: In-Reply-To: <4F58EEBE.8070101@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.243.0.216] Content-Type: text/plain; charset="iso-8859-2" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Mar 2012 18:10:00.0651 (UTC) FILETIME=[AD7C21B0:01CCFD56] X-Nokia-AV: Clean Cc: paws@ietf.org, presnick@qualcomm.com, johnny.dixon@bt.com, chris.cheeseman@bt.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 18:10:16 -0000 Hi Peter, Answers below. Kind Regards, Scott On 3/8/12 11:39 AM, "ext Peter Saint-Andre" wrote: >Hi Scott, I have two clarifying questions: > >1. Does the device know, when it receives the channel response, which >channel it will actually use? Scott->This is all new and I am not aware of any existing implementations. I would argue that the device must decide what channel(s) it will use when it receives the channel response. > >2. If the device then uses another channel or a different channel, does >it need to report that change to the database? Scott->My interpretation of section 3.18 is that the device can only transmit within the upper & lower frequencies returned in the acknowledgment. I do not (quickly) find any reference in the requirements to changing channels. Thus operationally it could be that the channel request process must be repeated before the device can use a different channel (frequencies). > >Thanks! > >Peter > >On 3/8/12 10:17 AM, scott.probasco@nokia.com wrote: >> Hi, >>=20 >> The point from Brian is very relevant: >>=20 >> Channel request >> Channel response >> Channel acknowledgement >>=20 >> What Ofcom does with the information in the acknowledgement does not >> matter. As the regulator in UK, they write rules that must be followed >>in >> order to operate a whitespace radio in the UK. I believe the scope of >>the >> WG must be focused on a working solution. If this is simple channel >> request & response in one regulator's domain, PAWS can support this. If >>it >> means a channel request, response and acknowledgement in another >> regulator's domain, PAWS can support this. As a participating member of >> the work group, I believe the scope should be basic working solution, >>not >> limited to a specific number of messages. >>=20 >> Kind Regards, >> Scott >>=20 >>=20 >>=20 >> On 3/8/12 11:11 AM, "ext Zuniga, Juan Carlos" >> wrote: >>=20 >>> Peter, Nancy, >>> >>> I agree should design a protocol with the best of our current >>>knowledge, >>> and that should be accounting for all the known regulations at present >>> time. We should not limit the scope with the purpose of designing a >>> protocol 'faster'. Our goal is not only to design a WSDB protocol. Our >>> goal is to design a WSDB protocol that is USEFUL to the community. >>> >>> The charter does state that >>> >>> "...the group should also reach out to other potential >>> "customers" for a white space database access method and consider input >>>from regulatory entities that are involved in the specification of the >>> rules for secondary use of spectrum in specific radio bands. " >>> >>> I think that is exactly what we are doing now. >>> >>> Regarding whether the types of requirements belong to #1 or #2, I >>>believe >>> it is more of #1 type, as the information to be exchanged would be >>>known >>> after the initial query/response. >>> >>> If we know it today, I see no reason why we should not work on it in >>>the >>> first phase of the work. >>> >>> Regards, >>> >>> Juan Carlos >>> >>>> -----Original Message----- >>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >>>>Of >>>> Peter Saint-Andre >>>> Sent: Thursday, March 08, 2012 11:59 AM >>>> To: Nancy Bravin >>>> Cc: paws@ietf.org; johnny.dixon@bt.com; chris.cheeseman@bt.com; Pete >>>> Resnick >>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >>>> rqmts-03: channel reporting >>>> >>>> Hi Nancy, >>>> >>>> You are absolutely right that different locales will have different >>>> rules and requirements. We need to understand those, and work to >>>> address >>>> them if possible (although we don't necessarily need to address them >>>> all >>>> at the same time). I see several kinds of requirements: >>>> >>>> 1. Some requirements might lead to features beyond the query/response >>>> protocol we've envisioned so far. One example might be real-time >>>> reporting about the channels that a device is actually using. In my >>>> opinion, it would be best to handle those in the next phase of work, >>>> because as far as I can see they are outside the scope of our charter. >>>> >>>> 2. Some requirements might be handled through by defining additional >>>> fields that can be included in the query or response. We definitely >>>> planned for that when working on the charter with the IESG: >>>> >>>> In addition, the particular >>>> data exchanged between a device and a database might depend on the >>>> ranges of radio spectrum that are to be used, the requirements of >>>>the >>>> database operators and their governing regulations, and other >>>> factors. >>>> Therefore, the database access method and the query/response data >>>> formats that are exchanged using that method need to be designed for >>>> extensibility rather than being tied to any specific spectrum, >>>> country, or phy/mac/air interface. >>>> >>>> It's unclear to me right now if the Ofcom requirement fits into #1 or >>>> #2, which is why we're having this discussion. :) >>>> >>>> Peter >>>> >>>> On 3/7/12 8:17 PM, Nancy Bravin wrote: >>>>> Peter and all, >>>>> >>>>> I agree that it is important to revisit now, so that in the future, >>>>> it will be easy to align things in their proper place. Every country >>>>> may have different regulations, spectrum, policy and what >>>>> responsibility is in the domain of the system, and what comes under >>>>> the PAWS charter is important. Maybe some separation might be >>>>> possible, and dividing and clarifying issues now will help in the >>>>> future. Certainly it seems that the FCC may change some rules, and >>>>> we know that Ofcom is not yet finished with their regulations. Canada >>>>> has their own, and other countries are working on this as well. Just >>>>> a thought...Sharing is a realistic goal...as is off loading... Or you >>>>> slim line and every 6 months decide what to incorporate in the >>>>> protocol based on new information, new ideas, new innovation new >>>>> regulations and maybe spend more time than you could if addressed >>>>> now. >>>>> >>>>> That way you leave the door open and outside of referencing what is >>>>> known today, by referencing regulations i.e. Ofcom, FCC, Industry >>>>> Canada etc as of XX-XX-XXXX date. Out of scope not something we know >>>>> enough about to say at this point, In my opinion. >>>>> >>>>> My 2 cents.. >>>>> >>>>> Sincerely, Nancy >>>>> >>>>> On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote: >>>>> >>>>>> >>>>>> >>>>>> As your responsible Area Director (until March 28, when Pete >>>>>> Resnick will take over from me), I have reviewed this thread. >>>>>> >>>>>> In my opinion (I am happy to be proven wrong), this new requirement >>>>>> goes beyond what the charter defined as the scope of this working >>>>>> group, which was to enable a device to discover the white space >>>>>> available to it in its current location. Reporting usage back to >>>>>> the database is simply not mentioned in the charter. >>>>>> >>>>>> Earlier in this thread, Andy Sago wrote: >>>>>> >>>>>> There's no language I can find in the charter that explicitly puts >>>>>> this out of scope. >>>>>> >>>>>> An IETF charter defines what the working group shall work on. Many >>>>>> interesting features could be developed here. However, it is not >>>>>> the job of the charter to mention explicitly that each of those >>>>>> interesting features is out of scope. >>>>>> >>>>>> The charter does say: >>>>>> >>>>>> Once the device learns of the available white space (e.g., in a TV >>>>>> white space implementation, the list of available channels at that >>>>>> location), it can then select one of the bands from the list and >>>>>> begin to transmit and receive on the selected band. >>>>>> >>>>>> This text might have assumed that no further communication or >>>>>> authorization was required in order to select one of the bands from >>>>>> the list and then transmit/receive. Perhaps that assumption was >>>>>> mistaken. If so, it would be good to have a discussion about that, >>>>>> so we can determine if we need to revisit the assumptions we made >>>>>> early on. If in fact we made some faulty or limited assumptions, >>>>>> then let's get that out in the open. >>>>>> >>>>>> Peter >>>>>> >>>>>> On 3/7/12 9:40 AM, Rosen, Brian wrote: >>>>>>> I'd also suggest that our >>>>>>> charter limitation is really support for sharing of whitespace by >>>>>>> whitespace devices. Reporting what you use is not sharing, it's >>>>>>> just data gathering. >>>>>>> >>>>>>> The point of excluding sharing was to eliminate the complexities >>>>>>> of what constituted fairness, and what kinds of communication >>>>>>> might be needed between databases, where more than one could >>>>>>> supply available whitespace in a band. This doesn't have any of >>>>>>> those issues, As long as it's just sending information, I don't >>>>>>> have a problem. Once the database is supposed to do anything >>>>>>> with it that involves changing what spectrum it reports, then I >>>>>>> think we cross the line. >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>> On Mar 6, 2012, at 12:28 PM, >>>>>>> wrote: >>>>>>> >>>>>>>> Joel >>>>>>>> >>>>>>>> Indeed, the regulator has not described the process or provided >>>>>>>> a flow diagram, so there may be some wrinkles, but we need to >>>>>>>> provide for their intent. To answer your question, the channels >>>>>>>> that the master will use are sent in a separate message >>>>>>>> (described in P.12 ter), that occurs after the master receives >>>>>>>> the response to its channel request, but before the master can >>>>>>>> transmit. At this point, it knows what channels are available, >>>>>>>> and which one it will use. As far as the slaves are concerned, >>>>>>>> as they associate, the master will need to gather their details >>>>>>>> and send further channel usage messages to the database on >>>>>>>> their behalf. >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Andy >>>>>>>> >>>>>>>> -----Original Message----- From: paws-bounces@ietf.org >>>>>>>> [mailto:paws-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>>>>>> Sent: 06 March 2012 17:05 To: scott.probasco@nokia.com Cc: >>>>>>>> paws@ietf.org; Cheeseman,CJ,Chris,COD R; Dixon,JS,Johnny,COD R >>>>>>>> Subject: Re: [paws] WGLC for >>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel >>>>>>>> reporting >>>>>>>> >>>>>>>> Ahh. I think I see where the request and my understanding >>>>>>>> divurge. If the idea here is that the master must provide, in >>>>>>>> the request, an indication of what channels it expects to use, >>>>>>>> I can at least understand that. I will return to technical >>>>>>>> concerns in a moment. >>>>>>>> >>>>>>>> However, when you say "provide channel usage information, in >>>>>>>> order to evaluate interference", what that says to me is >>>>>>>> providing, during operation, information as to what channels >>>>>>>> are being used, and at what power levels. That is what would >>>>>>>> be needed to analyze actual interference effects. And that is >>>>>>>> out of scope as I understand our scope. >>>>>>>> >>>>>>>> I do see a technical difficulty with having the master provide, >>>>>>>> as part of either registering or requesting spectrum >>>>>>>> information, what channels it intends to use. It doesn;t know >>>>>>>> what channels it intends to use. It intends to use some number >>>>>>>> of available channels. It will figure out which ones when it >>>>>>>> is told what is available. How can it send that information in >>>>>>>> the request? >>>>>>>> >>>>>>>> Yours, Joel >>>>>>>> >>>>>>>> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> There is a similarity here with device ID. In context of PAWS >>>>>>>>> we are not concerned with why a device ID is required by a >>>>>>>>> regulator, we accept it is a requirement from a regulator and >>>>>>>>> include it to the protocol. Ofcom identifies in 3.18& 3.19 >>>>>>>>> that channel usage information is required and thus we need >>>>>>>>> to include this information. Since the master must provide >>>>>>>>> this information prior to transmitting, PAWS will not >>>>>>>>> function in the UK without this information and thus I >>>>>>>>> believe channel usage information is integral to the channel >>>>>>>>> request& response messaging. >>>>>>>>> >>>>>>>>> Kind Regards, Scott >>>>>>>>> >>>>>>>>> >>>>>>>>> On 3/6/12 10:30 AM, "ext Joel M. >>>>>>>>> Halpern" wrote: >>>>>>>>> >>>>>>>>>> I would draw a distinction. Ofcom regulations about >>>>>>>>>> whitespace requests are very much relevant. Ofcom >>>>>>>>>> regulations about notification of dynamic behavior (which >>>>>>>>>> spectrum is being used) are not in scope as I understand >>>>>>>>>> the earlier discussions, particularly the chartering >>>>>>>>>> discussions. >>>>>>>>>> >>>>>>>>>> Yours, Joel >>>>>>>>>> >>>>>>>>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: >>>>>>>>>>> >>>>>>>>>>> The ofcom requirements are very much relevant to the >>>>>>>>>>> scope of the PAWS WG. The only other regulatory >>>>>>>>>>> requirements that we have today is the FCC. Ofcom >>>>>>>>>>> requirements are a good addition to the set. >>>>>>>>>>> >>>>>>>>>>> -Raj >>>>>>>>>>> >>>>>>>>>>> On 3/6/12 10:03 AM, "ext >>>>>>>>>>> andy.sago@bt.com" wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Joel >>>>>>>>>>>> >>>>>>>>>>>> There's no language I can find in the charter that >>>>>>>>>>>> explicitly puts this out of scope. On the other hand, >>>>>>>>>>>> the charter says that the group will "consider input >>>>>>>>>>>> from regulatory entities", and this is one of the >>>>>>>>>>>> requirements from Ofcom that they have just published. >>>>>>>>>>>> The protocol will be worthless for the UK if it omits >>>>>>>>>>>> some requirements. >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> >>>>>>>>>>>> Andy >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- From: Joel M. Halpern >>>>>>>>>>>> [mailto:jmh@joelhalpern.com] Sent: 06 March 2012 15:53 >>>>>>>>>>>> To: Sago,AJ,Andy,COD R Cc: paws@ietf.org; >>>>>>>>>>>> Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for >>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel >>>>>>>>>>>> reporting >>>>>>>>>>>> >>>>>>>>>>>> As I understand, the information you are asking for is >>>>>>>>>>>> explicitly out of scope for the working group. Yours, >>>>>>>>>>>> Joel >>>>>>>>>>>> >>>>>>>>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >>>>>>>>>>>>> All >>>>>>>>>>>>> >>>>>>>>>>>>> Comparing the draft with the Ofcom requirements at >>>>>>>>>>>>> http://www.cept.org/Documents/se- >>>> 43/4161/SE43(12)Info03_Draft-UK-r >>>>>>>>>>>>> >>>>>>>>>>>>> >>>> egul >>>>>>>>>>>>> atory-requirements-for-white-space-devices-in-the-UHF-TV- >>>> band, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>> I believe the WG draft is deficient in the area of reporting >>>>>>>>>>>>> frequencies and powers actually used by masters and >>>>>>>>>>>>> slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom >>>>>>>>>>>>> intends to collect this data to assesses the impact >>>>>>>>>>>>> of aggregate interference into other services. It >>>>>>>>>>>>> would also provide usage information (frequency in >>>>>>>>>>>>> use) that would inform the operation of a kill switch >>>>>>>>>>>>> capability. I suggest this deficiency can be remedied >>>>>>>>>>>>> with the following changes: >>>>>>>>>>>>> >>>>>>>>>>>>> New P requirements (probably best placed following >>>>>>>>>>>>> P.12): >>>>>>>>>>>>> >>>>>>>>>>>>> P.12bis: The protocol MUST support a channel usage >>>>>>>>>>>>> message from the slave device to the master device. >>>>>>>>>>>>> The channel usage message MUST include parameters as >>>>>>>>>>>>> required by local regulatory requirement. These >>>>>>>>>>>>> parameters MAY include device ID, manufacturer's >>>>>>>>>>>>> serial number, channel usage and power level >>>>>>>>>>>>> information. >>>>>>>>>>>>> >>>>>>>>>>>>> P.12ter: The protocol MUST support a channel usage >>>>>>>>>>>>> message from the master device to the database. The >>>>>>>>>>>>> channel usage message MUST include parameters as >>>>>>>>>>>>> required by local regulatory requirement for the >>>>>>>>>>>>> master and its associated slaves. These parameters >>>>>>>>>>>>> MAY include device ID, manufacturer's serial number, >>>>>>>>>>>>> channel usage and power level information. >>>>>>>>>>>>> >>>>>>>>>>>>> P.12qua: The protocol MUST support a channel usage >>>>>>>>>>>>> message acknowledgement. >>>>>>>>>>>>> >>>>>>>>>>>>> New O requirements (probably best placed following >>>>>>>>>>>>> O13): >>>>>>>>>>>>> >>>>>>>>>>>>> O.13bis: According to local regulatory policy, after >>>>>>>>>>>>> connecting to a master device's radio network a slave >>>>>>>>>>>>> device MAY inform the master device of the actual >>>>>>>>>>>>> channel usage. The slave MUST include parameters >>>>>>>>>>>>> required by local regulatory policy, e.g. device ID, >>>>>>>>>>>>> manufacturer's serial number, channel usage and power >>>>>>>>>>>>> level information. >>>>>>>>>>>>> >>>>>>>>>>>>> O.13ter: According to local regulatory policy, a >>>>>>>>>>>>> master device MAY inform the database of the actual >>>>>>>>>>>>> channel usage of the master and its slaves. The >>>>>>>>>>>>> master MUST include parameters required by local >>>>>>>>>>>>> regulatory policy, e.g. device ID, manufacturer's >>>>>>>>>>>>> serial number, channel usage and power level >>>>>>>>>>>>> information of the master and its slaves. >>>>>>>>>>>>> >>>>>>>>>>>>> New steps could be introduced into one or more use >>>>>>>>>>>>> cases to cover these Ofcom requirements, e.g. new >>>>>>>>>>>>> steps 6bis and 9bis in the hotspot use case at >>>>>>>>>>>>> 4.2.1: >>>>>>>>>>>>> >>>>>>>>>>>>> 6bis. Prior to initiating transmission, if required >>>>>>>>>>>>> by local regulation, the master/AP informs the >>>>>>>>>>>>> database of the channel and power level it has >>>>>>>>>>>>> chosen. This is repeated for each slave that >>>>>>>>>>>>> associated with the master. >>>>>>>>>>>>> >>>>>>>>>>>>> 9bis. Prior to initiating transmission, if required >>>>>>>>>>>>> by local regulation, the slave informs the master/AP >>>>>>>>>>>>> of the channel and power level it has chosen, and the >>>>>>>>>>>>> master/AP relays this information to the database. >>>>>>>>>>>>> >>>>>>>>>>>>> - end of new text - >>>>>>>>>>>>> >>>>>>>>>>>>> For information, for those not accessing the url in >>>>>>>>>>>>> the first paragraph of this email, the full Ofcom >>>>>>>>>>>>> requirements leading to this new PAWS text are as >>>>>>>>>>>>> follows: >>>>>>>>>>>>> >>>>>>>>>>>>> 3.18 After receiving instructions from a WSDB in >>>>>>>>>>>>> relation to the maximum permitted EIRPs over the DTT >>>>>>>>>>>>> channels, and prior to initiating transmissions >>>>>>>>>>>>> within the UHF TV band, a master WSD must communicate >>>>>>>>>>>>> to the WSDB the following information: >>>>>>>>>>>>> >>>>>>>>>>>>> 3.18.1 The lower and upper frequency boundaries^13 of >>>>>>>>>>>>> the in-block emissions of the master WSD, and those >>>>>>>>>>>>> of the in-block emissions of its associated slaves. A >>>>>>>>>>>>> lower frequency will be specified as (470 + 8k + >>>>>>>>>>>>> 0.2n) MHz, with the corresponding upper frequency >>>>>>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3=AE4 k 3=AE4 >>>>>>>>>>>>> 39, 0 3=AE4 n 3=AE4 39, 1 3=AE4 m 3=AE4 40, and n< m. >>>>>>>>>>>>> >>>>>>>>>>>>> 3.18.2 The maximum in-block EIRP spectral densities >>>>>>>>>>>>> (in dBm/(0.2 MHz)) that the master WSD, and its >>>>>>>>>>>>> associated slaves, actually radiate between each >>>>>>>>>>>>> reported lower frequency boundary and its >>>>>>>>>>>>> corresponding upper frequency boundary. >>>>>>>>>>>>> >>>>>>>>>>>>> Footnote 13 states: >>>>>>>>>>>>> >>>>>>>>>>>>> The use of upper and lower frequency boundaries >>>>>>>>>>>>> (defined over a 200 kHz raster) allows a WSDB to >>>>>>>>>>>>> collect more granular information with regards to the >>>>>>>>>>>>> usage of the frequency resource by narrowband WSD >>>>>>>>>>>>> technologies. The upper and lower frequencies of a >>>>>>>>>>>>> boundary pair do not straddle a DTT channel boundary. >>>>>>>>>>>>> Note that a WSD may transmit over multiple, >>>>>>>>>>>>> non-contiguous, whole DTT channels or fractions of >>>>>>>>>>>>> DTT channels. >>>>>>>>>>>>> >>>>>>>>>>>>> 3.19 A master WSD must be able to receive the >>>>>>>>>>>>> following information^14 from a WSDB: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in the >>>>>>>>>>>>> context of 3.18, that the reported information on the >>>>>>>>>>>>> DTT channels and EIRP spectral densities actually >>>>>>>>>>>>> used by the master and slave WSDs were received >>>>>>>>>>>>> successfully by the WSDB^18 ]. >>>>>>>>>>>>> >>>>>>>>>>>>> Footnote 14 states: >>>>>>>>>>>>> >>>>>>>>>>>>> 14 While the communication of some of this >>>>>>>>>>>>> information from a WSDB to a master WSD is optional, >>>>>>>>>>>>> master WSDs must be able to receive and interpret >>>>>>>>>>>>> these. >>>>>>>>>>>>> >>>>>>>>>>>>> Footnote 18 states: >>>>>>>>>>>>> >>>>>>>>>>>>> 18 This forms part of a handshake protocol and may be >>>>>>>>>>>>> an area where industry could harmonise without the >>>>>>>>>>>>> need for an explicit requirement in the regulations. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards >>>>>>>>>>>>> >>>>>>>>>>>>> Andy >>>>>>>>>>>>> >>>>>>>>>>>>> *From:*paws-bounces@ietf.org >>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] *On Behalf Of >>>>>>>>>>>>> *Gabor.Bajko@nokia.com *Sent:* 05 March 2012 19:46 >>>>>>>>>>>>> *To:* paws@ietf.org *Subject:* [paws] WGLC for >>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >>>>>>>>>>>>> >>>>>>>>>>>>> The authors of the use cases and requirements draft >>>>>>>>>>>>> have just posted a new version of the draft and >>>>>>>>>>>>> indicated that there are no unresolved >>>>>>>>>>>>> comments/issues they are aware of. >>>>>>>>>>>>> >>>>>>>>>>>>> Therefore, I'd like to initiate a WG Last Call for >>>>>>>>>>>>> comments on >>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-paws-problem- >>>> stmt-u >>>>>>>>>>>>> >>>>>>>>>>>>> >>>> seca >>>>>>>>>>>>> ses-rqmts-03.txt >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Please review the draft and send your comments to the >>>>>>>>>>>>> list by March 20th, 2012. >>>>>>>>>>>>> >>>>>>>>>>>>> If you review the draft and have no comments, send a >>>>>>>>>>>>> note to the list that the draft is good as it is, we >>>>>>>>>>>>> need these notes as much as we need the actual >>>>>>>>>>>>> comments. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, Gabor >>>>>>>>>>>>> >>>>>>>>>>>>> From jmh@joelhalpern.com Thu Mar 8 10:16:54 2012 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 EEE8021F86BA for ; Thu, 8 Mar 2012 10:16:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.802 X-Spam-Level: X-Spam-Status: No, score=-100.802 tagged_above=-999 required=5 tests=[AWL=-1.164, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, 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 MCMIaTUkvIhC for ; Thu, 8 Mar 2012 10:16:52 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 682A821F86B9 for ; Thu, 8 Mar 2012 10:16:52 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 596CED31C5 for ; Thu, 8 Mar 2012 10:16:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id A479E1C006BA; Thu, 8 Mar 2012 10:16:51 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.100] (pool-71-161-51-182.clppva.btas.verizon.net [71.161.51.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id F09D61C013A7; Thu, 8 Mar 2012 10:16:47 -0800 (PST) Message-ID: <4F58F78B.3030501@joelhalpern.com> Date: Thu, 08 Mar 2012 13:16:43 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: scott.probasco@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: paws@ietf.org, presnick@qualcomm.com, johnny.dixon@bt.com, chris.cheeseman@bt.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 18:16:54 -0000 So why won't the device simply say "I will use all of this?" After all, that way it needs to do less work with the database. And it can change frequencies when it wants. Given that the stated goal of the Ofcom requriement was to be able to analyze interference effects, it seems that this will not actually lead to them getting what they want, even if it does comply with the regulations. Yours, joel On 3/8/2012 1:09 PM, scott.probasco@nokia.com wrote: > Hi Peter, > > Answers below. > > Kind Regards, > Scott > > On 3/8/12 11:39 AM, "ext Peter Saint-Andre" wrote: > >> Hi Scott, I have two clarifying questions: >> >> 1. Does the device know, when it receives the channel response, which >> channel it will actually use? > Scott->This is all new and I am not aware of any existing implementations. > I would argue that the device must decide what channel(s) it will use when > it receives the channel response. >> >> 2. If the device then uses another channel or a different channel, does >> it need to report that change to the database? > Scott->My interpretation of section 3.18 is that the device can only > transmit within the upper& lower frequencies returned in the > acknowledgment. I do not (quickly) find any reference in the requirements > to changing channels. Thus operationally it could be that the channel > request process must be repeated before the device can use a different > channel (frequencies). >> >> Thanks! >> >> Peter >> >> On 3/8/12 10:17 AM, scott.probasco@nokia.com wrote: >>> Hi, >>> >>> The point from Brian is very relevant: >>> >>> Channel request >>> Channel response >>> Channel acknowledgement >>> >>> What Ofcom does with the information in the acknowledgement does not >>> matter. As the regulator in UK, they write rules that must be followed >>> in >>> order to operate a whitespace radio in the UK. I believe the scope of >>> the >>> WG must be focused on a working solution. If this is simple channel >>> request& response in one regulator's domain, PAWS can support this. If >>> it >>> means a channel request, response and acknowledgement in another >>> regulator's domain, PAWS can support this. As a participating member of >>> the work group, I believe the scope should be basic working solution, >>> not >>> limited to a specific number of messages. >>> >>> Kind Regards, >>> Scott >>> >>> >>> >>> On 3/8/12 11:11 AM, "ext Zuniga, Juan Carlos" >>> wrote: >>> >>>> Peter, Nancy, >>>> >>>> I agree should design a protocol with the best of our current >>>> knowledge, >>>> and that should be accounting for all the known regulations at present >>>> time. We should not limit the scope with the purpose of designing a >>>> protocol 'faster'. Our goal is not only to design a WSDB protocol. Our >>>> goal is to design a WSDB protocol that is USEFUL to the community. >>>> >>>> The charter does state that >>>> >>>> "...the group should also reach out to other potential >>>> "customers" for a white space database access method and consider input >>> >from regulatory entities that are involved in the specification of the >>>> rules for secondary use of spectrum in specific radio bands. " >>>> >>>> I think that is exactly what we are doing now. >>>> >>>> Regarding whether the types of requirements belong to #1 or #2, I >>>> believe >>>> it is more of #1 type, as the information to be exchanged would be >>>> known >>>> after the initial query/response. >>>> >>>> If we know it today, I see no reason why we should not work on it in >>>> the >>>> first phase of the work. >>>> >>>> Regards, >>>> >>>> Juan Carlos >>>> >>>>> -----Original Message----- >>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >>>>> Of >>>>> Peter Saint-Andre >>>>> Sent: Thursday, March 08, 2012 11:59 AM >>>>> To: Nancy Bravin >>>>> Cc: paws@ietf.org; johnny.dixon@bt.com; chris.cheeseman@bt.com; Pete >>>>> Resnick >>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >>>>> rqmts-03: channel reporting >>>>> >>>>> Hi Nancy, >>>>> >>>>> You are absolutely right that different locales will have different >>>>> rules and requirements. We need to understand those, and work to >>>>> address >>>>> them if possible (although we don't necessarily need to address them >>>>> all >>>>> at the same time). I see several kinds of requirements: >>>>> >>>>> 1. Some requirements might lead to features beyond the query/response >>>>> protocol we've envisioned so far. One example might be real-time >>>>> reporting about the channels that a device is actually using. In my >>>>> opinion, it would be best to handle those in the next phase of work, >>>>> because as far as I can see they are outside the scope of our charter. >>>>> >>>>> 2. Some requirements might be handled through by defining additional >>>>> fields that can be included in the query or response. We definitely >>>>> planned for that when working on the charter with the IESG: >>>>> >>>>> In addition, the particular >>>>> data exchanged between a device and a database might depend on the >>>>> ranges of radio spectrum that are to be used, the requirements of >>>>> the >>>>> database operators and their governing regulations, and other >>>>> factors. >>>>> Therefore, the database access method and the query/response data >>>>> formats that are exchanged using that method need to be designed for >>>>> extensibility rather than being tied to any specific spectrum, >>>>> country, or phy/mac/air interface. >>>>> >>>>> It's unclear to me right now if the Ofcom requirement fits into #1 or >>>>> #2, which is why we're having this discussion. :) >>>>> >>>>> Peter >>>>> >>>>> On 3/7/12 8:17 PM, Nancy Bravin wrote: >>>>>> Peter and all, >>>>>> >>>>>> I agree that it is important to revisit now, so that in the future, >>>>>> it will be easy to align things in their proper place. Every country >>>>>> may have different regulations, spectrum, policy and what >>>>>> responsibility is in the domain of the system, and what comes under >>>>>> the PAWS charter is important. Maybe some separation might be >>>>>> possible, and dividing and clarifying issues now will help in the >>>>>> future. Certainly it seems that the FCC may change some rules, and >>>>>> we know that Ofcom is not yet finished with their regulations. Canada >>>>>> has their own, and other countries are working on this as well. Just >>>>>> a thought...Sharing is a realistic goal...as is off loading... Or you >>>>>> slim line and every 6 months decide what to incorporate in the >>>>>> protocol based on new information, new ideas, new innovation new >>>>>> regulations and maybe spend more time than you could if addressed >>>>>> now. >>>>>> >>>>>> That way you leave the door open and outside of referencing what is >>>>>> known today, by referencing regulations i.e. Ofcom, FCC, Industry >>>>>> Canada etc as of XX-XX-XXXX date. Out of scope not something we know >>>>>> enough about to say at this point, In my opinion. >>>>>> >>>>>> My 2 cents.. >>>>>> >>>>>> Sincerely, Nancy >>>>>> >>>>>> On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> As your responsible Area Director (until March 28, when Pete >>>>>>> Resnick will take over from me), I have reviewed this thread. >>>>>>> >>>>>>> In my opinion (I am happy to be proven wrong), this new requirement >>>>>>> goes beyond what the charter defined as the scope of this working >>>>>>> group, which was to enable a device to discover the white space >>>>>>> available to it in its current location. Reporting usage back to >>>>>>> the database is simply not mentioned in the charter. >>>>>>> >>>>>>> Earlier in this thread, Andy Sago wrote: >>>>>>> >>>>>>> There's no language I can find in the charter that explicitly puts >>>>>>> this out of scope. >>>>>>> >>>>>>> An IETF charter defines what the working group shall work on. Many >>>>>>> interesting features could be developed here. However, it is not >>>>>>> the job of the charter to mention explicitly that each of those >>>>>>> interesting features is out of scope. >>>>>>> >>>>>>> The charter does say: >>>>>>> >>>>>>> Once the device learns of the available white space (e.g., in a TV >>>>>>> white space implementation, the list of available channels at that >>>>>>> location), it can then select one of the bands from the list and >>>>>>> begin to transmit and receive on the selected band. >>>>>>> >>>>>>> This text might have assumed that no further communication or >>>>>>> authorization was required in order to select one of the bands from >>>>>>> the list and then transmit/receive. Perhaps that assumption was >>>>>>> mistaken. If so, it would be good to have a discussion about that, >>>>>>> so we can determine if we need to revisit the assumptions we made >>>>>>> early on. If in fact we made some faulty or limited assumptions, >>>>>>> then let's get that out in the open. >>>>>>> >>>>>>> Peter >>>>>>> >>>>>>> On 3/7/12 9:40 AM, Rosen, Brian wrote: >>>>>>>> I'd also suggest that our >>>>>>>> charter limitation is really support for sharing of whitespace by >>>>>>>> whitespace devices. Reporting what you use is not sharing, it's >>>>>>>> just data gathering. >>>>>>>> >>>>>>>> The point of excluding sharing was to eliminate the complexities >>>>>>>> of what constituted fairness, and what kinds of communication >>>>>>>> might be needed between databases, where more than one could >>>>>>>> supply available whitespace in a band. This doesn't have any of >>>>>>>> those issues, As long as it's just sending information, I don't >>>>>>>> have a problem. Once the database is supposed to do anything >>>>>>>> with it that involves changing what spectrum it reports, then I >>>>>>>> think we cross the line. >>>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>> On Mar 6, 2012, at 12:28 PM, >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Joel >>>>>>>>> >>>>>>>>> Indeed, the regulator has not described the process or provided >>>>>>>>> a flow diagram, so there may be some wrinkles, but we need to >>>>>>>>> provide for their intent. To answer your question, the channels >>>>>>>>> that the master will use are sent in a separate message >>>>>>>>> (described in P.12 ter), that occurs after the master receives >>>>>>>>> the response to its channel request, but before the master can >>>>>>>>> transmit. At this point, it knows what channels are available, >>>>>>>>> and which one it will use. As far as the slaves are concerned, >>>>>>>>> as they associate, the master will need to gather their details >>>>>>>>> and send further channel usage messages to the database on >>>>>>>>> their behalf. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> Andy >>>>>>>>> >>>>>>>>> -----Original Message----- From: paws-bounces@ietf.org >>>>>>>>> [mailto:paws-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>>>>>>> Sent: 06 March 2012 17:05 To: scott.probasco@nokia.com Cc: >>>>>>>>> paws@ietf.org; Cheeseman,CJ,Chris,COD R; Dixon,JS,Johnny,COD R >>>>>>>>> Subject: Re: [paws] WGLC for >>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel >>>>>>>>> reporting >>>>>>>>> >>>>>>>>> Ahh. I think I see where the request and my understanding >>>>>>>>> divurge. If the idea here is that the master must provide, in >>>>>>>>> the request, an indication of what channels it expects to use, >>>>>>>>> I can at least understand that. I will return to technical >>>>>>>>> concerns in a moment. >>>>>>>>> >>>>>>>>> However, when you say "provide channel usage information, in >>>>>>>>> order to evaluate interference", what that says to me is >>>>>>>>> providing, during operation, information as to what channels >>>>>>>>> are being used, and at what power levels. That is what would >>>>>>>>> be needed to analyze actual interference effects. And that is >>>>>>>>> out of scope as I understand our scope. >>>>>>>>> >>>>>>>>> I do see a technical difficulty with having the master provide, >>>>>>>>> as part of either registering or requesting spectrum >>>>>>>>> information, what channels it intends to use. It doesn;t know >>>>>>>>> what channels it intends to use. It intends to use some number >>>>>>>>> of available channels. It will figure out which ones when it >>>>>>>>> is told what is available. How can it send that information in >>>>>>>>> the request? >>>>>>>>> >>>>>>>>> Yours, Joel >>>>>>>>> >>>>>>>>> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> There is a similarity here with device ID. In context of PAWS >>>>>>>>>> we are not concerned with why a device ID is required by a >>>>>>>>>> regulator, we accept it is a requirement from a regulator and >>>>>>>>>> include it to the protocol. Ofcom identifies in 3.18& 3.19 >>>>>>>>>> that channel usage information is required and thus we need >>>>>>>>>> to include this information. Since the master must provide >>>>>>>>>> this information prior to transmitting, PAWS will not >>>>>>>>>> function in the UK without this information and thus I >>>>>>>>>> believe channel usage information is integral to the channel >>>>>>>>>> request& response messaging. >>>>>>>>>> >>>>>>>>>> Kind Regards, Scott >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 3/6/12 10:30 AM, "ext Joel M. >>>>>>>>>> Halpern" wrote: >>>>>>>>>> >>>>>>>>>>> I would draw a distinction. Ofcom regulations about >>>>>>>>>>> whitespace requests are very much relevant. Ofcom >>>>>>>>>>> regulations about notification of dynamic behavior (which >>>>>>>>>>> spectrum is being used) are not in scope as I understand >>>>>>>>>>> the earlier discussions, particularly the chartering >>>>>>>>>>> discussions. >>>>>>>>>>> >>>>>>>>>>> Yours, Joel >>>>>>>>>>> >>>>>>>>>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: >>>>>>>>>>>> >>>>>>>>>>>> The ofcom requirements are very much relevant to the >>>>>>>>>>>> scope of the PAWS WG. The only other regulatory >>>>>>>>>>>> requirements that we have today is the FCC. Ofcom >>>>>>>>>>>> requirements are a good addition to the set. >>>>>>>>>>>> >>>>>>>>>>>> -Raj >>>>>>>>>>>> >>>>>>>>>>>> On 3/6/12 10:03 AM, "ext >>>>>>>>>>>> andy.sago@bt.com" wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Joel >>>>>>>>>>>>> >>>>>>>>>>>>> There's no language I can find in the charter that >>>>>>>>>>>>> explicitly puts this out of scope. On the other hand, >>>>>>>>>>>>> the charter says that the group will "consider input >>>>>>>>>>>>> from regulatory entities", and this is one of the >>>>>>>>>>>>> requirements from Ofcom that they have just published. >>>>>>>>>>>>> The protocol will be worthless for the UK if it omits >>>>>>>>>>>>> some requirements. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards >>>>>>>>>>>>> >>>>>>>>>>>>> Andy >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- From: Joel M. Halpern >>>>>>>>>>>>> [mailto:jmh@joelhalpern.com] Sent: 06 March 2012 15:53 >>>>>>>>>>>>> To: Sago,AJ,Andy,COD R Cc: paws@ietf.org; >>>>>>>>>>>>> Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for >>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel >>>>>>>>>>>>> reporting >>>>>>>>>>>>> >>>>>>>>>>>>> As I understand, the information you are asking for is >>>>>>>>>>>>> explicitly out of scope for the working group. Yours, >>>>>>>>>>>>> Joel >>>>>>>>>>>>> >>>>>>>>>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >>>>>>>>>>>>>> All >>>>>>>>>>>>>> >>>>>>>>>>>>>> Comparing the draft with the Ofcom requirements at >>>>>>>>>>>>>> http://www.cept.org/Documents/se- >>>>> 43/4161/SE43(12)Info03_Draft-UK-r >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>> egul >>>>>>>>>>>>>> atory-requirements-for-white-space-devices-in-the-UHF-TV- >>>>> band, >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>> I believe the WG draft is deficient in the area of reporting >>>>>>>>>>>>>> frequencies and powers actually used by masters and >>>>>>>>>>>>>> slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom >>>>>>>>>>>>>> intends to collect this data to assesses the impact >>>>>>>>>>>>>> of aggregate interference into other services. It >>>>>>>>>>>>>> would also provide usage information (frequency in >>>>>>>>>>>>>> use) that would inform the operation of a kill switch >>>>>>>>>>>>>> capability. I suggest this deficiency can be remedied >>>>>>>>>>>>>> with the following changes: >>>>>>>>>>>>>> >>>>>>>>>>>>>> New P requirements (probably best placed following >>>>>>>>>>>>>> P.12): >>>>>>>>>>>>>> >>>>>>>>>>>>>> P.12bis: The protocol MUST support a channel usage >>>>>>>>>>>>>> message from the slave device to the master device. >>>>>>>>>>>>>> The channel usage message MUST include parameters as >>>>>>>>>>>>>> required by local regulatory requirement. These >>>>>>>>>>>>>> parameters MAY include device ID, manufacturer's >>>>>>>>>>>>>> serial number, channel usage and power level >>>>>>>>>>>>>> information. >>>>>>>>>>>>>> >>>>>>>>>>>>>> P.12ter: The protocol MUST support a channel usage >>>>>>>>>>>>>> message from the master device to the database. The >>>>>>>>>>>>>> channel usage message MUST include parameters as >>>>>>>>>>>>>> required by local regulatory requirement for the >>>>>>>>>>>>>> master and its associated slaves. These parameters >>>>>>>>>>>>>> MAY include device ID, manufacturer's serial number, >>>>>>>>>>>>>> channel usage and power level information. >>>>>>>>>>>>>> >>>>>>>>>>>>>> P.12qua: The protocol MUST support a channel usage >>>>>>>>>>>>>> message acknowledgement. >>>>>>>>>>>>>> >>>>>>>>>>>>>> New O requirements (probably best placed following >>>>>>>>>>>>>> O13): >>>>>>>>>>>>>> >>>>>>>>>>>>>> O.13bis: According to local regulatory policy, after >>>>>>>>>>>>>> connecting to a master device's radio network a slave >>>>>>>>>>>>>> device MAY inform the master device of the actual >>>>>>>>>>>>>> channel usage. The slave MUST include parameters >>>>>>>>>>>>>> required by local regulatory policy, e.g. device ID, >>>>>>>>>>>>>> manufacturer's serial number, channel usage and power >>>>>>>>>>>>>> level information. >>>>>>>>>>>>>> >>>>>>>>>>>>>> O.13ter: According to local regulatory policy, a >>>>>>>>>>>>>> master device MAY inform the database of the actual >>>>>>>>>>>>>> channel usage of the master and its slaves. The >>>>>>>>>>>>>> master MUST include parameters required by local >>>>>>>>>>>>>> regulatory policy, e.g. device ID, manufacturer's >>>>>>>>>>>>>> serial number, channel usage and power level >>>>>>>>>>>>>> information of the master and its slaves. >>>>>>>>>>>>>> >>>>>>>>>>>>>> New steps could be introduced into one or more use >>>>>>>>>>>>>> cases to cover these Ofcom requirements, e.g. new >>>>>>>>>>>>>> steps 6bis and 9bis in the hotspot use case at >>>>>>>>>>>>>> 4.2.1: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 6bis. Prior to initiating transmission, if required >>>>>>>>>>>>>> by local regulation, the master/AP informs the >>>>>>>>>>>>>> database of the channel and power level it has >>>>>>>>>>>>>> chosen. This is repeated for each slave that >>>>>>>>>>>>>> associated with the master. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 9bis. Prior to initiating transmission, if required >>>>>>>>>>>>>> by local regulation, the slave informs the master/AP >>>>>>>>>>>>>> of the channel and power level it has chosen, and the >>>>>>>>>>>>>> master/AP relays this information to the database. >>>>>>>>>>>>>> >>>>>>>>>>>>>> - end of new text - >>>>>>>>>>>>>> >>>>>>>>>>>>>> For information, for those not accessing the url in >>>>>>>>>>>>>> the first paragraph of this email, the full Ofcom >>>>>>>>>>>>>> requirements leading to this new PAWS text are as >>>>>>>>>>>>>> follows: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 3.18 After receiving instructions from a WSDB in >>>>>>>>>>>>>> relation to the maximum permitted EIRPs over the DTT >>>>>>>>>>>>>> channels, and prior to initiating transmissions >>>>>>>>>>>>>> within the UHF TV band, a master WSD must communicate >>>>>>>>>>>>>> to the WSDB the following information: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 3.18.1 The lower and upper frequency boundaries^13 of >>>>>>>>>>>>>> the in-block emissions of the master WSD, and those >>>>>>>>>>>>>> of the in-block emissions of its associated slaves. A >>>>>>>>>>>>>> lower frequency will be specified as (470 + 8k + >>>>>>>>>>>>>> 0.2n) MHz, with the corresponding upper frequency >>>>>>>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3®4 k 3®4 >>>>>>>>>>>>>> 39, 0 3®4 n 3®4 39, 1 3®4 m 3®4 40, and n< m. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 3.18.2 The maximum in-block EIRP spectral densities >>>>>>>>>>>>>> (in dBm/(0.2 MHz)) that the master WSD, and its >>>>>>>>>>>>>> associated slaves, actually radiate between each >>>>>>>>>>>>>> reported lower frequency boundary and its >>>>>>>>>>>>>> corresponding upper frequency boundary. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Footnote 13 states: >>>>>>>>>>>>>> >>>>>>>>>>>>>> The use of upper and lower frequency boundaries >>>>>>>>>>>>>> (defined over a 200 kHz raster) allows a WSDB to >>>>>>>>>>>>>> collect more granular information with regards to the >>>>>>>>>>>>>> usage of the frequency resource by narrowband WSD >>>>>>>>>>>>>> technologies. The upper and lower frequencies of a >>>>>>>>>>>>>> boundary pair do not straddle a DTT channel boundary. >>>>>>>>>>>>>> Note that a WSD may transmit over multiple, >>>>>>>>>>>>>> non-contiguous, whole DTT channels or fractions of >>>>>>>>>>>>>> DTT channels. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 3.19 A master WSD must be able to receive the >>>>>>>>>>>>>> following information^14 from a WSDB: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in the >>>>>>>>>>>>>> context of 3.18, that the reported information on the >>>>>>>>>>>>>> DTT channels and EIRP spectral densities actually >>>>>>>>>>>>>> used by the master and slave WSDs were received >>>>>>>>>>>>>> successfully by the WSDB^18 ]. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Footnote 14 states: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 14 While the communication of some of this >>>>>>>>>>>>>> information from a WSDB to a master WSD is optional, >>>>>>>>>>>>>> master WSDs must be able to receive and interpret >>>>>>>>>>>>>> these. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Footnote 18 states: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 18 This forms part of a handshake protocol and may be >>>>>>>>>>>>>> an area where industry could harmonise without the >>>>>>>>>>>>>> need for an explicit requirement in the regulations. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards >>>>>>>>>>>>>> >>>>>>>>>>>>>> Andy >>>>>>>>>>>>>> >>>>>>>>>>>>>> *From:*paws-bounces@ietf.org >>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] *On Behalf Of >>>>>>>>>>>>>> *Gabor.Bajko@nokia.com *Sent:* 05 March 2012 19:46 >>>>>>>>>>>>>> *To:* paws@ietf.org *Subject:* [paws] WGLC for >>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >>>>>>>>>>>>>> >>>>>>>>>>>>>> The authors of the use cases and requirements draft >>>>>>>>>>>>>> have just posted a new version of the draft and >>>>>>>>>>>>>> indicated that there are no unresolved >>>>>>>>>>>>>> comments/issues they are aware of. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Therefore, I'd like to initiate a WG Last Call for >>>>>>>>>>>>>> comments on >>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-paws-problem- >>>>> stmt-u >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>> seca >>>>>>>>>>>>>> ses-rqmts-03.txt >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review the draft and send your comments to the >>>>>>>>>>>>>> list by March 20th, 2012. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If you review the draft and have no comments, send a >>>>>>>>>>>>>> note to the list that the draft is good as it is, we >>>>>>>>>>>>>> need these notes as much as we need the actual >>>>>>>>>>>>>> comments. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, Gabor >>>>>>>>>>>>>> >>>>>>>>>>>>>> > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > From scott.probasco@nokia.com Thu Mar 8 10:25:45 2012 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 D4A1D21F8679 for ; Thu, 8 Mar 2012 10:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.526 X-Spam-Level: X-Spam-Status: No, score=-3.526 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4, 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 89rSo5bbmn4o for ; Thu, 8 Mar 2012 10:25:44 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id BC49721F8649 for ; Thu, 8 Mar 2012 10:25:43 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q28IPWf2029115; Thu, 8 Mar 2012 20:25:39 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 20:25:34 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.129]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0355.003; Thu, 8 Mar 2012 19:25:33 +0100 From: To: Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting Thread-Index: AQHM/U9pVDIWW94XR02640QOS6jbCJZgmVoA//+kAoCAAGZ8gP//neCA Date: Thu, 8 Mar 2012 18:25:33 +0000 Message-ID: In-Reply-To: <4F58F78B.3030501@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.243.0.216] Content-Type: text/plain; charset="iso-8859-2" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Mar 2012 18:25:34.0660 (UTC) FILETIME=[DA329840:01CCFD58] X-Nokia-AV: Clean Cc: paws@ietf.org, presnick@qualcomm.com, johnny.dixon@bt.com, chris.cheeseman@bt.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 18:25:45 -0000 Hi Joel, A device could give that answer. But I expect the local regulator would not allow this, perhaps proactively by refusing local certification of the device or perhaps retroactively by disabling the device type(s) that try to claim all available spectrum. Both the described action and response are speculation. Kind Regards, Scott On 3/8/12 12:16 PM, "ext Joel M. Halpern" wrote: >So why won't the device simply say "I will use all of this?" >After all, that way it needs to do less work with the database. And it >can change frequencies when it wants. >Given that the stated goal of the Ofcom requriement was to be able to >analyze interference effects, it seems that this will not actually lead >to them getting what they want, even if it does comply with the >regulations. > >Yours, >joel > >On 3/8/2012 1:09 PM, scott.probasco@nokia.com wrote: >> Hi Peter, >> >> Answers below. >> >> Kind Regards, >> Scott >> >> On 3/8/12 11:39 AM, "ext Peter Saint-Andre" wrote: >> >>> Hi Scott, I have two clarifying questions: >>> >>> 1. Does the device know, when it receives the channel response, which >>> channel it will actually use? >> Scott->This is all new and I am not aware of any existing >>implementations. >> I would argue that the device must decide what channel(s) it will use >>when >> it receives the channel response. >>> >>> 2. If the device then uses another channel or a different channel, does >>> it need to report that change to the database? >> Scott->My interpretation of section 3.18 is that the device can only >> transmit within the upper& lower frequencies returned in the >> acknowledgment. I do not (quickly) find any reference in the >>requirements >> to changing channels. Thus operationally it could be that the channel >> request process must be repeated before the device can use a different >> channel (frequencies). >>> >>> Thanks! >>> >>> Peter >>> >>> On 3/8/12 10:17 AM, scott.probasco@nokia.com wrote: >>>> Hi, >>>> >>>> The point from Brian is very relevant: >>>> >>>> Channel request >>>> Channel response >>>> Channel acknowledgement >>>> >>>> What Ofcom does with the information in the acknowledgement does not >>>> matter. As the regulator in UK, they write rules that must be followed >>>> in >>>> order to operate a whitespace radio in the UK. I believe the scope of >>>> the >>>> WG must be focused on a working solution. If this is simple channel >>>> request& response in one regulator's domain, PAWS can support this. >>>>If >>>> it >>>> means a channel request, response and acknowledgement in another >>>> regulator's domain, PAWS can support this. As a participating member >>>>of >>>> the work group, I believe the scope should be basic working solution, >>>> not >>>> limited to a specific number of messages. >>>> >>>> Kind Regards, >>>> Scott >>>> >>>> >>>> >>>> On 3/8/12 11:11 AM, "ext Zuniga, Juan Carlos" >>>> wrote: >>>> >>>>> Peter, Nancy, >>>>> >>>>> I agree should design a protocol with the best of our current >>>>> knowledge, >>>>> and that should be accounting for all the known regulations at >>>>>present >>>>> time. We should not limit the scope with the purpose of designing a >>>>> protocol 'faster'. Our goal is not only to design a WSDB protocol. >>>>>Our >>>>> goal is to design a WSDB protocol that is USEFUL to the community. >>>>> >>>>> The charter does state that >>>>> >>>>> "...the group should also reach out to other potential >>>>> "customers" for a white space database access method and consider >>>>>input >>>> >from regulatory entities that are involved in the specification of >>>>the >>>>> rules for secondary use of spectrum in specific radio bands. " >>>>> >>>>> I think that is exactly what we are doing now. >>>>> >>>>> Regarding whether the types of requirements belong to #1 or #2, I >>>>> believe >>>>> it is more of #1 type, as the information to be exchanged would be >>>>> known >>>>> after the initial query/response. >>>>> >>>>> If we know it today, I see no reason why we should not work on it in >>>>> the >>>>> first phase of the work. >>>>> >>>>> Regards, >>>>> >>>>> Juan Carlos >>>>> >>>>>> -----Original Message----- >>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >>>>>> Of >>>>>> Peter Saint-Andre >>>>>> Sent: Thursday, March 08, 2012 11:59 AM >>>>>> To: Nancy Bravin >>>>>> Cc: paws@ietf.org; johnny.dixon@bt.com; chris.cheeseman@bt.com; Pete >>>>>> Resnick >>>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >>>>>> rqmts-03: channel reporting >>>>>> >>>>>> Hi Nancy, >>>>>> >>>>>> You are absolutely right that different locales will have different >>>>>> rules and requirements. We need to understand those, and work to >>>>>> address >>>>>> them if possible (although we don't necessarily need to address them >>>>>> all >>>>>> at the same time). I see several kinds of requirements: >>>>>> >>>>>> 1. Some requirements might lead to features beyond the >>>>>>query/response >>>>>> protocol we've envisioned so far. One example might be real-time >>>>>> reporting about the channels that a device is actually using. In my >>>>>> opinion, it would be best to handle those in the next phase of work, >>>>>> because as far as I can see they are outside the scope of our >>>>>>charter. >>>>>> >>>>>> 2. Some requirements might be handled through by defining additional >>>>>> fields that can be included in the query or response. We definitely >>>>>> planned for that when working on the charter with the IESG: >>>>>> >>>>>> In addition, the particular >>>>>> data exchanged between a device and a database might depend on >>>>>>the >>>>>> ranges of radio spectrum that are to be used, the requirements of >>>>>> the >>>>>> database operators and their governing regulations, and other >>>>>> factors. >>>>>> Therefore, the database access method and the query/response data >>>>>> formats that are exchanged using that method need to be designed >>>>>>for >>>>>> extensibility rather than being tied to any specific spectrum, >>>>>> country, or phy/mac/air interface. >>>>>> >>>>>> It's unclear to me right now if the Ofcom requirement fits into #1 >>>>>>or >>>>>> #2, which is why we're having this discussion. :) >>>>>> >>>>>> Peter >>>>>> >>>>>> On 3/7/12 8:17 PM, Nancy Bravin wrote: >>>>>>> Peter and all, >>>>>>> >>>>>>> I agree that it is important to revisit now, so that in the future, >>>>>>> it will be easy to align things in their proper place. Every >>>>>>>country >>>>>>> may have different regulations, spectrum, policy and what >>>>>>> responsibility is in the domain of the system, and what comes under >>>>>>> the PAWS charter is important. Maybe some separation might be >>>>>>> possible, and dividing and clarifying issues now will help in the >>>>>>> future. Certainly it seems that the FCC may change some rules, and >>>>>>> we know that Ofcom is not yet finished with their regulations. >>>>>>>Canada >>>>>>> has their own, and other countries are working on this as well. >>>>>>>Just >>>>>>> a thought...Sharing is a realistic goal...as is off loading... Or >>>>>>>you >>>>>>> slim line and every 6 months decide what to incorporate in the >>>>>>> protocol based on new information, new ideas, new innovation new >>>>>>> regulations and maybe spend more time than you could if addressed >>>>>>> now. >>>>>>> >>>>>>> That way you leave the door open and outside of referencing what is >>>>>>> known today, by referencing regulations i.e. Ofcom, FCC, Industry >>>>>>> Canada etc as of XX-XX-XXXX date. Out of scope not something we >>>>>>>know >>>>>>> enough about to say at this point, In my opinion. >>>>>>> >>>>>>> My 2 cents.. >>>>>>> >>>>>>> Sincerely, Nancy >>>>>>> >>>>>>> On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> As your responsible Area Director (until March 28, when Pete >>>>>>>> Resnick will take over from me), I have reviewed this thread. >>>>>>>> >>>>>>>> In my opinion (I am happy to be proven wrong), this new >>>>>>>>requirement >>>>>>>> goes beyond what the charter defined as the scope of this working >>>>>>>> group, which was to enable a device to discover the white space >>>>>>>> available to it in its current location. Reporting usage back to >>>>>>>> the database is simply not mentioned in the charter. >>>>>>>> >>>>>>>> Earlier in this thread, Andy Sago wrote: >>>>>>>> >>>>>>>> There's no language I can find in the charter that explicitly puts >>>>>>>> this out of scope. >>>>>>>> >>>>>>>> An IETF charter defines what the working group shall work on. Many >>>>>>>> interesting features could be developed here. However, it is not >>>>>>>> the job of the charter to mention explicitly that each of those >>>>>>>> interesting features is out of scope. >>>>>>>> >>>>>>>> The charter does say: >>>>>>>> >>>>>>>> Once the device learns of the available white space (e.g., in a TV >>>>>>>> white space implementation, the list of available channels at that >>>>>>>> location), it can then select one of the bands from the list and >>>>>>>> begin to transmit and receive on the selected band. >>>>>>>> >>>>>>>> This text might have assumed that no further communication or >>>>>>>> authorization was required in order to select one of the bands >>>>>>>>from >>>>>>>> the list and then transmit/receive. Perhaps that assumption was >>>>>>>> mistaken. If so, it would be good to have a discussion about that, >>>>>>>> so we can determine if we need to revisit the assumptions we made >>>>>>>> early on. If in fact we made some faulty or limited assumptions, >>>>>>>> then let's get that out in the open. >>>>>>>> >>>>>>>> Peter >>>>>>>> >>>>>>>> On 3/7/12 9:40 AM, Rosen, Brian wrote: >>>>>>>>> I'd also suggest that our >>>>>>>>> charter limitation is really support for sharing of whitespace by >>>>>>>>> whitespace devices. Reporting what you use is not sharing, it's >>>>>>>>> just data gathering. >>>>>>>>> >>>>>>>>> The point of excluding sharing was to eliminate the complexities >>>>>>>>> of what constituted fairness, and what kinds of communication >>>>>>>>> might be needed between databases, where more than one could >>>>>>>>> supply available whitespace in a band. This doesn't have any of >>>>>>>>> those issues, As long as it's just sending information, I don't >>>>>>>>> have a problem. Once the database is supposed to do anything >>>>>>>>> with it that involves changing what spectrum it reports, then I >>>>>>>>> think we cross the line. >>>>>>>>> >>>>>>>>> Brian >>>>>>>>> >>>>>>>>> On Mar 6, 2012, at 12:28 PM, >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Joel >>>>>>>>>> >>>>>>>>>> Indeed, the regulator has not described the process or provided >>>>>>>>>> a flow diagram, so there may be some wrinkles, but we need to >>>>>>>>>> provide for their intent. To answer your question, the channels >>>>>>>>>> that the master will use are sent in a separate message >>>>>>>>>> (described in P.12 ter), that occurs after the master receives >>>>>>>>>> the response to its channel request, but before the master can >>>>>>>>>> transmit. At this point, it knows what channels are available, >>>>>>>>>> and which one it will use. As far as the slaves are concerned, >>>>>>>>>> as they associate, the master will need to gather their details >>>>>>>>>> and send further channel usage messages to the database on >>>>>>>>>> their behalf. >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> >>>>>>>>>> Andy >>>>>>>>>> >>>>>>>>>> -----Original Message----- From: paws-bounces@ietf.org >>>>>>>>>> [mailto:paws-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>>>>>>>> Sent: 06 March 2012 17:05 To: scott.probasco@nokia.com Cc: >>>>>>>>>> paws@ietf.org; Cheeseman,CJ,Chris,COD R; Dixon,JS,Johnny,COD R >>>>>>>>>> Subject: Re: [paws] WGLC for >>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel >>>>>>>>>> reporting >>>>>>>>>> >>>>>>>>>> Ahh. I think I see where the request and my understanding >>>>>>>>>> divurge. If the idea here is that the master must provide, in >>>>>>>>>> the request, an indication of what channels it expects to use, >>>>>>>>>> I can at least understand that. I will return to technical >>>>>>>>>> concerns in a moment. >>>>>>>>>> >>>>>>>>>> However, when you say "provide channel usage information, in >>>>>>>>>> order to evaluate interference", what that says to me is >>>>>>>>>> providing, during operation, information as to what channels >>>>>>>>>> are being used, and at what power levels. That is what would >>>>>>>>>> be needed to analyze actual interference effects. And that is >>>>>>>>>> out of scope as I understand our scope. >>>>>>>>>> >>>>>>>>>> I do see a technical difficulty with having the master provide, >>>>>>>>>> as part of either registering or requesting spectrum >>>>>>>>>> information, what channels it intends to use. It doesn;t know >>>>>>>>>> what channels it intends to use. It intends to use some number >>>>>>>>>> of available channels. It will figure out which ones when it >>>>>>>>>> is told what is available. How can it send that information in >>>>>>>>>> the request? >>>>>>>>>> >>>>>>>>>> Yours, Joel >>>>>>>>>> >>>>>>>>>> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> There is a similarity here with device ID. In context of PAWS >>>>>>>>>>> we are not concerned with why a device ID is required by a >>>>>>>>>>> regulator, we accept it is a requirement from a regulator and >>>>>>>>>>> include it to the protocol. Ofcom identifies in 3.18& 3.19 >>>>>>>>>>> that channel usage information is required and thus we need >>>>>>>>>>> to include this information. Since the master must provide >>>>>>>>>>> this information prior to transmitting, PAWS will not >>>>>>>>>>> function in the UK without this information and thus I >>>>>>>>>>> believe channel usage information is integral to the channel >>>>>>>>>>> request& response messaging. >>>>>>>>>>> >>>>>>>>>>> Kind Regards, Scott >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 3/6/12 10:30 AM, "ext Joel M. >>>>>>>>>>> Halpern" wrote: >>>>>>>>>>> >>>>>>>>>>>> I would draw a distinction. Ofcom regulations about >>>>>>>>>>>> whitespace requests are very much relevant. Ofcom >>>>>>>>>>>> regulations about notification of dynamic behavior (which >>>>>>>>>>>> spectrum is being used) are not in scope as I understand >>>>>>>>>>>> the earlier discussions, particularly the chartering >>>>>>>>>>>> discussions. >>>>>>>>>>>> >>>>>>>>>>>> Yours, Joel >>>>>>>>>>>> >>>>>>>>>>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> The ofcom requirements are very much relevant to the >>>>>>>>>>>>> scope of the PAWS WG. The only other regulatory >>>>>>>>>>>>> requirements that we have today is the FCC. Ofcom >>>>>>>>>>>>> requirements are a good addition to the set. >>>>>>>>>>>>> >>>>>>>>>>>>> -Raj >>>>>>>>>>>>> >>>>>>>>>>>>> On 3/6/12 10:03 AM, "ext >>>>>>>>>>>>> andy.sago@bt.com" wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Joel >>>>>>>>>>>>>> >>>>>>>>>>>>>> There's no language I can find in the charter that >>>>>>>>>>>>>> explicitly puts this out of scope. On the other hand, >>>>>>>>>>>>>> the charter says that the group will "consider input >>>>>>>>>>>>>> from regulatory entities", and this is one of the >>>>>>>>>>>>>> requirements from Ofcom that they have just published. >>>>>>>>>>>>>> The protocol will be worthless for the UK if it omits >>>>>>>>>>>>>> some requirements. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards >>>>>>>>>>>>>> >>>>>>>>>>>>>> Andy >>>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- From: Joel M. Halpern >>>>>>>>>>>>>> [mailto:jmh@joelhalpern.com] Sent: 06 March 2012 15:53 >>>>>>>>>>>>>> To: Sago,AJ,Andy,COD R Cc: paws@ietf.org; >>>>>>>>>>>>>> Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for >>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel >>>>>>>>>>>>>> reporting >>>>>>>>>>>>>> >>>>>>>>>>>>>> As I understand, the information you are asking for is >>>>>>>>>>>>>> explicitly out of scope for the working group. Yours, >>>>>>>>>>>>>> Joel >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >>>>>>>>>>>>>>> All >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Comparing the draft with the Ofcom requirements at >>>>>>>>>>>>>>> http://www.cept.org/Documents/se- >>>>>> 43/4161/SE43(12)Info03_Draft-UK-r >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>> egul >>>>>>>>>>>>>>> atory-requirements-for-white-space-devices-in-the-UHF-TV- >>>>>> band, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>> I believe the WG draft is deficient in the area of reporting >>>>>>>>>>>>>>> frequencies and powers actually used by masters and >>>>>>>>>>>>>>> slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom >>>>>>>>>>>>>>> intends to collect this data to assesses the impact >>>>>>>>>>>>>>> of aggregate interference into other services. It >>>>>>>>>>>>>>> would also provide usage information (frequency in >>>>>>>>>>>>>>> use) that would inform the operation of a kill switch >>>>>>>>>>>>>>> capability. I suggest this deficiency can be remedied >>>>>>>>>>>>>>> with the following changes: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> New P requirements (probably best placed following >>>>>>>>>>>>>>> P.12): >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> P.12bis: The protocol MUST support a channel usage >>>>>>>>>>>>>>> message from the slave device to the master device. >>>>>>>>>>>>>>> The channel usage message MUST include parameters as >>>>>>>>>>>>>>> required by local regulatory requirement. These >>>>>>>>>>>>>>> parameters MAY include device ID, manufacturer's >>>>>>>>>>>>>>> serial number, channel usage and power level >>>>>>>>>>>>>>> information. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> P.12ter: The protocol MUST support a channel usage >>>>>>>>>>>>>>> message from the master device to the database. The >>>>>>>>>>>>>>> channel usage message MUST include parameters as >>>>>>>>>>>>>>> required by local regulatory requirement for the >>>>>>>>>>>>>>> master and its associated slaves. These parameters >>>>>>>>>>>>>>> MAY include device ID, manufacturer's serial number, >>>>>>>>>>>>>>> channel usage and power level information. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> P.12qua: The protocol MUST support a channel usage >>>>>>>>>>>>>>> message acknowledgement. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> New O requirements (probably best placed following >>>>>>>>>>>>>>> O13): >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> O.13bis: According to local regulatory policy, after >>>>>>>>>>>>>>> connecting to a master device's radio network a slave >>>>>>>>>>>>>>> device MAY inform the master device of the actual >>>>>>>>>>>>>>> channel usage. The slave MUST include parameters >>>>>>>>>>>>>>> required by local regulatory policy, e.g. device ID, >>>>>>>>>>>>>>> manufacturer's serial number, channel usage and power >>>>>>>>>>>>>>> level information. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> O.13ter: According to local regulatory policy, a >>>>>>>>>>>>>>> master device MAY inform the database of the actual >>>>>>>>>>>>>>> channel usage of the master and its slaves. The >>>>>>>>>>>>>>> master MUST include parameters required by local >>>>>>>>>>>>>>> regulatory policy, e.g. device ID, manufacturer's >>>>>>>>>>>>>>> serial number, channel usage and power level >>>>>>>>>>>>>>> information of the master and its slaves. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> New steps could be introduced into one or more use >>>>>>>>>>>>>>> cases to cover these Ofcom requirements, e.g. new >>>>>>>>>>>>>>> steps 6bis and 9bis in the hotspot use case at >>>>>>>>>>>>>>> 4.2.1: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 6bis. Prior to initiating transmission, if required >>>>>>>>>>>>>>> by local regulation, the master/AP informs the >>>>>>>>>>>>>>> database of the channel and power level it has >>>>>>>>>>>>>>> chosen. This is repeated for each slave that >>>>>>>>>>>>>>> associated with the master. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 9bis. Prior to initiating transmission, if required >>>>>>>>>>>>>>> by local regulation, the slave informs the master/AP >>>>>>>>>>>>>>> of the channel and power level it has chosen, and the >>>>>>>>>>>>>>> master/AP relays this information to the database. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - end of new text - >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> For information, for those not accessing the url in >>>>>>>>>>>>>>> the first paragraph of this email, the full Ofcom >>>>>>>>>>>>>>> requirements leading to this new PAWS text are as >>>>>>>>>>>>>>> follows: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 3.18 After receiving instructions from a WSDB in >>>>>>>>>>>>>>> relation to the maximum permitted EIRPs over the DTT >>>>>>>>>>>>>>> channels, and prior to initiating transmissions >>>>>>>>>>>>>>> within the UHF TV band, a master WSD must communicate >>>>>>>>>>>>>>> to the WSDB the following information: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 3.18.1 The lower and upper frequency boundaries^13 of >>>>>>>>>>>>>>> the in-block emissions of the master WSD, and those >>>>>>>>>>>>>>> of the in-block emissions of its associated slaves. A >>>>>>>>>>>>>>> lower frequency will be specified as (470 + 8k + >>>>>>>>>>>>>>> 0.2n) MHz, with the corresponding upper frequency >>>>>>>>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3=AE4 k 3=AE4 >>>>>>>>>>>>>>> 39, 0 3=AE4 n 3=AE4 39, 1 3=AE4 m 3=AE4 40, and n< m. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 3.18.2 The maximum in-block EIRP spectral densities >>>>>>>>>>>>>>> (in dBm/(0.2 MHz)) that the master WSD, and its >>>>>>>>>>>>>>> associated slaves, actually radiate between each >>>>>>>>>>>>>>> reported lower frequency boundary and its >>>>>>>>>>>>>>> corresponding upper frequency boundary. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Footnote 13 states: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The use of upper and lower frequency boundaries >>>>>>>>>>>>>>> (defined over a 200 kHz raster) allows a WSDB to >>>>>>>>>>>>>>> collect more granular information with regards to the >>>>>>>>>>>>>>> usage of the frequency resource by narrowband WSD >>>>>>>>>>>>>>> technologies. The upper and lower frequencies of a >>>>>>>>>>>>>>> boundary pair do not straddle a DTT channel boundary. >>>>>>>>>>>>>>> Note that a WSD may transmit over multiple, >>>>>>>>>>>>>>> non-contiguous, whole DTT channels or fractions of >>>>>>>>>>>>>>> DTT channels. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 3.19 A master WSD must be able to receive the >>>>>>>>>>>>>>> following information^14 from a WSDB: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in the >>>>>>>>>>>>>>> context of 3.18, that the reported information on the >>>>>>>>>>>>>>> DTT channels and EIRP spectral densities actually >>>>>>>>>>>>>>> used by the master and slave WSDs were received >>>>>>>>>>>>>>> successfully by the WSDB^18 ]. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Footnote 14 states: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 14 While the communication of some of this >>>>>>>>>>>>>>> information from a WSDB to a master WSD is optional, >>>>>>>>>>>>>>> master WSDs must be able to receive and interpret >>>>>>>>>>>>>>> these. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Footnote 18 states: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 18 This forms part of a handshake protocol and may be >>>>>>>>>>>>>>> an area where industry could harmonise without the >>>>>>>>>>>>>>> need for an explicit requirement in the regulations. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Andy >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *From:*paws-bounces@ietf.org >>>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] *On Behalf Of >>>>>>>>>>>>>>> *Gabor.Bajko@nokia.com *Sent:* 05 March 2012 19:46 >>>>>>>>>>>>>>> *To:* paws@ietf.org *Subject:* [paws] WGLC for >>>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The authors of the use cases and requirements draft >>>>>>>>>>>>>>> have just posted a new version of the draft and >>>>>>>>>>>>>>> indicated that there are no unresolved >>>>>>>>>>>>>>> comments/issues they are aware of. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Therefore, I'd like to initiate a WG Last Call for >>>>>>>>>>>>>>> comments on >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>http://www.ietf.org/internet-drafts/draft-ietf-paws-problem- >>>>>> stmt-u >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>> seca >>>>>>>>>>>>>>> ses-rqmts-03.txt >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please review the draft and send your comments to the >>>>>>>>>>>>>>> list by March 20th, 2012. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If you review the draft and have no comments, send a >>>>>>>>>>>>>>> note to the list that the draft is good as it is, we >>>>>>>>>>>>>>> need these notes as much as we need the actual >>>>>>>>>>>>>>> comments. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, Gabor >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> From budden@nps.edu Thu Mar 8 10:40:22 2012 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 3987821F8587 for ; Thu, 8 Mar 2012 10:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.182 X-Spam-Level: X-Spam-Status: No, score=-1.182 tagged_above=-999 required=5 tests=[AWL=-1.210, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, 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 OV5AXctfmmbA for ; Thu, 8 Mar 2012 10:40:20 -0800 (PST) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id 35A0421F857F for ; Thu, 8 Mar 2012 10:40:20 -0800 (PST) X-ASG-Debug-ID: 1331232017-036c92049456020001-Z0ZA9G Received: from gulfstream.ern.nps.edu (gulfstream.ern.nps.edu [172.20.24.113]) by mule.nps.edu with ESMTP id ZLu8JBfwERZnisLB; Thu, 08 Mar 2012 10:40:17 -0800 (PST) X-Barracuda-Envelope-From: budden@nps.edu Received: from [172.20.58.67] (172.20.58.67) by smtp.nps.edu (172.20.24.113) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 8 Mar 2012 10:40:17 -0800 From: Rex Buddenberg X-ASG-Orig-Subj: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting To: "Joel M. Halpern" In-Reply-To: <4F58F78B.3030501@joelhalpern.com> References: <4F58F78B.3030501@joelhalpern.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 8 Mar 2012 10:39:35 -0800 Message-ID: <1331231975.9169.3503.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 8bit X-Barracuda-Connect: gulfstream.ern.nps.edu[172.20.24.113] X-Barracuda-Start-Time: 1331232017 X-Barracuda-URL: http://205.155.65.106:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at nps.edu X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.90646 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: paws@ietf.org, presnick@qualcomm.com, johnny.dixon@bt.com, chris.cheeseman@bt.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 18:40:22 -0000 Joel, while this sounds on the surface like simply greedy, there's a scalability rationale too. Radio-WAN capacity is about four orders of magnitude less than terrestrial-WAN capacity. Worse, the diff is likely to widen as the limitations on terrestrial-WAN backbones are engineering while the radio-WAN is approaching physics limitations. What you may get is indeed: > device simply say "I will use all of this and the device indeed might use all -- in an inverse multiplex fashion. In keeping with the intent of PAWS we should not impose a value judgment -- the greed may be good or bad. (I'm not sure what the WG should be doing about this; simply an observation at this point). On Thu, 2012-03-08 at 13:16 -0500, Joel M. Halpern wrote: > So why won't the device simply say "I will use all of this?" > After all, that way it needs to do less work with the database. And it > can change frequencies when it wants. > Given that the stated goal of the Ofcom requriement was to be able to > analyze interference effects, it seems that this will not actually lead > to them getting what they want, even if it does comply with the regulations. > > Yours, > joel > > On 3/8/2012 1:09 PM, scott.probasco@nokia.com wrote: > > Hi Peter, > > > > Answers below. > > > > Kind Regards, > > Scott > > > > On 3/8/12 11:39 AM, "ext Peter Saint-Andre" wrote: > > > >> Hi Scott, I have two clarifying questions: > >> > >> 1. Does the device know, when it receives the channel response, which > >> channel it will actually use? > > Scott->This is all new and I am not aware of any existing implementations. > > I would argue that the device must decide what channel(s) it will use when > > it receives the channel response. > >> > >> 2. If the device then uses another channel or a different channel, does > >> it need to report that change to the database? > > Scott->My interpretation of section 3.18 is that the device can only > > transmit within the upper& lower frequencies returned in the > > acknowledgment. I do not (quickly) find any reference in the requirements > > to changing channels. Thus operationally it could be that the channel > > request process must be repeated before the device can use a different > > channel (frequencies). > >> > >> Thanks! > >> > >> Peter > >> > >> On 3/8/12 10:17 AM, scott.probasco@nokia.com wrote: > >>> Hi, > >>> > >>> The point from Brian is very relevant: > >>> > >>> Channel request > >>> Channel response > >>> Channel acknowledgement > >>> > >>> What Ofcom does with the information in the acknowledgement does not > >>> matter. As the regulator in UK, they write rules that must be followed > >>> in > >>> order to operate a whitespace radio in the UK. I believe the scope of > >>> the > >>> WG must be focused on a working solution. If this is simple channel > >>> request& response in one regulator's domain, PAWS can support this. If > >>> it > >>> means a channel request, response and acknowledgement in another > >>> regulator's domain, PAWS can support this. As a participating member of > >>> the work group, I believe the scope should be basic working solution, > >>> not > >>> limited to a specific number of messages. > >>> > >>> Kind Regards, > >>> Scott > >>> > >>> > >>> > >>> On 3/8/12 11:11 AM, "ext Zuniga, Juan Carlos" > >>> wrote: > >>> > >>>> Peter, Nancy, > >>>> > >>>> I agree should design a protocol with the best of our current > >>>> knowledge, > >>>> and that should be accounting for all the known regulations at present > >>>> time. We should not limit the scope with the purpose of designing a > >>>> protocol 'faster'. Our goal is not only to design a WSDB protocol. Our > >>>> goal is to design a WSDB protocol that is USEFUL to the community. > >>>> > >>>> The charter does state that > >>>> > >>>> "...the group should also reach out to other potential > >>>> "customers" for a white space database access method and consider input > >>> >from regulatory entities that are involved in the specification of the > >>>> rules for secondary use of spectrum in specific radio bands. " > >>>> > >>>> I think that is exactly what we are doing now. > >>>> > >>>> Regarding whether the types of requirements belong to #1 or #2, I > >>>> believe > >>>> it is more of #1 type, as the information to be exchanged would be > >>>> known > >>>> after the initial query/response. > >>>> > >>>> If we know it today, I see no reason why we should not work on it in > >>>> the > >>>> first phase of the work. > >>>> > >>>> Regards, > >>>> > >>>> Juan Carlos > >>>> > >>>>> -----Original Message----- > >>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf > >>>>> Of > >>>>> Peter Saint-Andre > >>>>> Sent: Thursday, March 08, 2012 11:59 AM > >>>>> To: Nancy Bravin > >>>>> Cc: paws@ietf.org; johnny.dixon@bt.com; chris.cheeseman@bt.com; Pete > >>>>> Resnick > >>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- > >>>>> rqmts-03: channel reporting > >>>>> > >>>>> Hi Nancy, > >>>>> > >>>>> You are absolutely right that different locales will have different > >>>>> rules and requirements. We need to understand those, and work to > >>>>> address > >>>>> them if possible (although we don't necessarily need to address them > >>>>> all > >>>>> at the same time). I see several kinds of requirements: > >>>>> > >>>>> 1. Some requirements might lead to features beyond the query/response > >>>>> protocol we've envisioned so far. One example might be real-time > >>>>> reporting about the channels that a device is actually using. In my > >>>>> opinion, it would be best to handle those in the next phase of work, > >>>>> because as far as I can see they are outside the scope of our charter. > >>>>> > >>>>> 2. Some requirements might be handled through by defining additional > >>>>> fields that can be included in the query or response. We definitely > >>>>> planned for that when working on the charter with the IESG: > >>>>> > >>>>> In addition, the particular > >>>>> data exchanged between a device and a database might depend on the > >>>>> ranges of radio spectrum that are to be used, the requirements of > >>>>> the > >>>>> database operators and their governing regulations, and other > >>>>> factors. > >>>>> Therefore, the database access method and the query/response data > >>>>> formats that are exchanged using that method need to be designed for > >>>>> extensibility rather than being tied to any specific spectrum, > >>>>> country, or phy/mac/air interface. > >>>>> > >>>>> It's unclear to me right now if the Ofcom requirement fits into #1 or > >>>>> #2, which is why we're having this discussion. :) > >>>>> > >>>>> Peter > >>>>> > >>>>> On 3/7/12 8:17 PM, Nancy Bravin wrote: > >>>>>> Peter and all, > >>>>>> > >>>>>> I agree that it is important to revisit now, so that in the future, > >>>>>> it will be easy to align things in their proper place. Every country > >>>>>> may have different regulations, spectrum, policy and what > >>>>>> responsibility is in the domain of the system, and what comes under > >>>>>> the PAWS charter is important. Maybe some separation might be > >>>>>> possible, and dividing and clarifying issues now will help in the > >>>>>> future. Certainly it seems that the FCC may change some rules, and > >>>>>> we know that Ofcom is not yet finished with their regulations. Canada > >>>>>> has their own, and other countries are working on this as well. Just > >>>>>> a thought...Sharing is a realistic goal...as is off loading... Or you > >>>>>> slim line and every 6 months decide what to incorporate in the > >>>>>> protocol based on new information, new ideas, new innovation new > >>>>>> regulations and maybe spend more time than you could if addressed > >>>>>> now. > >>>>>> > >>>>>> That way you leave the door open and outside of referencing what is > >>>>>> known today, by referencing regulations i.e. Ofcom, FCC, Industry > >>>>>> Canada etc as of XX-XX-XXXX date. Out of scope not something we know > >>>>>> enough about to say at this point, In my opinion. > >>>>>> > >>>>>> My 2 cents.. > >>>>>> > >>>>>> Sincerely, Nancy > >>>>>> > >>>>>> On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> As your responsible Area Director (until March 28, when Pete > >>>>>>> Resnick will take over from me), I have reviewed this thread. > >>>>>>> > >>>>>>> In my opinion (I am happy to be proven wrong), this new requirement > >>>>>>> goes beyond what the charter defined as the scope of this working > >>>>>>> group, which was to enable a device to discover the white space > >>>>>>> available to it in its current location. Reporting usage back to > >>>>>>> the database is simply not mentioned in the charter. > >>>>>>> > >>>>>>> Earlier in this thread, Andy Sago wrote: > >>>>>>> > >>>>>>> There's no language I can find in the charter that explicitly puts > >>>>>>> this out of scope. > >>>>>>> > >>>>>>> An IETF charter defines what the working group shall work on. Many > >>>>>>> interesting features could be developed here. However, it is not > >>>>>>> the job of the charter to mention explicitly that each of those > >>>>>>> interesting features is out of scope. > >>>>>>> > >>>>>>> The charter does say: > >>>>>>> > >>>>>>> Once the device learns of the available white space (e.g., in a TV > >>>>>>> white space implementation, the list of available channels at that > >>>>>>> location), it can then select one of the bands from the list and > >>>>>>> begin to transmit and receive on the selected band. > >>>>>>> > >>>>>>> This text might have assumed that no further communication or > >>>>>>> authorization was required in order to select one of the bands from > >>>>>>> the list and then transmit/receive. Perhaps that assumption was > >>>>>>> mistaken. If so, it would be good to have a discussion about that, > >>>>>>> so we can determine if we need to revisit the assumptions we made > >>>>>>> early on. If in fact we made some faulty or limited assumptions, > >>>>>>> then let's get that out in the open. > >>>>>>> > >>>>>>> Peter > >>>>>>> > >>>>>>> On 3/7/12 9:40 AM, Rosen, Brian wrote: > >>>>>>>> I'd also suggest that our > >>>>>>>> charter limitation is really support for sharing of whitespace by > >>>>>>>> whitespace devices. Reporting what you use is not sharing, it's > >>>>>>>> just data gathering. > >>>>>>>> > >>>>>>>> The point of excluding sharing was to eliminate the complexities > >>>>>>>> of what constituted fairness, and what kinds of communication > >>>>>>>> might be needed between databases, where more than one could > >>>>>>>> supply available whitespace in a band. This doesn't have any of > >>>>>>>> those issues, As long as it's just sending information, I don't > >>>>>>>> have a problem. Once the database is supposed to do anything > >>>>>>>> with it that involves changing what spectrum it reports, then I > >>>>>>>> think we cross the line. > >>>>>>>> > >>>>>>>> Brian > >>>>>>>> > >>>>>>>> On Mar 6, 2012, at 12:28 PM, > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> Joel > >>>>>>>>> > >>>>>>>>> Indeed, the regulator has not described the process or provided > >>>>>>>>> a flow diagram, so there may be some wrinkles, but we need to > >>>>>>>>> provide for their intent. To answer your question, the channels > >>>>>>>>> that the master will use are sent in a separate message > >>>>>>>>> (described in P.12 ter), that occurs after the master receives > >>>>>>>>> the response to its channel request, but before the master can > >>>>>>>>> transmit. At this point, it knows what channels are available, > >>>>>>>>> and which one it will use. As far as the slaves are concerned, > >>>>>>>>> as they associate, the master will need to gather their details > >>>>>>>>> and send further channel usage messages to the database on > >>>>>>>>> their behalf. > >>>>>>>>> > >>>>>>>>> Regards > >>>>>>>>> > >>>>>>>>> Andy > >>>>>>>>> > >>>>>>>>> -----Original Message----- From: paws-bounces@ietf.org > >>>>>>>>> [mailto:paws-bounces@ietf.org] On Behalf Of Joel M. Halpern > >>>>>>>>> Sent: 06 March 2012 17:05 To: scott.probasco@nokia.com Cc: > >>>>>>>>> paws@ietf.org; Cheeseman,CJ,Chris,COD R; Dixon,JS,Johnny,COD R > >>>>>>>>> Subject: Re: [paws] WGLC for > >>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel > >>>>>>>>> reporting > >>>>>>>>> > >>>>>>>>> Ahh. I think I see where the request and my understanding > >>>>>>>>> divurge. If the idea here is that the master must provide, in > >>>>>>>>> the request, an indication of what channels it expects to use, > >>>>>>>>> I can at least understand that. I will return to technical > >>>>>>>>> concerns in a moment. > >>>>>>>>> > >>>>>>>>> However, when you say "provide channel usage information, in > >>>>>>>>> order to evaluate interference", what that says to me is > >>>>>>>>> providing, during operation, information as to what channels > >>>>>>>>> are being used, and at what power levels. That is what would > >>>>>>>>> be needed to analyze actual interference effects. And that is > >>>>>>>>> out of scope as I understand our scope. > >>>>>>>>> > >>>>>>>>> I do see a technical difficulty with having the master provide, > >>>>>>>>> as part of either registering or requesting spectrum > >>>>>>>>> information, what channels it intends to use. It doesn;t know > >>>>>>>>> what channels it intends to use. It intends to use some number > >>>>>>>>> of available channels. It will figure out which ones when it > >>>>>>>>> is told what is available. How can it send that information in > >>>>>>>>> the request? > >>>>>>>>> > >>>>>>>>> Yours, Joel > >>>>>>>>> > >>>>>>>>> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: > >>>>>>>>>> Hi, > >>>>>>>>>> > >>>>>>>>>> There is a similarity here with device ID. In context of PAWS > >>>>>>>>>> we are not concerned with why a device ID is required by a > >>>>>>>>>> regulator, we accept it is a requirement from a regulator and > >>>>>>>>>> include it to the protocol. Ofcom identifies in 3.18& 3.19 > >>>>>>>>>> that channel usage information is required and thus we need > >>>>>>>>>> to include this information. Since the master must provide > >>>>>>>>>> this information prior to transmitting, PAWS will not > >>>>>>>>>> function in the UK without this information and thus I > >>>>>>>>>> believe channel usage information is integral to the channel > >>>>>>>>>> request& response messaging. > >>>>>>>>>> > >>>>>>>>>> Kind Regards, Scott > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On 3/6/12 10:30 AM, "ext Joel M. > >>>>>>>>>> Halpern" wrote: > >>>>>>>>>> > >>>>>>>>>>> I would draw a distinction. Ofcom regulations about > >>>>>>>>>>> whitespace requests are very much relevant. Ofcom > >>>>>>>>>>> regulations about notification of dynamic behavior (which > >>>>>>>>>>> spectrum is being used) are not in scope as I understand > >>>>>>>>>>> the earlier discussions, particularly the chartering > >>>>>>>>>>> discussions. > >>>>>>>>>>> > >>>>>>>>>>> Yours, Joel > >>>>>>>>>>> > >>>>>>>>>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> The ofcom requirements are very much relevant to the > >>>>>>>>>>>> scope of the PAWS WG. The only other regulatory > >>>>>>>>>>>> requirements that we have today is the FCC. Ofcom > >>>>>>>>>>>> requirements are a good addition to the set. > >>>>>>>>>>>> > >>>>>>>>>>>> -Raj > >>>>>>>>>>>> > >>>>>>>>>>>> On 3/6/12 10:03 AM, "ext > >>>>>>>>>>>> andy.sago@bt.com" wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> Hi Joel > >>>>>>>>>>>>> > >>>>>>>>>>>>> There's no language I can find in the charter that > >>>>>>>>>>>>> explicitly puts this out of scope. On the other hand, > >>>>>>>>>>>>> the charter says that the group will "consider input > >>>>>>>>>>>>> from regulatory entities", and this is one of the > >>>>>>>>>>>>> requirements from Ofcom that they have just published. > >>>>>>>>>>>>> The protocol will be worthless for the UK if it omits > >>>>>>>>>>>>> some requirements. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Regards > >>>>>>>>>>>>> > >>>>>>>>>>>>> Andy > >>>>>>>>>>>>> > >>>>>>>>>>>>> -----Original Message----- From: Joel M. Halpern > >>>>>>>>>>>>> [mailto:jmh@joelhalpern.com] Sent: 06 March 2012 15:53 > >>>>>>>>>>>>> To: Sago,AJ,Andy,COD R Cc: paws@ietf.org; > >>>>>>>>>>>>> Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for > >>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel > >>>>>>>>>>>>> reporting > >>>>>>>>>>>>> > >>>>>>>>>>>>> As I understand, the information you are asking for is > >>>>>>>>>>>>> explicitly out of scope for the working group. Yours, > >>>>>>>>>>>>> Joel > >>>>>>>>>>>>> > >>>>>>>>>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: > >>>>>>>>>>>>>> All > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Comparing the draft with the Ofcom requirements at > >>>>>>>>>>>>>> http://www.cept.org/Documents/se- > >>>>> 43/4161/SE43(12)Info03_Draft-UK-r > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>> egul > >>>>>>>>>>>>>> atory-requirements-for-white-space-devices-in-the-UHF-TV- > >>>>> band, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>> I believe the WG draft is deficient in the area of reporting > >>>>>>>>>>>>>> frequencies and powers actually used by masters and > >>>>>>>>>>>>>> slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom > >>>>>>>>>>>>>> intends to collect this data to assesses the impact > >>>>>>>>>>>>>> of aggregate interference into other services. It > >>>>>>>>>>>>>> would also provide usage information (frequency in > >>>>>>>>>>>>>> use) that would inform the operation of a kill switch > >>>>>>>>>>>>>> capability. I suggest this deficiency can be remedied > >>>>>>>>>>>>>> with the following changes: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> New P requirements (probably best placed following > >>>>>>>>>>>>>> P.12): > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> P.12bis: The protocol MUST support a channel usage > >>>>>>>>>>>>>> message from the slave device to the master device. > >>>>>>>>>>>>>> The channel usage message MUST include parameters as > >>>>>>>>>>>>>> required by local regulatory requirement. These > >>>>>>>>>>>>>> parameters MAY include device ID, manufacturer's > >>>>>>>>>>>>>> serial number, channel usage and power level > >>>>>>>>>>>>>> information. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> P.12ter: The protocol MUST support a channel usage > >>>>>>>>>>>>>> message from the master device to the database. The > >>>>>>>>>>>>>> channel usage message MUST include parameters as > >>>>>>>>>>>>>> required by local regulatory requirement for the > >>>>>>>>>>>>>> master and its associated slaves. These parameters > >>>>>>>>>>>>>> MAY include device ID, manufacturer's serial number, > >>>>>>>>>>>>>> channel usage and power level information. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> P.12qua: The protocol MUST support a channel usage > >>>>>>>>>>>>>> message acknowledgement. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> New O requirements (probably best placed following > >>>>>>>>>>>>>> O13): > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> O.13bis: According to local regulatory policy, after > >>>>>>>>>>>>>> connecting to a master device's radio network a slave > >>>>>>>>>>>>>> device MAY inform the master device of the actual > >>>>>>>>>>>>>> channel usage. The slave MUST include parameters > >>>>>>>>>>>>>> required by local regulatory policy, e.g. device ID, > >>>>>>>>>>>>>> manufacturer's serial number, channel usage and power > >>>>>>>>>>>>>> level information. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> O.13ter: According to local regulatory policy, a > >>>>>>>>>>>>>> master device MAY inform the database of the actual > >>>>>>>>>>>>>> channel usage of the master and its slaves. The > >>>>>>>>>>>>>> master MUST include parameters required by local > >>>>>>>>>>>>>> regulatory policy, e.g. device ID, manufacturer's > >>>>>>>>>>>>>> serial number, channel usage and power level > >>>>>>>>>>>>>> information of the master and its slaves. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> New steps could be introduced into one or more use > >>>>>>>>>>>>>> cases to cover these Ofcom requirements, e.g. new > >>>>>>>>>>>>>> steps 6bis and 9bis in the hotspot use case at > >>>>>>>>>>>>>> 4.2.1: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 6bis. Prior to initiating transmission, if required > >>>>>>>>>>>>>> by local regulation, the master/AP informs the > >>>>>>>>>>>>>> database of the channel and power level it has > >>>>>>>>>>>>>> chosen. This is repeated for each slave that > >>>>>>>>>>>>>> associated with the master. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 9bis. Prior to initiating transmission, if required > >>>>>>>>>>>>>> by local regulation, the slave informs the master/AP > >>>>>>>>>>>>>> of the channel and power level it has chosen, and the > >>>>>>>>>>>>>> master/AP relays this information to the database. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> - end of new text - > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> For information, for those not accessing the url in > >>>>>>>>>>>>>> the first paragraph of this email, the full Ofcom > >>>>>>>>>>>>>> requirements leading to this new PAWS text are as > >>>>>>>>>>>>>> follows: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 3.18 After receiving instructions from a WSDB in > >>>>>>>>>>>>>> relation to the maximum permitted EIRPs over the DTT > >>>>>>>>>>>>>> channels, and prior to initiating transmissions > >>>>>>>>>>>>>> within the UHF TV band, a master WSD must communicate > >>>>>>>>>>>>>> to the WSDB the following information: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 3.18.1 The lower and upper frequency boundaries^13 of > >>>>>>>>>>>>>> the in-block emissions of the master WSD, and those > >>>>>>>>>>>>>> of the in-block emissions of its associated slaves. A > >>>>>>>>>>>>>> lower frequency will be specified as (470 + 8k + > >>>>>>>>>>>>>> 0.2n) MHz, with the corresponding upper frequency > >>>>>>>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3Ž4 k 3Ž4 > >>>>>>>>>>>>>> 39, 0 3Ž4 n 3Ž4 39, 1 3Ž4 m 3Ž4 40, and n< m. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 3.18.2 The maximum in-block EIRP spectral densities > >>>>>>>>>>>>>> (in dBm/(0.2 MHz)) that the master WSD, and its > >>>>>>>>>>>>>> associated slaves, actually radiate between each > >>>>>>>>>>>>>> reported lower frequency boundary and its > >>>>>>>>>>>>>> corresponding upper frequency boundary. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Footnote 13 states: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> The use of upper and lower frequency boundaries > >>>>>>>>>>>>>> (defined over a 200 kHz raster) allows a WSDB to > >>>>>>>>>>>>>> collect more granular information with regards to the > >>>>>>>>>>>>>> usage of the frequency resource by narrowband WSD > >>>>>>>>>>>>>> technologies. The upper and lower frequencies of a > >>>>>>>>>>>>>> boundary pair do not straddle a DTT channel boundary. > >>>>>>>>>>>>>> Note that a WSD may transmit over multiple, > >>>>>>>>>>>>>> non-contiguous, whole DTT channels or fractions of > >>>>>>>>>>>>>> DTT channels. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 3.19 A master WSD must be able to receive the > >>>>>>>>>>>>>> following information^14 from a WSDB: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in the > >>>>>>>>>>>>>> context of 3.18, that the reported information on the > >>>>>>>>>>>>>> DTT channels and EIRP spectral densities actually > >>>>>>>>>>>>>> used by the master and slave WSDs were received > >>>>>>>>>>>>>> successfully by the WSDB^18 ]. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Footnote 14 states: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 14 While the communication of some of this > >>>>>>>>>>>>>> information from a WSDB to a master WSD is optional, > >>>>>>>>>>>>>> master WSDs must be able to receive and interpret > >>>>>>>>>>>>>> these. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Footnote 18 states: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 18 This forms part of a handshake protocol and may be > >>>>>>>>>>>>>> an area where industry could harmonise without the > >>>>>>>>>>>>>> need for an explicit requirement in the regulations. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Regards > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Andy > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> *From:*paws-bounces@ietf.org > >>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] *On Behalf Of > >>>>>>>>>>>>>> *Gabor.Bajko@nokia.com *Sent:* 05 March 2012 19:46 > >>>>>>>>>>>>>> *To:* paws@ietf.org *Subject:* [paws] WGLC for > >>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> The authors of the use cases and requirements draft > >>>>>>>>>>>>>> have just posted a new version of the draft and > >>>>>>>>>>>>>> indicated that there are no unresolved > >>>>>>>>>>>>>> comments/issues they are aware of. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Therefore, I'd like to initiate a WG Last Call for > >>>>>>>>>>>>>> comments on > >>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-paws-problem- > >>>>> stmt-u > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>> seca > >>>>>>>>>>>>>> ses-rqmts-03.txt > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Please review the draft and send your comments to the > >>>>>>>>>>>>>> list by March 20th, 2012. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> If you review the draft and have no comments, send a > >>>>>>>>>>>>>> note to the list that the draft is good as it is, we > >>>>>>>>>>>>>> need these notes as much as we need the actual > >>>>>>>>>>>>>> comments. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks, Gabor > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > > > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > https://www.ietf.org/mailman/listinfo/paws > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From gerald.chouinard@sympatico.ca Thu Mar 8 10:59:12 2012 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 4A09421F86C2 for ; Thu, 8 Mar 2012 10:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.834 X-Spam-Level: X-Spam-Status: No, score=0.834 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, MSGID_FROM_MTA_HEADER=0.803, 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 mz1jaiLdfEN7 for ; Thu, 8 Mar 2012 10:59:10 -0800 (PST) Received: from blu0-omc1-s6.blu0.hotmail.com (blu0-omc1-s6.blu0.hotmail.com [65.55.116.17]) by ietfa.amsl.com (Postfix) with ESMTP id B303421F86B4 for ; Thu, 8 Mar 2012 10:59:08 -0800 (PST) Received: from BLU0-SMTP70 ([65.55.116.9]) by blu0-omc1-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 10:59:08 -0800 X-Originating-IP: [174.95.243.14] X-Originating-Email: [gerald.chouinard@sympatico.ca] Message-ID: Received: from Gerald2 ([174.95.243.14]) by BLU0-SMTP70.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 10:59:07 -0800 From: Gerald Chouinard To: "'Joel M. Halpern'" , References: <4F58F78B.3030501@joelhalpern.com> Date: Thu, 8 Mar 2012 13:59:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4F58F78B.3030501@joelhalpern.com> Thread-Index: Acz9V7Iqh7bz3L85Sfm6YmPS/OxBfgAAXEPg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 08 Mar 2012 18:59:07.0454 (UTC) FILETIME=[89EA95E0:01CCFD5D] Cc: paws@ietf.org, presnick@qualcomm.com, johnny.dixon@bt.com, chris.cheeseman@bt.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 18:59:12 -0000 Joel, Scott, Interesting discussion! See my comments in line below. Gerald -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of = Joel M. Halpern Sent: Thursday, 08 March, 2012 13:17 To: scott.probasco@nokia.com Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; chris.cheeseman@bt.com Subject: Re: [paws] WGLC for = draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting So why won't the device simply say "I will use all of this?" [GC] This would defeat the purpose of the acknowledgement message. After all, that way it needs to do less work with the database. And it=20 can change frequencies when it wants. Given that the stated goal of the Ofcom requriement was to be able to=20 analyze interference effects, it seems that this will not actually lead=20 to them getting what they want, even if it does comply with the = regulations. [GC] You got it. This would be useless for spectrum regulators. One = should realize that, from the spectrum regulator's point of view, the second = and third messages could be iterated upon to optimize the spectrum use. = Knowing what channels the systems in an area are using, the spectrum regulators and/or other entities such as those taking care of coexistence could use = the database in near-real-time to iterate on the two last messages to reduce = the range of channels that some systems may use once they know precisely = what channels are being used in the area. The PAWS protocol would carry the information back and forth but would not be involved in such spectrum = use optimization. Yours, joel On 3/8/2012 1:09 PM, scott.probasco@nokia.com wrote: > Hi Peter, > > Answers below. > > Kind Regards, > Scott > > On 3/8/12 11:39 AM, "ext Peter Saint-Andre" = wrote: > >> Hi Scott, I have two clarifying questions: >> >> 1. Does the device know, when it receives the channel response, which >> channel it will actually use? > Scott->This is all new and I am not aware of any existing = implementations. > I would argue that the device must decide what channel(s) it will use = when > it receives the channel response. [GC] Agree with Scott but this is only a portion of the considerations. = If a device was to operate on its own, this would be true but a communication device usually implies at least 2 devices to communicate. Hence, the = choice of the channel to be used will need to be negotiated between the two = devices before a choice can be made. The chosen channel will belong to the set = of available channels that is common to both devices. Remember that some channels may be available at one device and not at the other because of their geolocation or other reason. Extending this concept to a star = network topology, the channel that will be selected by this network will have to belong to the set of channels that are available to all devices. Each = device will not be able to decide by itself which channel it wants to use. This is why in such a star topology, it makes sense that the slave = devices to a base station or access point be represented by the base station = acting as the master on their behalf to query the database and receive the list = of available channels (and/or maximum EIRP per channel). It is then the responsibility of the base station to identify the set of available = channels that is common for itself and all its slaves to decide on the channel = that the network will use. As you can see, in this case, there is no need for each slave to receive its list of available channels. On its own, it = would not know what to do with it. The only thing that needs to be sent from = the master device to its slaves is the resulting operating channel. I a more sophisticated operation, the master device may add one or a few backup channels extracted from the common set of available channel to = the message going to its slave so that if a change in channel availability occurs, an instantaneous switch to the next backup channel can be made without any further signaling, thus providing for a channel switch that = is transparent to the user. It is the scheme that has been included in the = IEEE 802.22-2011 Standard. This is why I don't believe that PAWS should get involved in defining this signaling between the base station and its = slaves devices. >> >> 2. If the device then uses another channel or a different channel, = does >> it need to report that change to the database? > Scott->My interpretation of section 3.18 is that the device can only > transmit within the upper& lower frequencies returned in the > acknowledgment. I do not (quickly) find any reference in the = requirements > to changing channels. Thus operationally it could be that the channel > request process must be repeated before the device can use a different > channel (frequencies). [GC] If the process involves 2 messages, then, the device and its = associated devices could change channels at will as long as all these channels = belong to the set of available channel. However, if the third message is added, = it would make sense that the master device reports to the database any = channel change that would occur to the database, otherwise, the status of the spectrum occupation would be wrong at any moment and would be useless = for the purpose of any spectrum usage optimization such as coexistence. >> >> Thanks! >> >> Peter >> >> On 3/8/12 10:17 AM, scott.probasco@nokia.com wrote: >>> Hi, >>> >>> The point from Brian is very relevant: >>> >>> Channel request >>> Channel response >>> Channel acknowledgement >>> >>> What Ofcom does with the information in the acknowledgement does not >>> matter. As the regulator in UK, they write rules that must be = followed >>> in >>> order to operate a whitespace radio in the UK. I believe the scope = of >>> the >>> WG must be focused on a working solution. If this is simple channel >>> request& response in one regulator's domain, PAWS can support this. = If >>> it >>> means a channel request, response and acknowledgement in another >>> regulator's domain, PAWS can support this. As a participating member = of >>> the work group, I believe the scope should be basic working = solution, >>> not >>> limited to a specific number of messages. >>> >>> Kind Regards, >>> Scott >>> >>> >>> >>> On 3/8/12 11:11 AM, "ext Zuniga, Juan Carlos" >>> wrote: >>> >>>> Peter, Nancy, >>>> >>>> I agree should design a protocol with the best of our current >>>> knowledge, >>>> and that should be accounting for all the known regulations at = present >>>> time. We should not limit the scope with the purpose of designing a >>>> protocol 'faster'. Our goal is not only to design a WSDB protocol. = Our >>>> goal is to design a WSDB protocol that is USEFUL to the community. >>>> >>>> The charter does state that >>>> >>>> "...the group should also reach out to other potential >>>> "customers" for a white space database access method and consider = input >>> >from regulatory entities that are involved in the specification of = the >>>> rules for secondary use of spectrum in specific radio bands. " >>>> >>>> I think that is exactly what we are doing now. >>>> >>>> Regarding whether the types of requirements belong to #1 or #2, I >>>> believe >>>> it is more of #1 type, as the information to be exchanged would be >>>> known >>>> after the initial query/response. >>>> >>>> If we know it today, I see no reason why we should not work on it = in >>>> the >>>> first phase of the work. >>>> >>>> Regards, >>>> >>>> Juan Carlos >>>> >>>>> -----Original Message----- >>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On = Behalf >>>>> Of >>>>> Peter Saint-Andre >>>>> Sent: Thursday, March 08, 2012 11:59 AM >>>>> To: Nancy Bravin >>>>> Cc: paws@ietf.org; johnny.dixon@bt.com; chris.cheeseman@bt.com; = Pete >>>>> Resnick >>>>> Subject: Re: [paws] WGLC for = draft-ietf-paws-problem-stmt-usecases- >>>>> rqmts-03: channel reporting >>>>> >>>>> Hi Nancy, >>>>> >>>>> You are absolutely right that different locales will have = different >>>>> rules and requirements. We need to understand those, and work to >>>>> address >>>>> them if possible (although we don't necessarily need to address = them >>>>> all >>>>> at the same time). I see several kinds of requirements: >>>>> >>>>> 1. Some requirements might lead to features beyond the = query/response >>>>> protocol we've envisioned so far. One example might be real-time >>>>> reporting about the channels that a device is actually using. In = my >>>>> opinion, it would be best to handle those in the next phase of = work, >>>>> because as far as I can see they are outside the scope of our = charter. >>>>> >>>>> 2. Some requirements might be handled through by defining = additional >>>>> fields that can be included in the query or response. We = definitely >>>>> planned for that when working on the charter with the IESG: >>>>> >>>>> In addition, the particular >>>>> data exchanged between a device and a database might depend on = the >>>>> ranges of radio spectrum that are to be used, the requirements = of >>>>> the >>>>> database operators and their governing regulations, and other >>>>> factors. >>>>> Therefore, the database access method and the query/response = data >>>>> formats that are exchanged using that method need to be = designed for >>>>> extensibility rather than being tied to any specific spectrum, >>>>> country, or phy/mac/air interface. >>>>> >>>>> It's unclear to me right now if the Ofcom requirement fits into #1 = or >>>>> #2, which is why we're having this discussion. :) >>>>> >>>>> Peter >>>>> >>>>> On 3/7/12 8:17 PM, Nancy Bravin wrote: >>>>>> Peter and all, >>>>>> >>>>>> I agree that it is important to revisit now, so that in the = future, >>>>>> it will be easy to align things in their proper place. Every = country >>>>>> may have different regulations, spectrum, policy and what >>>>>> responsibility is in the domain of the system, and what comes = under >>>>>> the PAWS charter is important. Maybe some separation might be >>>>>> possible, and dividing and clarifying issues now will help in the >>>>>> future. Certainly it seems that the FCC may change some rules, = and >>>>>> we know that Ofcom is not yet finished with their regulations. = Canada >>>>>> has their own, and other countries are working on this as well. = Just >>>>>> a thought...Sharing is a realistic goal...as is off loading... Or = you >>>>>> slim line and every 6 months decide what to incorporate in the >>>>>> protocol based on new information, new ideas, new innovation new >>>>>> regulations and maybe spend more time than you could if addressed >>>>>> now. >>>>>> >>>>>> That way you leave the door open and outside of referencing what = is >>>>>> known today, by referencing regulations i.e. Ofcom, FCC, Industry >>>>>> Canada etc as of XX-XX-XXXX date. Out of scope not something we = know >>>>>> enough about to say at this point, In my opinion. >>>>>> >>>>>> My 2 cents.. >>>>>> >>>>>> Sincerely, Nancy >>>>>> >>>>>> On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> As your responsible Area Director (until March 28, when Pete >>>>>>> Resnick will take over from me), I have reviewed this thread. >>>>>>> >>>>>>> In my opinion (I am happy to be proven wrong), this new = requirement >>>>>>> goes beyond what the charter defined as the scope of this = working >>>>>>> group, which was to enable a device to discover the white space >>>>>>> available to it in its current location. Reporting usage back to >>>>>>> the database is simply not mentioned in the charter. >>>>>>> >>>>>>> Earlier in this thread, Andy Sago wrote: >>>>>>> >>>>>>> There's no language I can find in the charter that explicitly = puts >>>>>>> this out of scope. >>>>>>> >>>>>>> An IETF charter defines what the working group shall work on. = Many >>>>>>> interesting features could be developed here. However, it is not >>>>>>> the job of the charter to mention explicitly that each of those >>>>>>> interesting features is out of scope. >>>>>>> >>>>>>> The charter does say: >>>>>>> >>>>>>> Once the device learns of the available white space (e.g., in a = TV >>>>>>> white space implementation, the list of available channels at = that >>>>>>> location), it can then select one of the bands from the list and >>>>>>> begin to transmit and receive on the selected band. >>>>>>> >>>>>>> This text might have assumed that no further communication or >>>>>>> authorization was required in order to select one of the bands = from >>>>>>> the list and then transmit/receive. Perhaps that assumption was >>>>>>> mistaken. If so, it would be good to have a discussion about = that, >>>>>>> so we can determine if we need to revisit the assumptions we = made >>>>>>> early on. If in fact we made some faulty or limited assumptions, >>>>>>> then let's get that out in the open. >>>>>>> >>>>>>> Peter >>>>>>> >>>>>>> On 3/7/12 9:40 AM, Rosen, Brian wrote: >>>>>>>> I'd also suggest that our >>>>>>>> charter limitation is really support for sharing of whitespace = by >>>>>>>> whitespace devices. Reporting what you use is not sharing, = it's >>>>>>>> just data gathering. >>>>>>>> >>>>>>>> The point of excluding sharing was to eliminate the = complexities >>>>>>>> of what constituted fairness, and what kinds of communication >>>>>>>> might be needed between databases, where more than one could >>>>>>>> supply available whitespace in a band. This doesn't have any = of >>>>>>>> those issues, As long as it's just sending information, I don't >>>>>>>> have a problem. Once the database is supposed to do anything >>>>>>>> with it that involves changing what spectrum it reports, then I >>>>>>>> think we cross the line. >>>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>> On Mar 6, 2012, at 12:28 PM, >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Joel >>>>>>>>> >>>>>>>>> Indeed, the regulator has not described the process or = provided >>>>>>>>> a flow diagram, so there may be some wrinkles, but we need to >>>>>>>>> provide for their intent. To answer your question, the = channels >>>>>>>>> that the master will use are sent in a separate message >>>>>>>>> (described in P.12 ter), that occurs after the master receives >>>>>>>>> the response to its channel request, but before the master can >>>>>>>>> transmit. At this point, it knows what channels are available, >>>>>>>>> and which one it will use. As far as the slaves are concerned, >>>>>>>>> as they associate, the master will need to gather their = details >>>>>>>>> and send further channel usage messages to the database on >>>>>>>>> their behalf. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> Andy >>>>>>>>> >>>>>>>>> -----Original Message----- From: paws-bounces@ietf.org >>>>>>>>> [mailto:paws-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>>>>>>> Sent: 06 March 2012 17:05 To: scott.probasco@nokia.com Cc: >>>>>>>>> paws@ietf.org; Cheeseman,CJ,Chris,COD R; Dixon,JS,Johnny,COD R >>>>>>>>> Subject: Re: [paws] WGLC for >>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel >>>>>>>>> reporting >>>>>>>>> >>>>>>>>> Ahh. I think I see where the request and my understanding >>>>>>>>> divurge. If the idea here is that the master must provide, in >>>>>>>>> the request, an indication of what channels it expects to use, >>>>>>>>> I can at least understand that. I will return to technical >>>>>>>>> concerns in a moment. >>>>>>>>> >>>>>>>>> However, when you say "provide channel usage information, in >>>>>>>>> order to evaluate interference", what that says to me is >>>>>>>>> providing, during operation, information as to what channels >>>>>>>>> are being used, and at what power levels. That is what would >>>>>>>>> be needed to analyze actual interference effects. And that is >>>>>>>>> out of scope as I understand our scope. >>>>>>>>> >>>>>>>>> I do see a technical difficulty with having the master = provide, >>>>>>>>> as part of either registering or requesting spectrum >>>>>>>>> information, what channels it intends to use. It doesn;t know >>>>>>>>> what channels it intends to use. It intends to use some = number >>>>>>>>> of available channels. It will figure out which ones when it >>>>>>>>> is told what is available. How can it send that information = in >>>>>>>>> the request? >>>>>>>>> >>>>>>>>> Yours, Joel >>>>>>>>> >>>>>>>>> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> There is a similarity here with device ID. In context of PAWS >>>>>>>>>> we are not concerned with why a device ID is required by a >>>>>>>>>> regulator, we accept it is a requirement from a regulator and >>>>>>>>>> include it to the protocol. Ofcom identifies in 3.18& 3.19 >>>>>>>>>> that channel usage information is required and thus we need >>>>>>>>>> to include this information. Since the master must provide >>>>>>>>>> this information prior to transmitting, PAWS will not >>>>>>>>>> function in the UK without this information and thus I >>>>>>>>>> believe channel usage information is integral to the channel >>>>>>>>>> request& response messaging. >>>>>>>>>> >>>>>>>>>> Kind Regards, Scott >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 3/6/12 10:30 AM, "ext Joel M. >>>>>>>>>> Halpern" wrote: >>>>>>>>>> >>>>>>>>>>> I would draw a distinction. Ofcom regulations about >>>>>>>>>>> whitespace requests are very much relevant. Ofcom >>>>>>>>>>> regulations about notification of dynamic behavior (which >>>>>>>>>>> spectrum is being used) are not in scope as I understand >>>>>>>>>>> the earlier discussions, particularly the chartering >>>>>>>>>>> discussions. >>>>>>>>>>> >>>>>>>>>>> Yours, Joel >>>>>>>>>>> >>>>>>>>>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: >>>>>>>>>>>> >>>>>>>>>>>> The ofcom requirements are very much relevant to the >>>>>>>>>>>> scope of the PAWS WG. The only other regulatory >>>>>>>>>>>> requirements that we have today is the FCC. Ofcom >>>>>>>>>>>> requirements are a good addition to the set. >>>>>>>>>>>> >>>>>>>>>>>> -Raj >>>>>>>>>>>> >>>>>>>>>>>> On 3/6/12 10:03 AM, "ext >>>>>>>>>>>> andy.sago@bt.com" wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Joel >>>>>>>>>>>>> >>>>>>>>>>>>> There's no language I can find in the charter that >>>>>>>>>>>>> explicitly puts this out of scope. On the other hand, >>>>>>>>>>>>> the charter says that the group will "consider input >>>>>>>>>>>>> from regulatory entities", and this is one of the >>>>>>>>>>>>> requirements from Ofcom that they have just published. >>>>>>>>>>>>> The protocol will be worthless for the UK if it omits >>>>>>>>>>>>> some requirements. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards >>>>>>>>>>>>> >>>>>>>>>>>>> Andy >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- From: Joel M. Halpern >>>>>>>>>>>>> [mailto:jmh@joelhalpern.com] Sent: 06 March 2012 15:53 >>>>>>>>>>>>> To: Sago,AJ,Andy,COD R Cc: paws@ietf.org; >>>>>>>>>>>>> Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for >>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel >>>>>>>>>>>>> reporting >>>>>>>>>>>>> >>>>>>>>>>>>> As I understand, the information you are asking for is >>>>>>>>>>>>> explicitly out of scope for the working group. Yours, >>>>>>>>>>>>> Joel >>>>>>>>>>>>> >>>>>>>>>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >>>>>>>>>>>>>> All >>>>>>>>>>>>>> >>>>>>>>>>>>>> Comparing the draft with the Ofcom requirements at >>>>>>>>>>>>>> http://www.cept.org/Documents/se- >>>>> 43/4161/SE43(12)Info03_Draft-UK-r >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>> egul >>>>>>>>>>>>>> atory-requirements-for-white-space-devices-in-the-UHF-TV- >>>>> band, >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>> I believe the WG draft is deficient in the area of reporting >>>>>>>>>>>>>> frequencies and powers actually used by masters and >>>>>>>>>>>>>> slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom >>>>>>>>>>>>>> intends to collect this data to assesses the impact >>>>>>>>>>>>>> of aggregate interference into other services. It >>>>>>>>>>>>>> would also provide usage information (frequency in >>>>>>>>>>>>>> use) that would inform the operation of a kill switch >>>>>>>>>>>>>> capability. I suggest this deficiency can be remedied >>>>>>>>>>>>>> with the following changes: >>>>>>>>>>>>>> >>>>>>>>>>>>>> New P requirements (probably best placed following >>>>>>>>>>>>>> P.12): >>>>>>>>>>>>>> >>>>>>>>>>>>>> P.12bis: The protocol MUST support a channel usage >>>>>>>>>>>>>> message from the slave device to the master device. >>>>>>>>>>>>>> The channel usage message MUST include parameters as >>>>>>>>>>>>>> required by local regulatory requirement. These >>>>>>>>>>>>>> parameters MAY include device ID, manufacturer's >>>>>>>>>>>>>> serial number, channel usage and power level >>>>>>>>>>>>>> information. >>>>>>>>>>>>>> >>>>>>>>>>>>>> P.12ter: The protocol MUST support a channel usage >>>>>>>>>>>>>> message from the master device to the database. The >>>>>>>>>>>>>> channel usage message MUST include parameters as >>>>>>>>>>>>>> required by local regulatory requirement for the >>>>>>>>>>>>>> master and its associated slaves. These parameters >>>>>>>>>>>>>> MAY include device ID, manufacturer's serial number, >>>>>>>>>>>>>> channel usage and power level information. >>>>>>>>>>>>>> >>>>>>>>>>>>>> P.12qua: The protocol MUST support a channel usage >>>>>>>>>>>>>> message acknowledgement. >>>>>>>>>>>>>> >>>>>>>>>>>>>> New O requirements (probably best placed following >>>>>>>>>>>>>> O13): >>>>>>>>>>>>>> >>>>>>>>>>>>>> O.13bis: According to local regulatory policy, after >>>>>>>>>>>>>> connecting to a master device's radio network a slave >>>>>>>>>>>>>> device MAY inform the master device of the actual >>>>>>>>>>>>>> channel usage. The slave MUST include parameters >>>>>>>>>>>>>> required by local regulatory policy, e.g. device ID, >>>>>>>>>>>>>> manufacturer's serial number, channel usage and power >>>>>>>>>>>>>> level information. >>>>>>>>>>>>>> >>>>>>>>>>>>>> O.13ter: According to local regulatory policy, a >>>>>>>>>>>>>> master device MAY inform the database of the actual >>>>>>>>>>>>>> channel usage of the master and its slaves. The >>>>>>>>>>>>>> master MUST include parameters required by local >>>>>>>>>>>>>> regulatory policy, e.g. device ID, manufacturer's >>>>>>>>>>>>>> serial number, channel usage and power level >>>>>>>>>>>>>> information of the master and its slaves. >>>>>>>>>>>>>> >>>>>>>>>>>>>> New steps could be introduced into one or more use >>>>>>>>>>>>>> cases to cover these Ofcom requirements, e.g. new >>>>>>>>>>>>>> steps 6bis and 9bis in the hotspot use case at >>>>>>>>>>>>>> 4.2.1: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 6bis. Prior to initiating transmission, if required >>>>>>>>>>>>>> by local regulation, the master/AP informs the >>>>>>>>>>>>>> database of the channel and power level it has >>>>>>>>>>>>>> chosen. This is repeated for each slave that >>>>>>>>>>>>>> associated with the master. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 9bis. Prior to initiating transmission, if required >>>>>>>>>>>>>> by local regulation, the slave informs the master/AP >>>>>>>>>>>>>> of the channel and power level it has chosen, and the >>>>>>>>>>>>>> master/AP relays this information to the database. >>>>>>>>>>>>>> >>>>>>>>>>>>>> - end of new text - >>>>>>>>>>>>>> >>>>>>>>>>>>>> For information, for those not accessing the url in >>>>>>>>>>>>>> the first paragraph of this email, the full Ofcom >>>>>>>>>>>>>> requirements leading to this new PAWS text are as >>>>>>>>>>>>>> follows: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 3.18 After receiving instructions from a WSDB in >>>>>>>>>>>>>> relation to the maximum permitted EIRPs over the DTT >>>>>>>>>>>>>> channels, and prior to initiating transmissions >>>>>>>>>>>>>> within the UHF TV band, a master WSD must communicate >>>>>>>>>>>>>> to the WSDB the following information: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 3.18.1 The lower and upper frequency boundaries^13 of >>>>>>>>>>>>>> the in-block emissions of the master WSD, and those >>>>>>>>>>>>>> of the in-block emissions of its associated slaves. A >>>>>>>>>>>>>> lower frequency will be specified as (470 + 8k + >>>>>>>>>>>>>> 0.2n) MHz, with the corresponding upper frequency >>>>>>>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3=AE4 k 3=AE4 >>>>>>>>>>>>>> 39, 0 3=AE4 n 3=AE4 39, 1 3=AE4 m 3=AE4 40, and n< m. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 3.18.2 The maximum in-block EIRP spectral densities >>>>>>>>>>>>>> (in dBm/(0.2 MHz)) that the master WSD, and its >>>>>>>>>>>>>> associated slaves, actually radiate between each >>>>>>>>>>>>>> reported lower frequency boundary and its >>>>>>>>>>>>>> corresponding upper frequency boundary. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Footnote 13 states: >>>>>>>>>>>>>> >>>>>>>>>>>>>> The use of upper and lower frequency boundaries >>>>>>>>>>>>>> (defined over a 200 kHz raster) allows a WSDB to >>>>>>>>>>>>>> collect more granular information with regards to the >>>>>>>>>>>>>> usage of the frequency resource by narrowband WSD >>>>>>>>>>>>>> technologies. The upper and lower frequencies of a >>>>>>>>>>>>>> boundary pair do not straddle a DTT channel boundary. >>>>>>>>>>>>>> Note that a WSD may transmit over multiple, >>>>>>>>>>>>>> non-contiguous, whole DTT channels or fractions of >>>>>>>>>>>>>> DTT channels. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 3.19 A master WSD must be able to receive the >>>>>>>>>>>>>> following information^14 from a WSDB: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in the >>>>>>>>>>>>>> context of 3.18, that the reported information on the >>>>>>>>>>>>>> DTT channels and EIRP spectral densities actually >>>>>>>>>>>>>> used by the master and slave WSDs were received >>>>>>>>>>>>>> successfully by the WSDB^18 ]. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Footnote 14 states: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 14 While the communication of some of this >>>>>>>>>>>>>> information from a WSDB to a master WSD is optional, >>>>>>>>>>>>>> master WSDs must be able to receive and interpret >>>>>>>>>>>>>> these. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Footnote 18 states: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 18 This forms part of a handshake protocol and may be >>>>>>>>>>>>>> an area where industry could harmonise without the >>>>>>>>>>>>>> need for an explicit requirement in the regulations. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards >>>>>>>>>>>>>> >>>>>>>>>>>>>> Andy >>>>>>>>>>>>>> >>>>>>>>>>>>>> *From:*paws-bounces@ietf.org >>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] *On Behalf Of >>>>>>>>>>>>>> *Gabor.Bajko@nokia.com *Sent:* 05 March 2012 19:46 >>>>>>>>>>>>>> *To:* paws@ietf.org *Subject:* [paws] WGLC for >>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >>>>>>>>>>>>>> >>>>>>>>>>>>>> The authors of the use cases and requirements draft >>>>>>>>>>>>>> have just posted a new version of the draft and >>>>>>>>>>>>>> indicated that there are no unresolved >>>>>>>>>>>>>> comments/issues they are aware of. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Therefore, I'd like to initiate a WG Last Call for >>>>>>>>>>>>>> comments on >>>>>>>>>>>>>> = http://www.ietf.org/internet-drafts/draft-ietf-paws-problem- >>>>> stmt-u >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>> seca >>>>>>>>>>>>>> ses-rqmts-03.txt >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review the draft and send your comments to the >>>>>>>>>>>>>> list by March 20th, 2012. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If you review the draft and have no comments, send a >>>>>>>>>>>>>> note to the list that the draft is good as it is, we >>>>>>>>>>>>>> need these notes as much as we need the actual >>>>>>>>>>>>>> comments. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, Gabor >>>>>>>>>>>>>> >>>>>>>>>>>>>> > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From gerald.chouinard@sympatico.ca Thu Mar 8 11:10:26 2012 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 2449D21F84E0 for ; Thu, 8 Mar 2012 11:10:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.066 X-Spam-Level: X-Spam-Status: No, score=-0.066 tagged_above=-999 required=5 tests=[AWL=0.902, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, MSGID_FROM_MTA_HEADER=0.803, 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 R5ozqfWS7t-1 for ; Thu, 8 Mar 2012 11:10:23 -0800 (PST) Received: from blu0-omc3-s34.blu0.hotmail.com (blu0-omc3-s34.blu0.hotmail.com [65.55.116.109]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8B321F84F5 for ; Thu, 8 Mar 2012 11:10:23 -0800 (PST) Received: from BLU0-SMTP28 ([65.55.116.72]) by blu0-omc3-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 11:10:22 -0800 X-Originating-IP: [174.95.243.14] X-Originating-Email: [gerald.chouinard@sympatico.ca] Message-ID: Received: from Gerald2 ([174.95.243.14]) by BLU0-SMTP28.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 11:10:20 -0800 From: Gerald Chouinard To: References: Date: Thu, 8 Mar 2012 14:10:21 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0194_01CCFD35.33883400" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AQHM+7qBJZkKE/OsEE6WAJSH4Dz7PpZdfy+A//+SKwCAAHc5wP//kfoAgAB2qjCAAqFTAIAAkR4g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 08 Mar 2012 19:10:21.0214 (UTC) FILETIME=[1B8233E0:01CCFD5F] Cc: paws@ietf.org Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 19:10:26 -0000 ------=_NextPart_000_0194_01CCFD35.33883400 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Scott, =20 I agree with you that, as far as the database is concerned, all devices should look the same and the assumption should be that each of these = devices would contact the database to receive its list of available channel. However, if a network operation is such that queries for some of the = devices are made through a =A1=AEproxy=A1=AF such as a base station representing = its associated slaves, it should be transparent to the database (except for = the IP address where the information is sent to). That the =A1=AEproxy=A1=AF = sends this list of available channels to the represented slave or its = =A1=AEproxy=A1=AF should not matter to the database. As far at it is concerned, it did its job. = It should not get involved with the communication on the other side of the =A1=AEproxy=A1=AF. =20 As you can see in the other email thread that I have just responded to, = the information going from the base station to its associated slaves could = be very different than the list of available channels for these individual devices. The choice of the operating channel involves an intersection of = all available channel lists and not each the individual list. =20 Gerald=20 =20 _____ =20 From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com]=20 Sent: Thursday, 08 March, 2012 12:20 To: gerald.chouinard@sympatico.ca Cc: paws@ietf.org Subject: Re: [paws] WGLC for = draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting =20 Hi Gerald, =20 I agree that some wireless standards will elect to implement signaling related to database access, e.g. signaling between the slave the and the master. But PAWS is independent of the radio and therefore cannot expect that portions of the necessary signaling will be implemented elsewhere. = In the scope of the WG we don't differentiate between a master or slave, we simply address providing channel lists to ensure proper operation of a = white space radio network. =20 Perhaps the chairs could allocate some time on the agenda in the coming meeting to discuss this topic. =20 Kind Regards, Scott =20 =20 From: ext Chouinard Date: Tue, 6 Mar 2012 13:18:25 -0500 To: Scott Probasco Cc: "paws@ietf.org" Subject: RE: [paws] WGLC for = draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting =20 Scott, =20 I believe that this could be kept simple by assuming that if a device = needs to directly communicate its information to the database, it can be considered for the purpose of PAWS as a =A1=B0master=A1=B1 device. If = this can be done through a proxy device in between, then the device needs to be = slaved to this device in between which will then be considered as the = =A1=B0master=A1=B1. In such case, the wireless standard used between these devices needs to = have all the necessary means to transmit the necessary information from the =A1=B0slave=A1=B1 to its =A1=B0master=A1=B1 to meet the requirements of = white space operation. The way it is done can vary from one technology to another. = This was, the scope of PAWS is limited to the link between the master and the database and not between the slave and the master. =20 Gerald =20 _____ =20 From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com]=20 Sent: Tuesday, 06 March, 2012 13:05 To: gerald.chouinard@sympatico.ca Cc: paws@ietf.org Subject: Re: [paws] WGLC for = draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting =20 Hi Gerald, =20 I agree with you that some wireless standards will include signaling = that supports database access. But PAWS is not specific to any particular = radio technology, we cannot expect that all radio technologies will include = some components of the signaling for database access. PAWS should include all necessary messages for contact between the device and the database, = without presumption of the underlying radio technology. =20 Kind Regards, Scott =20 From: ext Chouinard Date: Tue, 6 Mar 2012 12:44:09 -0500 To: Scott Probasco Cc: "paws@ietf.org" Subject: RE: [paws] WGLC for = draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting =20 Scott, =20 I am fine with your second sentence. However, I have some difficulty = with your third sentence since this would mean that the IETF-PAWS would get = into defining the signaling details between the slave and the master devices. = I believe this should be left to the wireless standard. Obviously, having this information available at the master would become a requirement that = the wireless standard would have to meet to be able to operate in white = space. The way it would be done would be internal to the wireless standard. = PAWS would take it from the master to the database. =20 Gerald =20 _____ =20 From: scott.probasco@Nokia.com [mailto:scott.probasco@Nokia.com]=20 Sent: Tuesday, 06 March, 2012 12:32 To: gerald.chouinard@sympatico.ca Cc: paws@ietf.org Subject: Re: [paws] WGLC for = draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting =20 Hi Gerald, =20 I believe Andy's proposal agrees with your suggestion below. Looking at O.13bis, the slave MAY send the channel usage information and if it does = so, it MUST include the following variables. I think P.12bis is appropriate since the message MUST be defined by the protocol inorder to have the = OPTION of sending it. When these two requirements are considered jointly does = this provide the implementation flexibility you arethinking of? =20 Kind Regards, Scott =20 From: ext Chouinard Date: Tue, 6 Mar 2012 12:13:05 -0500 To: Scott Probasco Cc: "paws@ietf.org" Subject: RE: [paws] WGLC for = draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting =20 Scott, =20 I am fine with your approach as long as the text says something as = follows: =A1=B0the operating channel of the slave needs to be provided to the = database=A1=B1 rather than: =A1=B0the slave needs to provide the database with its = operating channel=A1=B1. This way, this information can be provided by either the = slave or the master, not making it mandatory that the =A1=B0slave=A1=B1 has to = do it if the master knows the information. =20 The text proposed by Andy: =A1=B0The protocol MUST support a channel = usage message from the slave device to the master device.=A1=B1 Implies that = the protocol to be developed needs to apply on the connection between the = slave and the master. Such connection should be implementation dependant. = What is required is that the information beavailable to the master for it to transmit it to the database, never mind the format that isused between = the slave and the master to carry this information. =20 Gerald =20 _____ =20 From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com]=20 Sent: Tuesday, 06 March, 2012 12:00 To: gerald.chouinard@sympatico.ca; andy.sago@bt.com Cc: paws@ietf.org Subject: Re: [paws] WGLC for = draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting =20 Hi Gerald, =20 At least according to the FCC, a slave (Mode I) device may utilize = channels that the master (fixed device) cannot use, see =A1=EC15.707 and 15.712. = Thus there are potential situations where the master cannot be assumed to = know what channel the slave is using. Although this is a bit esoteric as the = FCC is silent about what the slave might do on those channels, it is = nonetheless included in the FCC regulations. =20 So I suggest we have no reason to overrule Ofcom requirements for = channel usage information. Also Andy's choice of words does ensure that this information is not required to be used in every operational scenario. =20 Kind Regards, Scott =20 =20 =20 From: ext Chouinard Date: Tue, 6 Mar 2012 11:44:07 -0500 To: ext com Cc: "paws@ietf.org" Subject: Re: [paws] WGLC for = draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting =20 Andy, =20 Looking at your suggestions below, it seems that there is a need to = define more precisely what a =A1=B0slave=A1=B1 device is relative to its = =A1=B0master=A1=B1. =20 In my view, a slave can only use the same transmission channel as that = used by the master to which it is associated (otherwise, master and slaves = would not be able to talk to each other). As a consequence, the slave does not have to indicate to the master the channel on which it is operating = since the master knows it and can provided it to the database e. =20 Similarly, modern bidirectional communication systems between a master = and a slave device assumes that there will be a transmit power control (TPC) = loop between the two devices to minimize the required transmit power in = various propagation environments. The driving device in this closed-loop process will be the master and as a result, the EIRP transmitted by the slave = device will be known to the master as long as there is a known factor linking = the power specification sent by the master to the slave and the actual EIRP transmitted by the slave. Such factor which is a constant for each = device can be provided from the slave to the master once at association. As a result, the slave does not need to inform the master of its current (and provably continuously varying) EIRP since the master will havethis information from its TPC process and can provide it to the database = onbehalf of the slave device. =20 Gerald =20 _____ =20 From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of andy.sago@bt.com Sent: Tuesday, 06 March, 2012 10:42 To: paws@ietf.org; Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for = draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting =20 All =20 Comparing the draft with the Ofcom requirements at http://www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-regulato= ry- requirements-for-white-space-devices-in-the-UHF-TV-band, I believe the = WG draft is deficient in the area of reporting frequencies and powers = actually used by masters and slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom intends to collect this data to assesses the impact of aggregate interference into other services. It would also provide usage = information (frequency in use) that would inform the operation of a kill switch capability. I suggest this deficiency can be remedied with the following changes: =20 New P requirements (probably best placed following P.12): =20 P.12bis: The protocol MUST support a channel usage message from the = slave device to the master device. The channel usage message MUST include parameters as required by local regulatory requirement. These = parameters MAY include device ID, manufacturer's serial number, channel usage and = power level information. =20 P.12ter: The protocol MUST support a channel usage message from the = master device to the database. The channel usage message MUST include = parameters as required by local regulatory requirement for the master and its associated slaves. These parameters MAY include device ID, = manufacturer's serial number, channel usage and power level information. =20 P.12qua: The protocol MUST support a channel usage message = acknowledgement. =20 New O requirements (probably best placed following O13): =20 O.13bis: According to local regulatory policy, after connecting to a = master device'sradio network a slave device MAY inform the master device of the actual channel usage. The slave MUST include parameters required by = local regulatory policy, e.g. device ID, manufacturer's serial number, channel usage and power levelinformation. =20 O.13ter: According to local regulatory policy, a master device MAY = inform the database of the actual channel usage of the master and its slaves. = The master MUST include parameters required by local regulatory policy, e.g. device ID, manufacturer's serial number, channel usage and power level information of the master and its slaves. =20 New steps could be introduced into one or more use cases to cover these Ofcom requirements, e.g. new steps 6bis and 9bis in the hotspot use case = at 4.2.1: =20 6bis. Prior to initiating transmission, if required by local regulation, = the master/AP informs the database of the channel and power level it has = chosen. This is repeated for each slave that associated with the master. =20 9bis. Prior to initiating transmission, if required by local regulation, = the slave informs the master/AP of the channel and power level it has = chosen, and themaster/AP relays this information to the database.=20 =20 - end of new text - =20 For information, for those not accessing the url in the first paragraph = of this email, the full Ofcom requirements leading to this new PAWS text = are as follows: =20 3.18 After receiving instructions from a WSDB in relation to the maximum permitted EIRPs over the DTT channels, and prior to initiating = transmissions within the UHF TV band, a master WSD mustcommunicate to the WSDB the following information: 3.18.1 The lower and upper frequency boundaries13 of the in-block = emissions of the master WSD, and those of the in-block emissions of its associated slaves. A lower frequency will be specified as (470 + 8k + 0.2n) MHz, = with the corresponding upper frequency specified as (470 + 8k + 0.2m) MHz, = where 0 =A1=DC k =A1=DC 39, 0 =A1=DC n =A1=DC 39, 1 =A1=DC m =A1=DC 40, and n = < m. 3.18.2 The maximum in-block EIRP spectral densities (in dBm/(0.2 MHz)) = that the masterWSD, and its associated slaves, actually radiate between each reported lower frequency boundary and its corresponding upper frequency boundary. =20 Footnote 13 states: The use of upper and lower frequency boundaries (defined over a 200 kHz raster) allows a WSDB to collect more granular information with regards = to the usage of the frequency resource bynarrowband WSD technologies. The = upper and lower frequencies of a boundary pair do notstraddle a DTT channel boundary. Note that a WSD may transmit over multiple, non-contiguous, = whole DTT channels or fractions of DTT channels. =20 3.19 A master WSD must be able to receive the following information14 = from a WSDB: 3.19.8 [An acknowledgement from the WSDB, in the context of 3.18, = that the reported information on the DTT channels and EIRP spectral densities actually used by the master and slave WSDs were received successfully by = the WSDB18]. =20 Footnote 14 states: 14 While the communication of some of this information from a WSDB to a master WSD is optional, master WSDs must be able to receive and = interpret these. =20 Footnote 18 states: 18 This forms part of a handshake protocol and may be an area where = industry could harmonise without the need for an explicit requirement in the regulations. =20 Regards =20 Andy =20 From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com Sent: 05 March 2012 19:46 To: paws@ietf.org Subject: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03 =20 The authors of the use cases and requirements draft have just posted a = new version of the draft and indicated that there are no unresolved comments/issues they are aware of. =20 Therefore, I'd like to initiate a WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases= -rq mts-03.txt =20 Please review the draft and send yourcomments to the list by March 20th, 2012. =20 If you review the draft and have no comments, send a note to the list = that the draft is good as it is, we need these notes as much as we need the actual comments. =20 Thanks, Gabor =20 _______________________________________________ paws mailing list = paws@ietf. org https://www.ietf.org/mailman/listinfo/paws ------=_NextPart_000_0194_01CCFD35.33883400 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Scott,

 

I agree with you that, as far as = the database is concerned, all devices should look the same and the = assumption should be that each of these devices would contact the database to = receive its list of available channel.  However, if a network operation is such = that queries for some of the devices are made through a =A1=AEproxy=A1=AF such as a = base station representing its associated slaves, it should be transparent to the = database (except for the IP address where the information is sent to). That the = =A1=AEproxy=A1=AF sends this list of available channels to the represented slave or its = =A1=AEproxy=A1=AF should not matter to the database.  As far at it is concerned, it did its job. = It should not get involved with the communication on the other side of the = =A1=AEproxy=A1=AF.

 

As you can see in the other email = thread that I have just responded to, the information going from the base station to = its associated slaves could be very different than the list of available = channels for these individual devices. The choice of the operating channel = involves an intersection of all available channel lists and not each the individual = list.

 

Gerald =

 

From: = scott.probasco@nokia.com [mailto:scott.probasco@nokia.com]
Sent: Thursday, 08 March, = 2012 12:20
To: gerald.chouinard@sympatico.ca
Cc: paws@ietf.org
Subject: Re: [paws] WGLC = for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel = reporting

 

Hi = Gerald,

 

I agree that some wireless = standards will elect to implement signaling related to database access, e.g. signaling = between the slave the and the master. But PAWS is independent of the radio and therefore cannot expect that portions of the necessary signaling will be implemented elsewhere. In the scope of the WG we don't differentiate = between a master or slave, we simply address providing channel lists to ensure = proper operation of a white space radio network.

 

Perhaps the chairs could allocate = some time on the agenda in the coming meeting to discuss this = topic.

 

Kind = Regards,

Scott

=

 

 

From: ext Chouinard <gerald.chouinard@sympatico.= ca>
Date: Tue, 6 Mar 2012 = 13:18:25 -0500
To: Scott Probasco <scott.probasco@nokia.com>=
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] WGLC = for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel = reporting

 

Scott,

 

I believe that this could be kept = simple by assuming that if a device needs to directly communicate its = information to the database, it can be considered for the purpose of PAWS as a = =A1=B0master=A1=B1 device. If this can be done through a proxy device in between, then the = device needs to be slaved to this device in between which will then be = considered as the =A1=B0master=A1=B1. In such case, the wireless standard used between = these devices needs to have all the necessary means to transmit the necessary = information from the =A1=B0slave=A1=B1 to its =A1=B0master=A1=B1 to meet the = requirements of white space operation.  The way it is done can vary from one technology to = another. This was, the scope of PAWS is limited to the link between the master = and the database and not between the slave and the = master.

 

Gerald

 

From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com<= /a>]
Sent: Tuesday, 06 March, = 2012 13:05
To: gerald.chouinard@sympatico.= ca
Cc: paws@ietf.org
Subject: Re: [paws] WGLC = for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel = reporting

 

Hi = Gerald,

 <= font color=3Dblack>

I agree with you that some = wireless standards will include signaling that supports database access. But PAWS = is not specific to any particular radio technology, we cannot expect that all = radio technologies will include some components of the signaling for database = access. PAWS should include all necessary messages for contact between the = device and the database, without presumption of the underlying radio = technology.

 <= font color=3Dblack>

Kind = Regards,

Scott

 <= font color=3Dblack>

From: ext Chouinard <gerald.chouinard@sympatico.= ca>
Date: Tue, 6 Mar 2012 = 12:44:09 -0500
To: Scott Probasco <scott.probasco@nokia.com>=
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] WGLC = for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel = reporting

 <= font color=3Dblack>

Scott,

 

I am fine with your second = sentence.  However, I have some difficulty with your third sentence since = this would mean that the IETF-PAWS would get into defining the signaling details = between the slave and the master devices. I believe this should be left to the = wireless standard.  Obviously, having this information available at the = master would become a requirement that the wireless standard would have to meet = to be able to operate in white space. The way it would be done would be = internal to the wireless standard.  PAWS would take it from the master to the = database.

 

Gerald

 

From: scott.probasco@Nokia.com [mailto:scott.probasco@Nokia.com<= /a>]
Sent: Tuesday, 06 March, = 2012 12:32
To: gerald.chouinard@sympatico.= ca
Cc: paws@ietf.org
Subject: Re: [paws] WGLC = for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel = reporting=

 

Hi = Gerald,

 <= font color=3Dblack>

I believe Andy's proposal agrees = with your suggestion below. Looking at O.13bis, the slave MAY send the channel = usage information and if it does so, it MUST include the following variables. = I think P.12bis is appropriate since the message MUST be defined by the protocol inorder to have the OPTION of sending it. When these two requirements = are considered jointly does this provide the implementation flexibility you arethinking of?

 <= font color=3Dblack>

Kind = Regards,

Scott

 <= font color=3Dblack>

From: ext Chouinard <gerald.chouinard@sympatico.= ca>
Date: Tue, 6 Mar 2012 = 12:13:05 -0500
To: Scott Probasco <scott.probasco@nokia.com>=
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] WGLC = for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel = reporting

 <= font color=3Dblack>

Scott,=

 =

I am fine with your approach as = long as the text says something as follows: =A1=B0the operating channel of the = slave needs to be provided to the database=A1=B1 rather than: =A1=B0the slave needs = to provide the database with its operating channel=A1=B1.  This way, this = information can be provided by either the slave or the master, not making it mandatory that = the =A1=B0slave=A1=B1 has to do it if the master knows the = information.=

 =

The text proposed by Andy: = =A1=B0The protocol MUST support a channel usage message from the slave device to = the master device.=A1=B1 Implies that the protocol to be developed needs to = apply on the connection between the slave and the master. Such connection should be = implementation dependant.  What is required is that the information beavailable to = the master for it to transmit it to the database, never mind the format that = isused between the slave and the master to carry this = information.<= /span>

 =

Gerald=

 =

From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com<= /a>]
Sent: Tuesday, 06 March, = 2012 12:00
To: gerald.chouinard@sympatico.= ca; andy.sago@bt.com
Cc: paws@ietf.org
Subject: Re: [paws] WGLC = for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel = reporting<= /span>

 

Hi = Gerald,=

 <= font color=3Dblack>=

At least according to the FCC, a = slave (Mode I) device may utilize channels that the master (fixed device) = cannot use, see =A1=EC15.707 and 15.712. Thus there are potential situations where = the master cannot be assumed to know what channel the slave is using. Although this = is a bit esoteric as the FCC is silent about what the slave might do on those channels, it is nonetheless included in the FCC = regulations.=

 <= font color=3Dblack>=

So I suggest we have no reason to = overrule Ofcom requirements for channel usage information. Also Andy's choice of = words does ensure that this information is not required to be used in every operational scenario.=

 <= font color=3Dblack>=

Kind = Regards,=

Scott=

 <= font color=3Dblack>=

 <= font color=3Dblack>=

 <= font color=3Dblack>=

From: ext Chouinard <gerald.chouinard@sympatico.= ca>
Date: Tue, 6 Mar 2012 = 11:44:07 -0500
To: ext com <andy.sago@bt.com>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] WGLC = for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel = reporting=

 <= font color=3Dblack>=

Andy,<= /span>

 <= /span>

Looking at your suggestions below, = it seems that there is a need to define more precisely what a = =A1=B0slave=A1=B1 device is relative to its =A1=B0master=A1=B1.<= /span>

 <= /span>

In my view, a slave can only use = the same transmission channel as that used by the master to which it is = associated (otherwise, master and slaves would not be able to talk to each other). = As a consequence, the slave does not have to indicate to the master the = channel on which it is operating since the master knows it and can provided it to = the database e.

 <= /span>

Similarly, modern bidirectional communication systems between a master and a slave device assumes that = there will be a transmit power control (TPC) loop between the two devices to = minimize the required transmit power in various propagation environments. The = driving device in this closed-loop process will be the master and as a result, = the EIRP transmitted by the slave device will be known to the master as long as = there is a known factor linking the power specification sent by the master to the = slave and the actual EIRP transmitted by the slave.  Such factor which is = a constant for each device can be provided from the slave to the master = once at association.  As a result, the slave does not need to inform the = master of its current (and provably continuously varying) EIRP since the master = will havethis information from its TPC process and can provide it to the = database onbehalf of the slave device.<= /span>

 <= /span>

Gerald<= /span>

 <= /span>

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] = On Behalf Of andy.sago@bt.com
Sent: Tuesday, 06 March, = 2012 10:42
To: paws@ietf.org; Gabor.Bajko@nokia.com
Subject: Re: [paws] WGLC = for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel = reporting

 

All<= /span>

 <= /span>

Comparing the draft with the = Ofcom requirements at http:= //www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-regulatory-re= quirements-for-white-space-devices-in-the-UHF-TV-band, I believe the WG draft is deficient in the area of reporting frequencies = and powers actually used by masters and slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom intends to collect this data to assesses the impact of = aggregate interference into other services. It would also provide usage = information (frequency in use) that would inform the operation of a kill switch = capability. I suggest this deficiency can be remedied with the following = changes:<= /span>

 <= /span>

New P requirements (probably = best placed following P.12):<= /span>

 <= /span>

P.12bis: The protocol MUST support a channel usage message from the slave device = to the master device.  The channel usage message MUST include parameters = as required by local regulatory requirement.  These parameters MAY = include device ID, manufacturer's serial number, channel usage and power level information.<= /span>

 <= /span>

P.12ter: The protocol MUST support a channel usage message from the master device = to the database.  The channel usage message MUST include parameters as = required by local regulatory requirement for the master and its associated = slaves.  These parameters MAY include device ID, manufacturer's serial number, = channel usage and power level information.<= /span>

 <= /span>

P.12qua: The protocol MUST support a channel usage message = acknowledgement.<= /span>

 <= /span>

New O requirements (probably = best placed following O13):<= /span>

 <= /span>

O.13bis:  According to local regulatory policy, after connecting to a master device'sradio network a slave device MAY inform the master device of the = actual channel usage. The slave MUST include parameters required by local = regulatory policy, e.g. device ID, manufacturer's serial number, channel usage and = power levelinformation.<= /span>

 <= /span>

O.13ter:  According to local regulatory policy, a master device MAY inform the = database of the actual channel usage of the master and its slaves. The master = MUST include parameters required by local regulatory policy, e.g. device ID, manufacturer's serial number, channel usage and power level information = of the master and its slaves.<= /span>

 <= /span>

New steps could be introduced = into one or more use cases to cover these Ofcom requirements, e.g. new steps 6bis = and 9bis in the hotspot use case at 4.2.1:<= /span>

 <= /span>

6bis. Prior to initiating transmission, if required by local regulation, the master/AP informs the database of the channel and power level it has = chosen. This is repeated for each slave that associated with the = master.<= /span>

 <= /span>

9bis. Prior to initiating transmission, if required by local regulation, the = slave informs the master/AP of the channel and power level it has chosen, and themaster/AP relays this information to the database. = <= /span>

 <= /span>

- end of new text = -<= /span>

 <= /span>

For information, for those not = accessing the url in the first paragraph of this email, the full Ofcom = requirements leading to this new PAWS text are as = follows:<= /span>

 <= /span>

3.18 After receiving = instructions from a WSDB in relation to the maximum permitted EIRPs over the DTT channels, = and prior to initiating transmissions within the UHF TV band, a master WSD mustcommunicate to the WSDB the following = information:<= /span>

3.18.1 The lower and upper frequency boundaries13 of the in-block = emissions of the master WSD, and those of the in-block emissions of its associated = slaves. A lower frequency will be specified as (470 + 8k + 0.2n) MHz, with the corresponding upper frequency specified as (470 + 8k + 0.2m) MHz, where = 0 =A1=DC k =A1=DC 39, 0 =A1=DC n =A1=DC 39, 1 =A1=DC m =A1=DC 40, and n < = m.<= /span>

3.18.2 The maximum in-block EIRP spectral densities (in dBm/(0.2 MHz)) that the = masterWSD, and its associated slaves, actually radiate between each reported lower frequency boundary and its corresponding upper frequency = boundary.<= /span>

 <= /span>

Footnote 13 = states:<= /span>

The use of upper and lower = frequency boundaries (defined over a 200 kHz raster) allows a WSDB to collect more granular information with regards to the usage of the frequency resource bynarrowband WSD technologies. The upper and lower frequencies of a = boundary pair do notstraddle a DTT channel boundary. Note that a WSD may transmit = over multiple, non-contiguous, whole DTT channels or fractions of DTT = channels.<= /span>

 <= /span>

3.19 A master WSD must be able = to receive the following information14 from a = WSDB:<= /span>

<snip>= <= /span>

3.19.8     [An acknowledgement from the WSDB, in the context of 3.18, that the = reported information on the DTT channels and EIRP spectral densities actually = used by the master and slave WSDs were received successfully by the = WSDB18].<= /span>

 <= /span>

Footnote 14 = states:<= /span>

14 While the communication of = some of this information from a WSDB to a master WSD is optional, master WSDs = must be able to receive and interpret these.<= /span>

 <= /span>

Footnote 18 = states:<= /span>

18 This forms part of a = handshake protocol and may be an area where industry could harmonise without the = need for an explicit requirement in the = regulations.<= /span>

 <= /span>

Regards<= /span>

 <= /span>

Andy<= font color=3Dblack><= /span>

 <= /span>

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] = On Behalf Of Gabor.Bajko@nokia.com
Sent: 05 March 2012 = 19:46
To: paws@ietf.org
Subject: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03= <= /span>

 

The authors of the use cases and requirements draft have just posted a new version of the draft and = indicated that there are no unresolved comments/issues they are aware = of.=

 

Therefore, I'd like to initiate a = WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paw= s-problem-stmt-usecases-rqmts-03.txt<= /u3:p>

 

Please review the draft and send yourcomments to the list by March 20th, = 2012.

 

If you review the draft and have = no comments, send a note to the list that the draft is good as it is, we = need these notes as much as we need the actual = comments.<= /span>

 

Thanks, = Gabor

 

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

------=_NextPart_000_0194_01CCFD35.33883400-- From JuanCarlos.Zuniga@InterDigital.com Thu Mar 8 12:26:03 2012 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 65E8B21F8649 for ; Thu, 8 Mar 2012 12:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[AWL=-0.928, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, 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 9U9jVQQqLRgd for ; Thu, 8 Mar 2012 12:26:01 -0800 (PST) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2459421F8648 for ; Thu, 8 Mar 2012 12:26:01 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 15:26:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Mar 2012 15:25:58 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting Thread-Index: Acz9V7Iqh7bz3L85Sfm6YmPS/OxBfgAAXEPgAAQCfZA= References: <4F58F78B.3030501@joelhalpern.com> From: "Zuniga, Juan Carlos" To: "Gerald Chouinard" , "Joel M. Halpern" , X-OriginalArrivalTime: 08 Mar 2012 20:26:00.0113 (UTC) FILETIME=[ACE73A10:01CCFD69] Cc: paws@ietf.org, presnick@qualcomm.com, johnny.dixon@bt.com, chris.cheeseman@bt.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 20:26:03 -0000 So, from Gerald and Andy's comments, it seems like from the point of = view of (at least) two regulatory entities it is important for the = protocol to allow communicating back to the WSDB/coexistence manager the = actual channel usage after the first query is made. This is to me a very clear requirement.=20 The actual messages/IEs that would carry this information should be = discussed as part of the solution document, and not the requirements. JC > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of > Gerald Chouinard > Sent: Thursday, March 08, 2012 1:59 PM > To: 'Joel M. Halpern'; scott.probasco@nokia.com > Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; > chris.cheeseman@bt.com > Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- > rqmts-03:channel reporting >=20 > Joel, Scott, >=20 > Interesting discussion! See my comments in line below. >=20 > Gerald >=20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of > Joel > M. Halpern > Sent: Thursday, 08 March, 2012 13:17 > To: scott.probasco@nokia.com > Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; > chris.cheeseman@bt.com > Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- > rqmts-03: > channel reporting >=20 > So why won't the device simply say "I will use all of this?" > [GC] This would defeat the purpose of the acknowledgement message. > After all, that way it needs to do less work with the database. And = it > can change frequencies when it wants. > Given that the stated goal of the Ofcom requriement was to be able to > analyze interference effects, it seems that this will not actually = lead > to them getting what they want, even if it does comply with the > regulations. > [GC] You got it. This would be useless for spectrum regulators. One > should > realize that, from the spectrum regulator's point of view, the second > and > third messages could be iterated upon to optimize the spectrum use. > Knowing > what channels the systems in an area are using, the spectrum = regulators > and/or other entities such as those taking care of coexistence could > use the > database in near-real-time to iterate on the two last messages to > reduce the > range of channels that some systems may use once they know precisely > what > channels are being used in the area. The PAWS protocol would carry the > information back and forth but would not be involved in such spectrum > use > optimization. >=20 > Yours, > joel >=20 > On 3/8/2012 1:09 PM, scott.probasco@nokia.com wrote: > > Hi Peter, > > > > Answers below. > > > > Kind Regards, > > Scott > > > > On 3/8/12 11:39 AM, "ext Peter Saint-Andre" > wrote: > > > >> Hi Scott, I have two clarifying questions: > >> > >> 1. Does the device know, when it receives the channel response, > which > >> channel it will actually use? > > Scott->This is all new and I am not aware of any existing > implementations. > > I would argue that the device must decide what channel(s) it will = use > when > > it receives the channel response. > [GC] Agree with Scott but this is only a portion of the = considerations. > If a > device was to operate on its own, this would be true but a > communication > device usually implies at least 2 devices to communicate. Hence, the > choice > of the channel to be used will need to be negotiated between the two > devices > before a choice can be made. The chosen channel will belong to the = set > of > available channels that is common to both devices. Remember that some > channels may be available at one device and not at the other because = of > their geolocation or other reason. Extending this concept to a star > network > topology, the channel that will be selected by this network will have > to > belong to the set of channels that are available to all devices. Each > device > will not be able to decide by itself which channel it wants to use. >=20 > This is why in such a star topology, it makes sense that the slave > devices > to a base station or access point be represented by the base station > acting > as the master on their behalf to query the database and receive the > list of > available channels (and/or maximum EIRP per channel). It is then the > responsibility of the base station to identify the set of available > channels > that is common for itself and all its slaves to decide on the channel > that > the network will use. As you can see, in this case, there is no need > for > each slave to receive its list of available channels. On its own, it > would > not know what to do with it. The only thing that needs to be sent from > the > master device to its slaves is the resulting operating channel. >=20 > I a more sophisticated operation, the master device may add one or a > few > backup channels extracted from the common set of available channel to > the > message going to its slave so that if a change in channel availability > occurs, an instantaneous switch to the next backup channel can be made > without any further signaling, thus providing for a channel switch = that > is > transparent to the user. It is the scheme that has been included in = the > IEEE > 802.22-2011 Standard. This is why I don't believe that PAWS should get > involved in defining this signaling between the base station and its > slaves > devices. > >> > >> 2. If the device then uses another channel or a different channel, > does > >> it need to report that change to the database? > > Scott->My interpretation of section 3.18 is that the device can only > > transmit within the upper& lower frequencies returned in the > > acknowledgment. I do not (quickly) find any reference in the > requirements > > to changing channels. Thus operationally it could be that the = channel > > request process must be repeated before the device can use a > different > > channel (frequencies). > [GC] If the process involves 2 messages, then, the device and its > associated > devices could change channels at will as long as all these channels > belong > to the set of available channel. However, if the third message is > added, it > would make sense that the master device reports to the database any > channel > change that would occur to the database, otherwise, the status of the > spectrum occupation would be wrong at any moment and would be useless > for > the purpose of any spectrum usage optimization such as coexistence. > >> > >> Thanks! > >> > >> Peter > >> > >> On 3/8/12 10:17 AM, scott.probasco@nokia.com wrote: > >>> Hi, > >>> > >>> The point from Brian is very relevant: > >>> > >>> Channel request > >>> Channel response > >>> Channel acknowledgement > >>> > >>> What Ofcom does with the information in the acknowledgement does > not > >>> matter. As the regulator in UK, they write rules that must be > followed > >>> in > >>> order to operate a whitespace radio in the UK. I believe the scope > of > >>> the > >>> WG must be focused on a working solution. If this is simple = channel > >>> request& response in one regulator's domain, PAWS can support > this. If > >>> it > >>> means a channel request, response and acknowledgement in another > >>> regulator's domain, PAWS can support this. As a participating > member of > >>> the work group, I believe the scope should be basic working > solution, > >>> not > >>> limited to a specific number of messages. > >>> > >>> Kind Regards, > >>> Scott > >>> > >>> > >>> > >>> On 3/8/12 11:11 AM, "ext Zuniga, Juan Carlos" > >>> wrote: > >>> > >>>> Peter, Nancy, > >>>> > >>>> I agree should design a protocol with the best of our current > >>>> knowledge, > >>>> and that should be accounting for all the known regulations at > present > >>>> time. We should not limit the scope with the purpose of designing > a > >>>> protocol 'faster'. Our goal is not only to design a WSDB = protocol. > Our > >>>> goal is to design a WSDB protocol that is USEFUL to the = community. > >>>> > >>>> The charter does state that > >>>> > >>>> "...the group should also reach out to other potential > >>>> "customers" for a white space database access method and consider > input > >>> >from regulatory entities that are involved in the specification = of > the > >>>> rules for secondary use of spectrum in specific radio bands. " > >>>> > >>>> I think that is exactly what we are doing now. > >>>> > >>>> Regarding whether the types of requirements belong to #1 or #2, I > >>>> believe > >>>> it is more of #1 type, as the information to be exchanged would = be > >>>> known > >>>> after the initial query/response. > >>>> > >>>> If we know it today, I see no reason why we should not work on it > in > >>>> the > >>>> first phase of the work. > >>>> > >>>> Regards, > >>>> > >>>> Juan Carlos > >>>> > >>>>> -----Original Message----- > >>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On > Behalf > >>>>> Of > >>>>> Peter Saint-Andre > >>>>> Sent: Thursday, March 08, 2012 11:59 AM > >>>>> To: Nancy Bravin > >>>>> Cc: paws@ietf.org; johnny.dixon@bt.com; chris.cheeseman@bt.com; > Pete > >>>>> Resnick > >>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- > usecases- > >>>>> rqmts-03: channel reporting > >>>>> > >>>>> Hi Nancy, > >>>>> > >>>>> You are absolutely right that different locales will have > different > >>>>> rules and requirements. We need to understand those, and work to > >>>>> address > >>>>> them if possible (although we don't necessarily need to address > them > >>>>> all > >>>>> at the same time). I see several kinds of requirements: > >>>>> > >>>>> 1. Some requirements might lead to features beyond the > query/response > >>>>> protocol we've envisioned so far. One example might be real-time > >>>>> reporting about the channels that a device is actually using. In > my > >>>>> opinion, it would be best to handle those in the next phase of > work, > >>>>> because as far as I can see they are outside the scope of our > charter. > >>>>> > >>>>> 2. Some requirements might be handled through by defining > additional > >>>>> fields that can be included in the query or response. We > definitely > >>>>> planned for that when working on the charter with the IESG: > >>>>> > >>>>> In addition, the particular > >>>>> data exchanged between a device and a database might depend = on > the > >>>>> ranges of radio spectrum that are to be used, the = requirements > of > >>>>> the > >>>>> database operators and their governing regulations, and other > >>>>> factors. > >>>>> Therefore, the database access method and the query/response > data > >>>>> formats that are exchanged using that method need to be > designed > for > >>>>> extensibility rather than being tied to any specific = spectrum, > >>>>> country, or phy/mac/air interface. > >>>>> > >>>>> It's unclear to me right now if the Ofcom requirement fits into > #1 or > >>>>> #2, which is why we're having this discussion. :) > >>>>> > >>>>> Peter > >>>>> > >>>>> On 3/7/12 8:17 PM, Nancy Bravin wrote: > >>>>>> Peter and all, > >>>>>> > >>>>>> I agree that it is important to revisit now, so that in the > future, > >>>>>> it will be easy to align things in their proper place. Every > country > >>>>>> may have different regulations, spectrum, policy and what > >>>>>> responsibility is in the domain of the system, and what comes > under > >>>>>> the PAWS charter is important. Maybe some separation might be > >>>>>> possible, and dividing and clarifying issues now will help in > the > >>>>>> future. Certainly it seems that the FCC may change some rules, > and > >>>>>> we know that Ofcom is not yet finished with their regulations. > Canada > >>>>>> has their own, and other countries are working on this as well. > Just > >>>>>> a thought...Sharing is a realistic goal...as is off loading... > Or you > >>>>>> slim line and every 6 months decide what to incorporate in the > >>>>>> protocol based on new information, new ideas, new innovation = new > >>>>>> regulations and maybe spend more time than you could if > addressed > >>>>>> now. > >>>>>> > >>>>>> That way you leave the door open and outside of referencing = what > is > >>>>>> known today, by referencing regulations i.e. Ofcom, FCC, > Industry > >>>>>> Canada etc as of XX-XX-XXXX date. Out of scope not something we > know > >>>>>> enough about to say at this point, In my opinion. > >>>>>> > >>>>>> My 2 cents.. > >>>>>> > >>>>>> Sincerely, Nancy > >>>>>> > >>>>>> On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> As your responsible Area Director (until March 28, when Pete > >>>>>>> Resnick will take over from me), I have reviewed this thread. > >>>>>>> > >>>>>>> In my opinion (I am happy to be proven wrong), this new > requirement > >>>>>>> goes beyond what the charter defined as the scope of this > working > >>>>>>> group, which was to enable a device to discover the white = space > >>>>>>> available to it in its current location. Reporting usage back > to > >>>>>>> the database is simply not mentioned in the charter. > >>>>>>> > >>>>>>> Earlier in this thread, Andy Sago wrote: > >>>>>>> > >>>>>>> There's no language I can find in the charter that explicitly > puts > >>>>>>> this out of scope. > >>>>>>> > >>>>>>> An IETF charter defines what the working group shall work on. > Many > >>>>>>> interesting features could be developed here. However, it is > not > >>>>>>> the job of the charter to mention explicitly that each of = those > >>>>>>> interesting features is out of scope. > >>>>>>> > >>>>>>> The charter does say: > >>>>>>> > >>>>>>> Once the device learns of the available white space (e.g., in = a > TV > >>>>>>> white space implementation, the list of available channels at > that > >>>>>>> location), it can then select one of the bands from the list > and > >>>>>>> begin to transmit and receive on the selected band. > >>>>>>> > >>>>>>> This text might have assumed that no further communication or > >>>>>>> authorization was required in order to select one of the bands > from > >>>>>>> the list and then transmit/receive. Perhaps that assumption = was > >>>>>>> mistaken. If so, it would be good to have a discussion about > that, > >>>>>>> so we can determine if we need to revisit the assumptions we > made > >>>>>>> early on. If in fact we made some faulty or limited > assumptions, > >>>>>>> then let's get that out in the open. > >>>>>>> > >>>>>>> Peter > >>>>>>> > >>>>>>> On 3/7/12 9:40 AM, Rosen, Brian wrote: > >>>>>>>> I'd also suggest that our > >>>>>>>> charter limitation is really support for sharing of = whitespace > by > >>>>>>>> whitespace devices. Reporting what you use is not sharing, > it's > >>>>>>>> just data gathering. > >>>>>>>> > >>>>>>>> The point of excluding sharing was to eliminate the > complexities > >>>>>>>> of what constituted fairness, and what kinds of communication > >>>>>>>> might be needed between databases, where more than one could > >>>>>>>> supply available whitespace in a band. This doesn't have any > of > >>>>>>>> those issues, As long as it's just sending information, I > don't > >>>>>>>> have a problem. Once the database is supposed to do anything > >>>>>>>> with it that involves changing what spectrum it reports, then > I > >>>>>>>> think we cross the line. > >>>>>>>> > >>>>>>>> Brian > >>>>>>>> > >>>>>>>> On Mar 6, 2012, at 12:28 PM, > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> Joel > >>>>>>>>> > >>>>>>>>> Indeed, the regulator has not described the process or > provided > >>>>>>>>> a flow diagram, so there may be some wrinkles, but we need = to > >>>>>>>>> provide for their intent. To answer your question, the > channels > >>>>>>>>> that the master will use are sent in a separate message > >>>>>>>>> (described in P.12 ter), that occurs after the master > receives > >>>>>>>>> the response to its channel request, but before the master > can > >>>>>>>>> transmit. At this point, it knows what channels are > available, > >>>>>>>>> and which one it will use. As far as the slaves are > concerned, > >>>>>>>>> as they associate, the master will need to gather their > details > >>>>>>>>> and send further channel usage messages to the database on > >>>>>>>>> their behalf. > >>>>>>>>> > >>>>>>>>> Regards > >>>>>>>>> > >>>>>>>>> Andy > >>>>>>>>> > >>>>>>>>> -----Original Message----- From: paws-bounces@ietf.org > >>>>>>>>> [mailto:paws-bounces@ietf.org] On Behalf Of Joel M. Halpern > >>>>>>>>> Sent: 06 March 2012 17:05 To: scott.probasco@nokia.com Cc: > >>>>>>>>> paws@ietf.org; Cheeseman,CJ,Chris,COD R; Dixon,JS,Johnny,COD > R > >>>>>>>>> Subject: Re: [paws] WGLC for > >>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel > >>>>>>>>> reporting > >>>>>>>>> > >>>>>>>>> Ahh. I think I see where the request and my understanding > >>>>>>>>> divurge. If the idea here is that the master must provide, = in > >>>>>>>>> the request, an indication of what channels it expects to > use, > >>>>>>>>> I can at least understand that. I will return to technical > >>>>>>>>> concerns in a moment. > >>>>>>>>> > >>>>>>>>> However, when you say "provide channel usage information, in > >>>>>>>>> order to evaluate interference", what that says to me is > >>>>>>>>> providing, during operation, information as to what channels > >>>>>>>>> are being used, and at what power levels. That is what = would > >>>>>>>>> be needed to analyze actual interference effects. And that = is > >>>>>>>>> out of scope as I understand our scope. > >>>>>>>>> > >>>>>>>>> I do see a technical difficulty with having the master > provide, > >>>>>>>>> as part of either registering or requesting spectrum > >>>>>>>>> information, what channels it intends to use. It doesn;t > know > >>>>>>>>> what channels it intends to use. It intends to use some > number > >>>>>>>>> of available channels. It will figure out which ones when = it > >>>>>>>>> is told what is available. How can it send that information > in > >>>>>>>>> the request? > >>>>>>>>> > >>>>>>>>> Yours, Joel > >>>>>>>>> > >>>>>>>>> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: > >>>>>>>>>> Hi, > >>>>>>>>>> > >>>>>>>>>> There is a similarity here with device ID. In context of > PAWS > >>>>>>>>>> we are not concerned with why a device ID is required by a > >>>>>>>>>> regulator, we accept it is a requirement from a regulator > and > >>>>>>>>>> include it to the protocol. Ofcom identifies in 3.18& = 3.19 > >>>>>>>>>> that channel usage information is required and thus we need > >>>>>>>>>> to include this information. Since the master must provide > >>>>>>>>>> this information prior to transmitting, PAWS will not > >>>>>>>>>> function in the UK without this information and thus I > >>>>>>>>>> believe channel usage information is integral to the = channel > >>>>>>>>>> request& response messaging. > >>>>>>>>>> > >>>>>>>>>> Kind Regards, Scott > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On 3/6/12 10:30 AM, "ext Joel M. > >>>>>>>>>> Halpern" wrote: > >>>>>>>>>> > >>>>>>>>>>> I would draw a distinction. Ofcom regulations about > >>>>>>>>>>> whitespace requests are very much relevant. Ofcom > >>>>>>>>>>> regulations about notification of dynamic behavior (which > >>>>>>>>>>> spectrum is being used) are not in scope as I understand > >>>>>>>>>>> the earlier discussions, particularly the chartering > >>>>>>>>>>> discussions. > >>>>>>>>>>> > >>>>>>>>>>> Yours, Joel > >>>>>>>>>>> > >>>>>>>>>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> The ofcom requirements are very much relevant to the > >>>>>>>>>>>> scope of the PAWS WG. The only other regulatory > >>>>>>>>>>>> requirements that we have today is the FCC. Ofcom > >>>>>>>>>>>> requirements are a good addition to the set. > >>>>>>>>>>>> > >>>>>>>>>>>> -Raj > >>>>>>>>>>>> > >>>>>>>>>>>> On 3/6/12 10:03 AM, "ext > >>>>>>>>>>>> andy.sago@bt.com" wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> Hi Joel > >>>>>>>>>>>>> > >>>>>>>>>>>>> There's no language I can find in the charter that > >>>>>>>>>>>>> explicitly puts this out of scope. On the other hand, > >>>>>>>>>>>>> the charter says that the group will "consider input > >>>>>>>>>>>>> from regulatory entities", and this is one of the > >>>>>>>>>>>>> requirements from Ofcom that they have just published. > >>>>>>>>>>>>> The protocol will be worthless for the UK if it omits > >>>>>>>>>>>>> some requirements. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Regards > >>>>>>>>>>>>> > >>>>>>>>>>>>> Andy > >>>>>>>>>>>>> > >>>>>>>>>>>>> -----Original Message----- From: Joel M. Halpern > >>>>>>>>>>>>> [mailto:jmh@joelhalpern.com] Sent: 06 March 2012 15:53 > >>>>>>>>>>>>> To: Sago,AJ,Andy,COD R Cc: paws@ietf.org; > >>>>>>>>>>>>> Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for > >>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel > >>>>>>>>>>>>> reporting > >>>>>>>>>>>>> > >>>>>>>>>>>>> As I understand, the information you are asking for is > >>>>>>>>>>>>> explicitly out of scope for the working group. Yours, > >>>>>>>>>>>>> Joel > >>>>>>>>>>>>> > >>>>>>>>>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: > >>>>>>>>>>>>>> All > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Comparing the draft with the Ofcom requirements at > >>>>>>>>>>>>>> http://www.cept.org/Documents/se- > >>>>> 43/4161/SE43(12)Info03_Draft-UK-r > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>> egul > >>>>>>>>>>>>>> atory-requirements-for-white-space-devices-in-the-UHF- > TV- > >>>>> band, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>> I believe the WG draft is deficient in the area of reporting > >>>>>>>>>>>>>> frequencies and powers actually used by masters and > >>>>>>>>>>>>>> slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom > >>>>>>>>>>>>>> intends to collect this data to assesses the impact > >>>>>>>>>>>>>> of aggregate interference into other services. It > >>>>>>>>>>>>>> would also provide usage information (frequency in > >>>>>>>>>>>>>> use) that would inform the operation of a kill switch > >>>>>>>>>>>>>> capability. I suggest this deficiency can be remedied > >>>>>>>>>>>>>> with the following changes: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> New P requirements (probably best placed following > >>>>>>>>>>>>>> P.12): > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> P.12bis: The protocol MUST support a channel usage > >>>>>>>>>>>>>> message from the slave device to the master device. > >>>>>>>>>>>>>> The channel usage message MUST include parameters as > >>>>>>>>>>>>>> required by local regulatory requirement. These > >>>>>>>>>>>>>> parameters MAY include device ID, manufacturer's > >>>>>>>>>>>>>> serial number, channel usage and power level > >>>>>>>>>>>>>> information. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> P.12ter: The protocol MUST support a channel usage > >>>>>>>>>>>>>> message from the master device to the database. The > >>>>>>>>>>>>>> channel usage message MUST include parameters as > >>>>>>>>>>>>>> required by local regulatory requirement for the > >>>>>>>>>>>>>> master and its associated slaves. These parameters > >>>>>>>>>>>>>> MAY include device ID, manufacturer's serial number, > >>>>>>>>>>>>>> channel usage and power level information. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> P.12qua: The protocol MUST support a channel usage > >>>>>>>>>>>>>> message acknowledgement. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> New O requirements (probably best placed following > >>>>>>>>>>>>>> O13): > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> O.13bis: According to local regulatory policy, after > >>>>>>>>>>>>>> connecting to a master device's radio network a slave > >>>>>>>>>>>>>> device MAY inform the master device of the actual > >>>>>>>>>>>>>> channel usage. The slave MUST include parameters > >>>>>>>>>>>>>> required by local regulatory policy, e.g. device ID, > >>>>>>>>>>>>>> manufacturer's serial number, channel usage and power > >>>>>>>>>>>>>> level information. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> O.13ter: According to local regulatory policy, a > >>>>>>>>>>>>>> master device MAY inform the database of the actual > >>>>>>>>>>>>>> channel usage of the master and its slaves. The > >>>>>>>>>>>>>> master MUST include parameters required by local > >>>>>>>>>>>>>> regulatory policy, e.g. device ID, manufacturer's > >>>>>>>>>>>>>> serial number, channel usage and power level > >>>>>>>>>>>>>> information of the master and its slaves. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> New steps could be introduced into one or more use > >>>>>>>>>>>>>> cases to cover these Ofcom requirements, e.g. new > >>>>>>>>>>>>>> steps 6bis and 9bis in the hotspot use case at > >>>>>>>>>>>>>> 4.2.1: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 6bis. Prior to initiating transmission, if required > >>>>>>>>>>>>>> by local regulation, the master/AP informs the > >>>>>>>>>>>>>> database of the channel and power level it has > >>>>>>>>>>>>>> chosen. This is repeated for each slave that > >>>>>>>>>>>>>> associated with the master. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 9bis. Prior to initiating transmission, if required > >>>>>>>>>>>>>> by local regulation, the slave informs the master/AP > >>>>>>>>>>>>>> of the channel and power level it has chosen, and the > >>>>>>>>>>>>>> master/AP relays this information to the database. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> - end of new text - > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> For information, for those not accessing the url in > >>>>>>>>>>>>>> the first paragraph of this email, the full Ofcom > >>>>>>>>>>>>>> requirements leading to this new PAWS text are as > >>>>>>>>>>>>>> follows: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 3.18 After receiving instructions from a WSDB in > >>>>>>>>>>>>>> relation to the maximum permitted EIRPs over the DTT > >>>>>>>>>>>>>> channels, and prior to initiating transmissions > >>>>>>>>>>>>>> within the UHF TV band, a master WSD must communicate > >>>>>>>>>>>>>> to the WSDB the following information: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 3.18.1 The lower and upper frequency boundaries^13 of > >>>>>>>>>>>>>> the in-block emissions of the master WSD, and those > >>>>>>>>>>>>>> of the in-block emissions of its associated slaves. A > >>>>>>>>>>>>>> lower frequency will be specified as (470 + 8k + > >>>>>>>>>>>>>> 0.2n) MHz, with the corresponding upper frequency > >>>>>>>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3=AE4 k = 3=AE4 > >>>>>>>>>>>>>> 39, 0 3=AE4 n 3=AE4 39, 1 3=AE4 m 3=AE4 40, and n< = m. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 3.18.2 The maximum in-block EIRP spectral densities > >>>>>>>>>>>>>> (in dBm/(0.2 MHz)) that the master WSD, and its > >>>>>>>>>>>>>> associated slaves, actually radiate between each > >>>>>>>>>>>>>> reported lower frequency boundary and its > >>>>>>>>>>>>>> corresponding upper frequency boundary. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Footnote 13 states: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> The use of upper and lower frequency boundaries > >>>>>>>>>>>>>> (defined over a 200 kHz raster) allows a WSDB to > >>>>>>>>>>>>>> collect more granular information with regards to the > >>>>>>>>>>>>>> usage of the frequency resource by narrowband WSD > >>>>>>>>>>>>>> technologies. The upper and lower frequencies of a > >>>>>>>>>>>>>> boundary pair do not straddle a DTT channel boundary. > >>>>>>>>>>>>>> Note that a WSD may transmit over multiple, > >>>>>>>>>>>>>> non-contiguous, whole DTT channels or fractions of > >>>>>>>>>>>>>> DTT channels. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 3.19 A master WSD must be able to receive the > >>>>>>>>>>>>>> following information^14 from a WSDB: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in the > >>>>>>>>>>>>>> context of 3.18, that the reported information on the > >>>>>>>>>>>>>> DTT channels and EIRP spectral densities actually > >>>>>>>>>>>>>> used by the master and slave WSDs were received > >>>>>>>>>>>>>> successfully by the WSDB^18 ]. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Footnote 14 states: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 14 While the communication of some of this > >>>>>>>>>>>>>> information from a WSDB to a master WSD is optional, > >>>>>>>>>>>>>> master WSDs must be able to receive and interpret > >>>>>>>>>>>>>> these. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Footnote 18 states: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 18 This forms part of a handshake protocol and may be > >>>>>>>>>>>>>> an area where industry could harmonise without the > >>>>>>>>>>>>>> need for an explicit requirement in the regulations. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Regards > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Andy > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> *From:*paws-bounces@ietf.org > >>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] *On Behalf Of > >>>>>>>>>>>>>> *Gabor.Bajko@nokia.com *Sent:* 05 March 2012 19:46 > >>>>>>>>>>>>>> *To:* paws@ietf.org *Subject:* [paws] WGLC for > >>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> The authors of the use cases and requirements draft > >>>>>>>>>>>>>> have just posted a new version of the draft and > >>>>>>>>>>>>>> indicated that there are no unresolved > >>>>>>>>>>>>>> comments/issues they are aware of. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Therefore, I'd like to initiate a WG Last Call for > >>>>>>>>>>>>>> comments on > >>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-paws- > problem- > >>>>> stmt-u > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>> seca > >>>>>>>>>>>>>> ses-rqmts-03.txt > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Please review the draft and send your comments to the > >>>>>>>>>>>>>> list by March 20th, 2012. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> If you review the draft and have no comments, send a > >>>>>>>>>>>>>> note to the list that the draft is good as it is, we > >>>>>>>>>>>>>> need these notes as much as we need the actual > >>>>>>>>>>>>>> comments. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks, Gabor > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > > > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > https://www.ietf.org/mailman/listinfo/paws > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From Basavaraj.Patil@nokia.com Thu Mar 8 12:32:51 2012 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 4159121E8032 for ; Thu, 8 Mar 2012 12:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.796 X-Spam-Level: X-Spam-Status: No, score=-103.796 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4, 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 1GhGUTFVK7j0 for ; Thu, 8 Mar 2012 12:32:48 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6821C21E801C for ; Thu, 8 Mar 2012 12:32:48 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q28KWegw015029; Thu, 8 Mar 2012 22:32:40 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.23]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 22:32:39 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.150]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.01.0355.003; Thu, 8 Mar 2012 21:32:38 +0100 From: To: , , , Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting Thread-Index: AQHM/WqaGADtHyPWsUCiCGl6fDpM1g== Date: Thu, 8 Mar 2012 20:32:38 +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.14.0.111121 x-originating-ip: [172.19.59.135] Content-Type: text/plain; charset="iso-8859-2" Content-ID: <5202094B760B544F9FE97934244EBDD2@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Mar 2012 20:32:39.0817 (UTC) FILETIME=[9B253790:01CCFD6A] X-Nokia-AV: Clean Cc: paws@ietf.org, presnick@qualcomm.com, johnny.dixon@bt.com, chris.cheeseman@bt.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 20:32:51 -0000 Hi JC, Where/why did the coexistence manager come into the picture? Your comment about "communicating back to the WSDB/coexistence manager" may result in further misunderstanding. If we simply stick to to WSDB I think we are okay. -Raj On 3/8/12 2:25 PM, "ext Zuniga, Juan Carlos" wrote: >So, from Gerald and Andy's comments, it seems like from the point of view >of (at least) two regulatory entities it is important for the protocol to >allow communicating back to the WSDB/coexistence manager the actual >channel usage after the first query is made. > >This is to me a very clear requirement. > >The actual messages/IEs that would carry this information should be >discussed as part of the solution document, and not the requirements. > >JC > >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >> Gerald Chouinard >> Sent: Thursday, March 08, 2012 1:59 PM >> To: 'Joel M. Halpern'; scott.probasco@nokia.com >> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >> chris.cheeseman@bt.com >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >> rqmts-03:channel reporting >>=20 >> Joel, Scott, >>=20 >> Interesting discussion! See my comments in line below. >>=20 >> Gerald >>=20 >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >> Joel >> M. Halpern >> Sent: Thursday, 08 March, 2012 13:17 >> To: scott.probasco@nokia.com >> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >> chris.cheeseman@bt.com >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >> rqmts-03: >> channel reporting >>=20 >> So why won't the device simply say "I will use all of this?" >> [GC] This would defeat the purpose of the acknowledgement message. >> After all, that way it needs to do less work with the database. And it >> can change frequencies when it wants. >> Given that the stated goal of the Ofcom requriement was to be able to >> analyze interference effects, it seems that this will not actually lead >> to them getting what they want, even if it does comply with the >> regulations. >> [GC] You got it. This would be useless for spectrum regulators. One >> should >> realize that, from the spectrum regulator's point of view, the second >> and >> third messages could be iterated upon to optimize the spectrum use. >> Knowing >> what channels the systems in an area are using, the spectrum regulators >> and/or other entities such as those taking care of coexistence could >> use the >> database in near-real-time to iterate on the two last messages to >> reduce the >> range of channels that some systems may use once they know precisely >> what >> channels are being used in the area. The PAWS protocol would carry the >> information back and forth but would not be involved in such spectrum >> use >> optimization. >>=20 >> Yours, >> joel >>=20 >> On 3/8/2012 1:09 PM, scott.probasco@nokia.com wrote: >> > Hi Peter, >> > >> > Answers below. >> > >> > Kind Regards, >> > Scott >> > >> > On 3/8/12 11:39 AM, "ext Peter Saint-Andre" >> wrote: >> > >> >> Hi Scott, I have two clarifying questions: >> >> >> >> 1. Does the device know, when it receives the channel response, >> which >> >> channel it will actually use? >> > Scott->This is all new and I am not aware of any existing >> implementations. >> > I would argue that the device must decide what channel(s) it will use >> when >> > it receives the channel response. >> [GC] Agree with Scott but this is only a portion of the considerations. >> If a >> device was to operate on its own, this would be true but a >> communication >> device usually implies at least 2 devices to communicate. Hence, the >> choice >> of the channel to be used will need to be negotiated between the two >> devices >> before a choice can be made. The chosen channel will belong to the set >> of >> available channels that is common to both devices. Remember that some >> channels may be available at one device and not at the other because of >> their geolocation or other reason. Extending this concept to a star >> network >> topology, the channel that will be selected by this network will have >> to >> belong to the set of channels that are available to all devices. Each >> device >> will not be able to decide by itself which channel it wants to use. >>=20 >> This is why in such a star topology, it makes sense that the slave >> devices >> to a base station or access point be represented by the base station >> acting >> as the master on their behalf to query the database and receive the >> list of >> available channels (and/or maximum EIRP per channel). It is then the >> responsibility of the base station to identify the set of available >> channels >> that is common for itself and all its slaves to decide on the channel >> that >> the network will use. As you can see, in this case, there is no need >> for >> each slave to receive its list of available channels. On its own, it >> would >> not know what to do with it. The only thing that needs to be sent from >> the >> master device to its slaves is the resulting operating channel. >>=20 >> I a more sophisticated operation, the master device may add one or a >> few >> backup channels extracted from the common set of available channel to >> the >> message going to its slave so that if a change in channel availability >> occurs, an instantaneous switch to the next backup channel can be made >> without any further signaling, thus providing for a channel switch that >> is >> transparent to the user. It is the scheme that has been included in the >> IEEE >> 802.22-2011 Standard. This is why I don't believe that PAWS should get >> involved in defining this signaling between the base station and its >> slaves >> devices. >> >> >> >> 2. If the device then uses another channel or a different channel, >> does >> >> it need to report that change to the database? >> > Scott->My interpretation of section 3.18 is that the device can only >> > transmit within the upper& lower frequencies returned in the >> > acknowledgment. I do not (quickly) find any reference in the >> requirements >> > to changing channels. Thus operationally it could be that the channel >> > request process must be repeated before the device can use a >> different >> > channel (frequencies). >> [GC] If the process involves 2 messages, then, the device and its >> associated >> devices could change channels at will as long as all these channels >> belong >> to the set of available channel. However, if the third message is >> added, it >> would make sense that the master device reports to the database any >> channel >> change that would occur to the database, otherwise, the status of the >> spectrum occupation would be wrong at any moment and would be useless >> for >> the purpose of any spectrum usage optimization such as coexistence. >> >> >> >> Thanks! >> >> >> >> Peter >> >> >> >> On 3/8/12 10:17 AM, scott.probasco@nokia.com wrote: >> >>> Hi, >> >>> >> >>> The point from Brian is very relevant: >> >>> >> >>> Channel request >> >>> Channel response >> >>> Channel acknowledgement >> >>> >> >>> What Ofcom does with the information in the acknowledgement does >> not >> >>> matter. As the regulator in UK, they write rules that must be >> followed >> >>> in >> >>> order to operate a whitespace radio in the UK. I believe the scope >> of >> >>> the >> >>> WG must be focused on a working solution. If this is simple channel >> >>> request& response in one regulator's domain, PAWS can support >> this. If >> >>> it >> >>> means a channel request, response and acknowledgement in another >> >>> regulator's domain, PAWS can support this. As a participating >> member of >> >>> the work group, I believe the scope should be basic working >> solution, >> >>> not >> >>> limited to a specific number of messages. >> >>> >> >>> Kind Regards, >> >>> Scott >> >>> >> >>> >> >>> >> >>> On 3/8/12 11:11 AM, "ext Zuniga, Juan Carlos" >> >>> wrote: >> >>> >> >>>> Peter, Nancy, >> >>>> >> >>>> I agree should design a protocol with the best of our current >> >>>> knowledge, >> >>>> and that should be accounting for all the known regulations at >> present >> >>>> time. We should not limit the scope with the purpose of designing >> a >> >>>> protocol 'faster'. Our goal is not only to design a WSDB protocol. >> Our >> >>>> goal is to design a WSDB protocol that is USEFUL to the community. >> >>>> >> >>>> The charter does state that >> >>>> >> >>>> "...the group should also reach out to other potential >> >>>> "customers" for a white space database access method and consider >> input >> >>> >from regulatory entities that are involved in the specification of >> the >> >>>> rules for secondary use of spectrum in specific radio bands. " >> >>>> >> >>>> I think that is exactly what we are doing now. >> >>>> >> >>>> Regarding whether the types of requirements belong to #1 or #2, I >> >>>> believe >> >>>> it is more of #1 type, as the information to be exchanged would be >> >>>> known >> >>>> after the initial query/response. >> >>>> >> >>>> If we know it today, I see no reason why we should not work on it >> in >> >>>> the >> >>>> first phase of the work. >> >>>> >> >>>> Regards, >> >>>> >> >>>> Juan Carlos >> >>>> >> >>>>> -----Original Message----- >> >>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >> Behalf >> >>>>> Of >> >>>>> Peter Saint-Andre >> >>>>> Sent: Thursday, March 08, 2012 11:59 AM >> >>>>> To: Nancy Bravin >> >>>>> Cc: paws@ietf.org; johnny.dixon@bt.com; chris.cheeseman@bt.com; >> Pete >> >>>>> Resnick >> >>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- >> usecases- >> >>>>> rqmts-03: channel reporting >> >>>>> >> >>>>> Hi Nancy, >> >>>>> >> >>>>> You are absolutely right that different locales will have >> different >> >>>>> rules and requirements. We need to understand those, and work to >> >>>>> address >> >>>>> them if possible (although we don't necessarily need to address >> them >> >>>>> all >> >>>>> at the same time). I see several kinds of requirements: >> >>>>> >> >>>>> 1. Some requirements might lead to features beyond the >> query/response >> >>>>> protocol we've envisioned so far. One example might be real-time >> >>>>> reporting about the channels that a device is actually using. In >> my >> >>>>> opinion, it would be best to handle those in the next phase of >> work, >> >>>>> because as far as I can see they are outside the scope of our >> charter. >> >>>>> >> >>>>> 2. Some requirements might be handled through by defining >> additional >> >>>>> fields that can be included in the query or response. We >> definitely >> >>>>> planned for that when working on the charter with the IESG: >> >>>>> >> >>>>> In addition, the particular >> >>>>> data exchanged between a device and a database might depend on >> the >> >>>>> ranges of radio spectrum that are to be used, the requirements >> of >> >>>>> the >> >>>>> database operators and their governing regulations, and other >> >>>>> factors. >> >>>>> Therefore, the database access method and the query/response >> data >> >>>>> formats that are exchanged using that method need to be >> designed >> for >> >>>>> extensibility rather than being tied to any specific spectrum, >> >>>>> country, or phy/mac/air interface. >> >>>>> >> >>>>> It's unclear to me right now if the Ofcom requirement fits into >> #1 or >> >>>>> #2, which is why we're having this discussion. :) >> >>>>> >> >>>>> Peter >> >>>>> >> >>>>> On 3/7/12 8:17 PM, Nancy Bravin wrote: >> >>>>>> Peter and all, >> >>>>>> >> >>>>>> I agree that it is important to revisit now, so that in the >> future, >> >>>>>> it will be easy to align things in their proper place. Every >> country >> >>>>>> may have different regulations, spectrum, policy and what >> >>>>>> responsibility is in the domain of the system, and what comes >> under >> >>>>>> the PAWS charter is important. Maybe some separation might be >> >>>>>> possible, and dividing and clarifying issues now will help in >> the >> >>>>>> future. Certainly it seems that the FCC may change some rules, >> and >> >>>>>> we know that Ofcom is not yet finished with their regulations. >> Canada >> >>>>>> has their own, and other countries are working on this as well. >> Just >> >>>>>> a thought...Sharing is a realistic goal...as is off loading... >> Or you >> >>>>>> slim line and every 6 months decide what to incorporate in the >> >>>>>> protocol based on new information, new ideas, new innovation new >> >>>>>> regulations and maybe spend more time than you could if >> addressed >> >>>>>> now. >> >>>>>> >> >>>>>> That way you leave the door open and outside of referencing what >> is >> >>>>>> known today, by referencing regulations i.e. Ofcom, FCC, >> Industry >> >>>>>> Canada etc as of XX-XX-XXXX date. Out of scope not something we >> know >> >>>>>> enough about to say at this point, In my opinion. >> >>>>>> >> >>>>>> My 2 cents.. >> >>>>>> >> >>>>>> Sincerely, Nancy >> >>>>>> >> >>>>>> On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote: >> >>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> As your responsible Area Director (until March 28, when Pete >> >>>>>>> Resnick will take over from me), I have reviewed this thread. >> >>>>>>> >> >>>>>>> In my opinion (I am happy to be proven wrong), this new >> requirement >> >>>>>>> goes beyond what the charter defined as the scope of this >> working >> >>>>>>> group, which was to enable a device to discover the white space >> >>>>>>> available to it in its current location. Reporting usage back >> to >> >>>>>>> the database is simply not mentioned in the charter. >> >>>>>>> >> >>>>>>> Earlier in this thread, Andy Sago wrote: >> >>>>>>> >> >>>>>>> There's no language I can find in the charter that explicitly >> puts >> >>>>>>> this out of scope. >> >>>>>>> >> >>>>>>> An IETF charter defines what the working group shall work on. >> Many >> >>>>>>> interesting features could be developed here. However, it is >> not >> >>>>>>> the job of the charter to mention explicitly that each of those >> >>>>>>> interesting features is out of scope. >> >>>>>>> >> >>>>>>> The charter does say: >> >>>>>>> >> >>>>>>> Once the device learns of the available white space (e.g., in a >> TV >> >>>>>>> white space implementation, the list of available channels at >> that >> >>>>>>> location), it can then select one of the bands from the list >> and >> >>>>>>> begin to transmit and receive on the selected band. >> >>>>>>> >> >>>>>>> This text might have assumed that no further communication or >> >>>>>>> authorization was required in order to select one of the bands >> from >> >>>>>>> the list and then transmit/receive. Perhaps that assumption was >> >>>>>>> mistaken. If so, it would be good to have a discussion about >> that, >> >>>>>>> so we can determine if we need to revisit the assumptions we >> made >> >>>>>>> early on. If in fact we made some faulty or limited >> assumptions, >> >>>>>>> then let's get that out in the open. >> >>>>>>> >> >>>>>>> Peter >> >>>>>>> >> >>>>>>> On 3/7/12 9:40 AM, Rosen, Brian wrote: >> >>>>>>>> I'd also suggest that our >> >>>>>>>> charter limitation is really support for sharing of whitespace >> by >> >>>>>>>> whitespace devices. Reporting what you use is not sharing, >> it's >> >>>>>>>> just data gathering. >> >>>>>>>> >> >>>>>>>> The point of excluding sharing was to eliminate the >> complexities >> >>>>>>>> of what constituted fairness, and what kinds of communication >> >>>>>>>> might be needed between databases, where more than one could >> >>>>>>>> supply available whitespace in a band. This doesn't have any >> of >> >>>>>>>> those issues, As long as it's just sending information, I >> don't >> >>>>>>>> have a problem. Once the database is supposed to do anything >> >>>>>>>> with it that involves changing what spectrum it reports, then >> I >> >>>>>>>> think we cross the line. >> >>>>>>>> >> >>>>>>>> Brian >> >>>>>>>> >> >>>>>>>> On Mar 6, 2012, at 12:28 PM, >> >>>>>>>> wrote: >> >>>>>>>> >> >>>>>>>>> Joel >> >>>>>>>>> >> >>>>>>>>> Indeed, the regulator has not described the process or >> provided >> >>>>>>>>> a flow diagram, so there may be some wrinkles, but we need to >> >>>>>>>>> provide for their intent. To answer your question, the >> channels >> >>>>>>>>> that the master will use are sent in a separate message >> >>>>>>>>> (described in P.12 ter), that occurs after the master >> receives >> >>>>>>>>> the response to its channel request, but before the master >> can >> >>>>>>>>> transmit. At this point, it knows what channels are >> available, >> >>>>>>>>> and which one it will use. As far as the slaves are >> concerned, >> >>>>>>>>> as they associate, the master will need to gather their >> details >> >>>>>>>>> and send further channel usage messages to the database on >> >>>>>>>>> their behalf. >> >>>>>>>>> >> >>>>>>>>> Regards >> >>>>>>>>> >> >>>>>>>>> Andy >> >>>>>>>>> >> >>>>>>>>> -----Original Message----- From: paws-bounces@ietf.org >> >>>>>>>>> [mailto:paws-bounces@ietf.org] On Behalf Of Joel M. Halpern >> >>>>>>>>> Sent: 06 March 2012 17:05 To: scott.probasco@nokia.com Cc: >> >>>>>>>>> paws@ietf.org; Cheeseman,CJ,Chris,COD R; Dixon,JS,Johnny,COD >> R >> >>>>>>>>> Subject: Re: [paws] WGLC for >> >>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel >> >>>>>>>>> reporting >> >>>>>>>>> >> >>>>>>>>> Ahh. I think I see where the request and my understanding >> >>>>>>>>> divurge. If the idea here is that the master must provide, in >> >>>>>>>>> the request, an indication of what channels it expects to >> use, >> >>>>>>>>> I can at least understand that. I will return to technical >> >>>>>>>>> concerns in a moment. >> >>>>>>>>> >> >>>>>>>>> However, when you say "provide channel usage information, in >> >>>>>>>>> order to evaluate interference", what that says to me is >> >>>>>>>>> providing, during operation, information as to what channels >> >>>>>>>>> are being used, and at what power levels. That is what would >> >>>>>>>>> be needed to analyze actual interference effects. And that is >> >>>>>>>>> out of scope as I understand our scope. >> >>>>>>>>> >> >>>>>>>>> I do see a technical difficulty with having the master >> provide, >> >>>>>>>>> as part of either registering or requesting spectrum >> >>>>>>>>> information, what channels it intends to use. It doesn;t >> know >> >>>>>>>>> what channels it intends to use. It intends to use some >> number >> >>>>>>>>> of available channels. It will figure out which ones when it >> >>>>>>>>> is told what is available. How can it send that information >> in >> >>>>>>>>> the request? >> >>>>>>>>> >> >>>>>>>>> Yours, Joel >> >>>>>>>>> >> >>>>>>>>> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: >> >>>>>>>>>> Hi, >> >>>>>>>>>> >> >>>>>>>>>> There is a similarity here with device ID. In context of >> PAWS >> >>>>>>>>>> we are not concerned with why a device ID is required by a >> >>>>>>>>>> regulator, we accept it is a requirement from a regulator >> and >> >>>>>>>>>> include it to the protocol. Ofcom identifies in 3.18& 3.19 >> >>>>>>>>>> that channel usage information is required and thus we need >> >>>>>>>>>> to include this information. Since the master must provide >> >>>>>>>>>> this information prior to transmitting, PAWS will not >> >>>>>>>>>> function in the UK without this information and thus I >> >>>>>>>>>> believe channel usage information is integral to the channel >> >>>>>>>>>> request& response messaging. >> >>>>>>>>>> >> >>>>>>>>>> Kind Regards, Scott >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> On 3/6/12 10:30 AM, "ext Joel M. >> >>>>>>>>>> Halpern" wrote: >> >>>>>>>>>> >> >>>>>>>>>>> I would draw a distinction. Ofcom regulations about >> >>>>>>>>>>> whitespace requests are very much relevant. Ofcom >> >>>>>>>>>>> regulations about notification of dynamic behavior (which >> >>>>>>>>>>> spectrum is being used) are not in scope as I understand >> >>>>>>>>>>> the earlier discussions, particularly the chartering >> >>>>>>>>>>> discussions. >> >>>>>>>>>>> >> >>>>>>>>>>> Yours, Joel >> >>>>>>>>>>> >> >>>>>>>>>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: >> >>>>>>>>>>>> >> >>>>>>>>>>>> The ofcom requirements are very much relevant to the >> >>>>>>>>>>>> scope of the PAWS WG. The only other regulatory >> >>>>>>>>>>>> requirements that we have today is the FCC. Ofcom >> >>>>>>>>>>>> requirements are a good addition to the set. >> >>>>>>>>>>>> >> >>>>>>>>>>>> -Raj >> >>>>>>>>>>>> >> >>>>>>>>>>>> On 3/6/12 10:03 AM, "ext >> >>>>>>>>>>>> andy.sago@bt.com" wrote: >> >>>>>>>>>>>> >> >>>>>>>>>>>>> Hi Joel >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> There's no language I can find in the charter that >> >>>>>>>>>>>>> explicitly puts this out of scope. On the other hand, >> >>>>>>>>>>>>> the charter says that the group will "consider input >> >>>>>>>>>>>>> from regulatory entities", and this is one of the >> >>>>>>>>>>>>> requirements from Ofcom that they have just published. >> >>>>>>>>>>>>> The protocol will be worthless for the UK if it omits >> >>>>>>>>>>>>> some requirements. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Regards >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Andy >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> -----Original Message----- From: Joel M. Halpern >> >>>>>>>>>>>>> [mailto:jmh@joelhalpern.com] Sent: 06 March 2012 15:53 >> >>>>>>>>>>>>> To: Sago,AJ,Andy,COD R Cc: paws@ietf.org; >> >>>>>>>>>>>>> Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for >> >>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel >> >>>>>>>>>>>>> reporting >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> As I understand, the information you are asking for is >> >>>>>>>>>>>>> explicitly out of scope for the working group. Yours, >> >>>>>>>>>>>>> Joel >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >> >>>>>>>>>>>>>> All >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Comparing the draft with the Ofcom requirements at >> >>>>>>>>>>>>>> http://www.cept.org/Documents/se- >> >>>>> 43/4161/SE43(12)Info03_Draft-UK-r >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>> egul >> >>>>>>>>>>>>>> atory-requirements-for-white-space-devices-in-the-UHF- >> TV- >> >>>>> band, >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>> I believe the WG draft is deficient in the area of reporting >> >>>>>>>>>>>>>> frequencies and powers actually used by masters and >> >>>>>>>>>>>>>> slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom >> >>>>>>>>>>>>>> intends to collect this data to assesses the impact >> >>>>>>>>>>>>>> of aggregate interference into other services. It >> >>>>>>>>>>>>>> would also provide usage information (frequency in >> >>>>>>>>>>>>>> use) that would inform the operation of a kill switch >> >>>>>>>>>>>>>> capability. I suggest this deficiency can be remedied >> >>>>>>>>>>>>>> with the following changes: >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> New P requirements (probably best placed following >> >>>>>>>>>>>>>> P.12): >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> P.12bis: The protocol MUST support a channel usage >> >>>>>>>>>>>>>> message from the slave device to the master device. >> >>>>>>>>>>>>>> The channel usage message MUST include parameters as >> >>>>>>>>>>>>>> required by local regulatory requirement. These >> >>>>>>>>>>>>>> parameters MAY include device ID, manufacturer's >> >>>>>>>>>>>>>> serial number, channel usage and power level >> >>>>>>>>>>>>>> information. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> P.12ter: The protocol MUST support a channel usage >> >>>>>>>>>>>>>> message from the master device to the database. The >> >>>>>>>>>>>>>> channel usage message MUST include parameters as >> >>>>>>>>>>>>>> required by local regulatory requirement for the >> >>>>>>>>>>>>>> master and its associated slaves. These parameters >> >>>>>>>>>>>>>> MAY include device ID, manufacturer's serial number, >> >>>>>>>>>>>>>> channel usage and power level information. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> P.12qua: The protocol MUST support a channel usage >> >>>>>>>>>>>>>> message acknowledgement. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> New O requirements (probably best placed following >> >>>>>>>>>>>>>> O13): >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> O.13bis: According to local regulatory policy, after >> >>>>>>>>>>>>>> connecting to a master device's radio network a slave >> >>>>>>>>>>>>>> device MAY inform the master device of the actual >> >>>>>>>>>>>>>> channel usage. The slave MUST include parameters >> >>>>>>>>>>>>>> required by local regulatory policy, e.g. device ID, >> >>>>>>>>>>>>>> manufacturer's serial number, channel usage and power >> >>>>>>>>>>>>>> level information. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> O.13ter: According to local regulatory policy, a >> >>>>>>>>>>>>>> master device MAY inform the database of the actual >> >>>>>>>>>>>>>> channel usage of the master and its slaves. The >> >>>>>>>>>>>>>> master MUST include parameters required by local >> >>>>>>>>>>>>>> regulatory policy, e.g. device ID, manufacturer's >> >>>>>>>>>>>>>> serial number, channel usage and power level >> >>>>>>>>>>>>>> information of the master and its slaves. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> New steps could be introduced into one or more use >> >>>>>>>>>>>>>> cases to cover these Ofcom requirements, e.g. new >> >>>>>>>>>>>>>> steps 6bis and 9bis in the hotspot use case at >> >>>>>>>>>>>>>> 4.2.1: >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> 6bis. Prior to initiating transmission, if required >> >>>>>>>>>>>>>> by local regulation, the master/AP informs the >> >>>>>>>>>>>>>> database of the channel and power level it has >> >>>>>>>>>>>>>> chosen. This is repeated for each slave that >> >>>>>>>>>>>>>> associated with the master. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> 9bis. Prior to initiating transmission, if required >> >>>>>>>>>>>>>> by local regulation, the slave informs the master/AP >> >>>>>>>>>>>>>> of the channel and power level it has chosen, and the >> >>>>>>>>>>>>>> master/AP relays this information to the database. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> - end of new text - >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> For information, for those not accessing the url in >> >>>>>>>>>>>>>> the first paragraph of this email, the full Ofcom >> >>>>>>>>>>>>>> requirements leading to this new PAWS text are as >> >>>>>>>>>>>>>> follows: >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> 3.18 After receiving instructions from a WSDB in >> >>>>>>>>>>>>>> relation to the maximum permitted EIRPs over the DTT >> >>>>>>>>>>>>>> channels, and prior to initiating transmissions >> >>>>>>>>>>>>>> within the UHF TV band, a master WSD must communicate >> >>>>>>>>>>>>>> to the WSDB the following information: >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> 3.18.1 The lower and upper frequency boundaries^13 of >> >>>>>>>>>>>>>> the in-block emissions of the master WSD, and those >> >>>>>>>>>>>>>> of the in-block emissions of its associated slaves. A >> >>>>>>>>>>>>>> lower frequency will be specified as (470 + 8k + >> >>>>>>>>>>>>>> 0.2n) MHz, with the corresponding upper frequency >> >>>>>>>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3=AE4 k 3=AE4 >> >>>>>>>>>>>>>> 39, 0 3=AE4 n 3=AE4 39, 1 3=AE4 m 3=AE4 40, and n< m. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> 3.18.2 The maximum in-block EIRP spectral densities >> >>>>>>>>>>>>>> (in dBm/(0.2 MHz)) that the master WSD, and its >> >>>>>>>>>>>>>> associated slaves, actually radiate between each >> >>>>>>>>>>>>>> reported lower frequency boundary and its >> >>>>>>>>>>>>>> corresponding upper frequency boundary. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Footnote 13 states: >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> The use of upper and lower frequency boundaries >> >>>>>>>>>>>>>> (defined over a 200 kHz raster) allows a WSDB to >> >>>>>>>>>>>>>> collect more granular information with regards to the >> >>>>>>>>>>>>>> usage of the frequency resource by narrowband WSD >> >>>>>>>>>>>>>> technologies. The upper and lower frequencies of a >> >>>>>>>>>>>>>> boundary pair do not straddle a DTT channel boundary. >> >>>>>>>>>>>>>> Note that a WSD may transmit over multiple, >> >>>>>>>>>>>>>> non-contiguous, whole DTT channels or fractions of >> >>>>>>>>>>>>>> DTT channels. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> 3.19 A master WSD must be able to receive the >> >>>>>>>>>>>>>> following information^14 from a WSDB: >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in the >> >>>>>>>>>>>>>> context of 3.18, that the reported information on the >> >>>>>>>>>>>>>> DTT channels and EIRP spectral densities actually >> >>>>>>>>>>>>>> used by the master and slave WSDs were received >> >>>>>>>>>>>>>> successfully by the WSDB^18 ]. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Footnote 14 states: >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> 14 While the communication of some of this >> >>>>>>>>>>>>>> information from a WSDB to a master WSD is optional, >> >>>>>>>>>>>>>> master WSDs must be able to receive and interpret >> >>>>>>>>>>>>>> these. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Footnote 18 states: >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> 18 This forms part of a handshake protocol and may be >> >>>>>>>>>>>>>> an area where industry could harmonise without the >> >>>>>>>>>>>>>> need for an explicit requirement in the regulations. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Regards >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Andy >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> *From:*paws-bounces@ietf.org >> >>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] *On Behalf Of >> >>>>>>>>>>>>>> *Gabor.Bajko@nokia.com *Sent:* 05 March 2012 19:46 >> >>>>>>>>>>>>>> *To:* paws@ietf.org *Subject:* [paws] WGLC for >> >>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> The authors of the use cases and requirements draft >> >>>>>>>>>>>>>> have just posted a new version of the draft and >> >>>>>>>>>>>>>> indicated that there are no unresolved >> >>>>>>>>>>>>>> comments/issues they are aware of. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Therefore, I'd like to initiate a WG Last Call for >> >>>>>>>>>>>>>> comments on >> >>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-paws- >> problem- >> >>>>> stmt-u >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>> seca >> >>>>>>>>>>>>>> ses-rqmts-03.txt >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Please review the draft and send your comments to the >> >>>>>>>>>>>>>> list by March 20th, 2012. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> If you review the draft and have no comments, send a >> >>>>>>>>>>>>>> note to the list that the draft is good as it is, we >> >>>>>>>>>>>>>> need these notes as much as we need the actual >> >>>>>>>>>>>>>> comments. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Thanks, Gabor >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> > >> > _______________________________________________ >> > paws mailing list >> > paws@ietf.org >> > https://www.ietf.org/mailman/listinfo/paws >> > >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >>=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 stpeter@stpeter.im Thu Mar 8 12:40:44 2012 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 DEA0D21E8032 for ; Thu, 8 Mar 2012 12:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.435 X-Spam-Level: X-Spam-Status: No, score=-101.435 tagged_above=-999 required=5 tests=[AWL=-1.463, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, 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 NTWRfvfnGnbw for ; Thu, 8 Mar 2012 12:40:43 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 81C3D21E802D for ; Thu, 8 Mar 2012 12:40:42 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 90BD04005B; Thu, 8 Mar 2012 13:52:44 -0700 (MST) Message-ID: <4F591947.6080603@stpeter.im> Date: Thu, 08 Mar 2012 13:40:39 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: paws@ietf.org, johnny.dixon@bt.com, chris.cheeseman@bt.com, presnick@qualcomm.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 20:40:45 -0000 A rose by any other name is still a rose. :) It might be true that some folks have a very clear requirement for adding coexistence managers to the architecture, but those are not necessarily the same things as white space databases. On 3/8/12 1:32 PM, Basavaraj.Patil@nokia.com wrote: > > Hi JC, > > Where/why did the coexistence manager come into the picture? Your comment > about "communicating back to the WSDB/coexistence manager" may result in > further misunderstanding. If we simply stick to to WSDB I think we are > okay. > > -Raj > > On 3/8/12 2:25 PM, "ext Zuniga, Juan Carlos" > wrote: > >> So, from Gerald and Andy's comments, it seems like from the point of view >> of (at least) two regulatory entities it is important for the protocol to >> allow communicating back to the WSDB/coexistence manager the actual >> channel usage after the first query is made. >> >> This is to me a very clear requirement. >> >> The actual messages/IEs that would carry this information should be >> discussed as part of the solution document, and not the requirements. >> >> JC >> >>> -----Original Message----- >>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >>> Gerald Chouinard >>> Sent: Thursday, March 08, 2012 1:59 PM >>> To: 'Joel M. Halpern'; scott.probasco@nokia.com >>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>> chris.cheeseman@bt.com >>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >>> rqmts-03:channel reporting >>> >>> Joel, Scott, >>> >>> Interesting discussion! See my comments in line below. >>> >>> Gerald >>> >>> -----Original Message----- >>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >>> Joel >>> M. Halpern >>> Sent: Thursday, 08 March, 2012 13:17 >>> To: scott.probasco@nokia.com >>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>> chris.cheeseman@bt.com >>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >>> rqmts-03: >>> channel reporting >>> >>> So why won't the device simply say "I will use all of this?" >>> [GC] This would defeat the purpose of the acknowledgement message. >>> After all, that way it needs to do less work with the database. And it >>> can change frequencies when it wants. >>> Given that the stated goal of the Ofcom requriement was to be able to >>> analyze interference effects, it seems that this will not actually lead >>> to them getting what they want, even if it does comply with the >>> regulations. >>> [GC] You got it. This would be useless for spectrum regulators. One >>> should >>> realize that, from the spectrum regulator's point of view, the second >>> and >>> third messages could be iterated upon to optimize the spectrum use. >>> Knowing >>> what channels the systems in an area are using, the spectrum regulators >>> and/or other entities such as those taking care of coexistence could >>> use the >>> database in near-real-time to iterate on the two last messages to >>> reduce the >>> range of channels that some systems may use once they know precisely >>> what >>> channels are being used in the area. The PAWS protocol would carry the >>> information back and forth but would not be involved in such spectrum >>> use >>> optimization. >>> >>> Yours, >>> joel >>> >>> On 3/8/2012 1:09 PM, scott.probasco@nokia.com wrote: >>>> Hi Peter, >>>> >>>> Answers below. >>>> >>>> Kind Regards, >>>> Scott >>>> >>>> On 3/8/12 11:39 AM, "ext Peter Saint-Andre" >>> wrote: >>>> >>>>> Hi Scott, I have two clarifying questions: >>>>> >>>>> 1. Does the device know, when it receives the channel response, >>> which >>>>> channel it will actually use? >>>> Scott->This is all new and I am not aware of any existing >>> implementations. >>>> I would argue that the device must decide what channel(s) it will use >>> when >>>> it receives the channel response. >>> [GC] Agree with Scott but this is only a portion of the considerations. >>> If a >>> device was to operate on its own, this would be true but a >>> communication >>> device usually implies at least 2 devices to communicate. Hence, the >>> choice >>> of the channel to be used will need to be negotiated between the two >>> devices >>> before a choice can be made. The chosen channel will belong to the set >>> of >>> available channels that is common to both devices. Remember that some >>> channels may be available at one device and not at the other because of >>> their geolocation or other reason. Extending this concept to a star >>> network >>> topology, the channel that will be selected by this network will have >>> to >>> belong to the set of channels that are available to all devices. Each >>> device >>> will not be able to decide by itself which channel it wants to use. >>> >>> This is why in such a star topology, it makes sense that the slave >>> devices >>> to a base station or access point be represented by the base station >>> acting >>> as the master on their behalf to query the database and receive the >>> list of >>> available channels (and/or maximum EIRP per channel). It is then the >>> responsibility of the base station to identify the set of available >>> channels >>> that is common for itself and all its slaves to decide on the channel >>> that >>> the network will use. As you can see, in this case, there is no need >>> for >>> each slave to receive its list of available channels. On its own, it >>> would >>> not know what to do with it. The only thing that needs to be sent from >>> the >>> master device to its slaves is the resulting operating channel. >>> >>> I a more sophisticated operation, the master device may add one or a >>> few >>> backup channels extracted from the common set of available channel to >>> the >>> message going to its slave so that if a change in channel availability >>> occurs, an instantaneous switch to the next backup channel can be made >>> without any further signaling, thus providing for a channel switch that >>> is >>> transparent to the user. It is the scheme that has been included in the >>> IEEE >>> 802.22-2011 Standard. This is why I don't believe that PAWS should get >>> involved in defining this signaling between the base station and its >>> slaves >>> devices. >>>>> >>>>> 2. If the device then uses another channel or a different channel, >>> does >>>>> it need to report that change to the database? >>>> Scott->My interpretation of section 3.18 is that the device can only >>>> transmit within the upper& lower frequencies returned in the >>>> acknowledgment. I do not (quickly) find any reference in the >>> requirements >>>> to changing channels. Thus operationally it could be that the channel >>>> request process must be repeated before the device can use a >>> different >>>> channel (frequencies). >>> [GC] If the process involves 2 messages, then, the device and its >>> associated >>> devices could change channels at will as long as all these channels >>> belong >>> to the set of available channel. However, if the third message is >>> added, it >>> would make sense that the master device reports to the database any >>> channel >>> change that would occur to the database, otherwise, the status of the >>> spectrum occupation would be wrong at any moment and would be useless >>> for >>> the purpose of any spectrum usage optimization such as coexistence. >>>>> >>>>> Thanks! >>>>> >>>>> Peter >>>>> >>>>> On 3/8/12 10:17 AM, scott.probasco@nokia.com wrote: >>>>>> Hi, >>>>>> >>>>>> The point from Brian is very relevant: >>>>>> >>>>>> Channel request >>>>>> Channel response >>>>>> Channel acknowledgement >>>>>> >>>>>> What Ofcom does with the information in the acknowledgement does >>> not >>>>>> matter. As the regulator in UK, they write rules that must be >>> followed >>>>>> in >>>>>> order to operate a whitespace radio in the UK. I believe the scope >>> of >>>>>> the >>>>>> WG must be focused on a working solution. If this is simple channel >>>>>> request& response in one regulator's domain, PAWS can support >>> this. If >>>>>> it >>>>>> means a channel request, response and acknowledgement in another >>>>>> regulator's domain, PAWS can support this. As a participating >>> member of >>>>>> the work group, I believe the scope should be basic working >>> solution, >>>>>> not >>>>>> limited to a specific number of messages. >>>>>> >>>>>> Kind Regards, >>>>>> Scott >>>>>> >>>>>> >>>>>> >>>>>> On 3/8/12 11:11 AM, "ext Zuniga, Juan Carlos" >>>>>> wrote: >>>>>> >>>>>>> Peter, Nancy, >>>>>>> >>>>>>> I agree should design a protocol with the best of our current >>>>>>> knowledge, >>>>>>> and that should be accounting for all the known regulations at >>> present >>>>>>> time. We should not limit the scope with the purpose of designing >>> a >>>>>>> protocol 'faster'. Our goal is not only to design a WSDB protocol. >>> Our >>>>>>> goal is to design a WSDB protocol that is USEFUL to the community. >>>>>>> >>>>>>> The charter does state that >>>>>>> >>>>>>> "...the group should also reach out to other potential >>>>>>> "customers" for a white space database access method and consider >>> input >>>>>> >from regulatory entities that are involved in the specification of >>> the >>>>>>> rules for secondary use of spectrum in specific radio bands. " >>>>>>> >>>>>>> I think that is exactly what we are doing now. >>>>>>> >>>>>>> Regarding whether the types of requirements belong to #1 or #2, I >>>>>>> believe >>>>>>> it is more of #1 type, as the information to be exchanged would be >>>>>>> known >>>>>>> after the initial query/response. >>>>>>> >>>>>>> If we know it today, I see no reason why we should not work on it >>> in >>>>>>> the >>>>>>> first phase of the work. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Juan Carlos >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >>> Behalf >>>>>>>> Of >>>>>>>> Peter Saint-Andre >>>>>>>> Sent: Thursday, March 08, 2012 11:59 AM >>>>>>>> To: Nancy Bravin >>>>>>>> Cc: paws@ietf.org; johnny.dixon@bt.com; chris.cheeseman@bt.com; >>> Pete >>>>>>>> Resnick >>>>>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- >>> usecases- >>>>>>>> rqmts-03: channel reporting >>>>>>>> >>>>>>>> Hi Nancy, >>>>>>>> >>>>>>>> You are absolutely right that different locales will have >>> different >>>>>>>> rules and requirements. We need to understand those, and work to >>>>>>>> address >>>>>>>> them if possible (although we don't necessarily need to address >>> them >>>>>>>> all >>>>>>>> at the same time). I see several kinds of requirements: >>>>>>>> >>>>>>>> 1. Some requirements might lead to features beyond the >>> query/response >>>>>>>> protocol we've envisioned so far. One example might be real-time >>>>>>>> reporting about the channels that a device is actually using. In >>> my >>>>>>>> opinion, it would be best to handle those in the next phase of >>> work, >>>>>>>> because as far as I can see they are outside the scope of our >>> charter. >>>>>>>> >>>>>>>> 2. Some requirements might be handled through by defining >>> additional >>>>>>>> fields that can be included in the query or response. We >>> definitely >>>>>>>> planned for that when working on the charter with the IESG: >>>>>>>> >>>>>>>> In addition, the particular >>>>>>>> data exchanged between a device and a database might depend on >>> the >>>>>>>> ranges of radio spectrum that are to be used, the requirements >>> of >>>>>>>> the >>>>>>>> database operators and their governing regulations, and other >>>>>>>> factors. >>>>>>>> Therefore, the database access method and the query/response >>> data >>>>>>>> formats that are exchanged using that method need to be >>> designed >>> for >>>>>>>> extensibility rather than being tied to any specific spectrum, >>>>>>>> country, or phy/mac/air interface. >>>>>>>> >>>>>>>> It's unclear to me right now if the Ofcom requirement fits into >>> #1 or >>>>>>>> #2, which is why we're having this discussion. :) >>>>>>>> >>>>>>>> Peter >>>>>>>> >>>>>>>> On 3/7/12 8:17 PM, Nancy Bravin wrote: >>>>>>>>> Peter and all, >>>>>>>>> >>>>>>>>> I agree that it is important to revisit now, so that in the >>> future, >>>>>>>>> it will be easy to align things in their proper place. Every >>> country >>>>>>>>> may have different regulations, spectrum, policy and what >>>>>>>>> responsibility is in the domain of the system, and what comes >>> under >>>>>>>>> the PAWS charter is important. Maybe some separation might be >>>>>>>>> possible, and dividing and clarifying issues now will help in >>> the >>>>>>>>> future. Certainly it seems that the FCC may change some rules, >>> and >>>>>>>>> we know that Ofcom is not yet finished with their regulations. >>> Canada >>>>>>>>> has their own, and other countries are working on this as well. >>> Just >>>>>>>>> a thought...Sharing is a realistic goal...as is off loading... >>> Or you >>>>>>>>> slim line and every 6 months decide what to incorporate in the >>>>>>>>> protocol based on new information, new ideas, new innovation new >>>>>>>>> regulations and maybe spend more time than you could if >>> addressed >>>>>>>>> now. >>>>>>>>> >>>>>>>>> That way you leave the door open and outside of referencing what >>> is >>>>>>>>> known today, by referencing regulations i.e. Ofcom, FCC, >>> Industry >>>>>>>>> Canada etc as of XX-XX-XXXX date. Out of scope not something we >>> know >>>>>>>>> enough about to say at this point, In my opinion. >>>>>>>>> >>>>>>>>> My 2 cents.. >>>>>>>>> >>>>>>>>> Sincerely, Nancy >>>>>>>>> >>>>>>>>> On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> As your responsible Area Director (until March 28, when Pete >>>>>>>>>> Resnick will take over from me), I have reviewed this thread. >>>>>>>>>> >>>>>>>>>> In my opinion (I am happy to be proven wrong), this new >>> requirement >>>>>>>>>> goes beyond what the charter defined as the scope of this >>> working >>>>>>>>>> group, which was to enable a device to discover the white space >>>>>>>>>> available to it in its current location. Reporting usage back >>> to >>>>>>>>>> the database is simply not mentioned in the charter. >>>>>>>>>> >>>>>>>>>> Earlier in this thread, Andy Sago wrote: >>>>>>>>>> >>>>>>>>>> There's no language I can find in the charter that explicitly >>> puts >>>>>>>>>> this out of scope. >>>>>>>>>> >>>>>>>>>> An IETF charter defines what the working group shall work on. >>> Many >>>>>>>>>> interesting features could be developed here. However, it is >>> not >>>>>>>>>> the job of the charter to mention explicitly that each of those >>>>>>>>>> interesting features is out of scope. >>>>>>>>>> >>>>>>>>>> The charter does say: >>>>>>>>>> >>>>>>>>>> Once the device learns of the available white space (e.g., in a >>> TV >>>>>>>>>> white space implementation, the list of available channels at >>> that >>>>>>>>>> location), it can then select one of the bands from the list >>> and >>>>>>>>>> begin to transmit and receive on the selected band. >>>>>>>>>> >>>>>>>>>> This text might have assumed that no further communication or >>>>>>>>>> authorization was required in order to select one of the bands >>> from >>>>>>>>>> the list and then transmit/receive. Perhaps that assumption was >>>>>>>>>> mistaken. If so, it would be good to have a discussion about >>> that, >>>>>>>>>> so we can determine if we need to revisit the assumptions we >>> made >>>>>>>>>> early on. If in fact we made some faulty or limited >>> assumptions, >>>>>>>>>> then let's get that out in the open. >>>>>>>>>> >>>>>>>>>> Peter >>>>>>>>>> >>>>>>>>>> On 3/7/12 9:40 AM, Rosen, Brian wrote: >>>>>>>>>>> I'd also suggest that our >>>>>>>>>>> charter limitation is really support for sharing of whitespace >>> by >>>>>>>>>>> whitespace devices. Reporting what you use is not sharing, >>> it's >>>>>>>>>>> just data gathering. >>>>>>>>>>> >>>>>>>>>>> The point of excluding sharing was to eliminate the >>> complexities >>>>>>>>>>> of what constituted fairness, and what kinds of communication >>>>>>>>>>> might be needed between databases, where more than one could >>>>>>>>>>> supply available whitespace in a band. This doesn't have any >>> of >>>>>>>>>>> those issues, As long as it's just sending information, I >>> don't >>>>>>>>>>> have a problem. Once the database is supposed to do anything >>>>>>>>>>> with it that involves changing what spectrum it reports, then >>> I >>>>>>>>>>> think we cross the line. >>>>>>>>>>> >>>>>>>>>>> Brian >>>>>>>>>>> >>>>>>>>>>> On Mar 6, 2012, at 12:28 PM, >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Joel >>>>>>>>>>>> >>>>>>>>>>>> Indeed, the regulator has not described the process or >>> provided >>>>>>>>>>>> a flow diagram, so there may be some wrinkles, but we need to >>>>>>>>>>>> provide for their intent. To answer your question, the >>> channels >>>>>>>>>>>> that the master will use are sent in a separate message >>>>>>>>>>>> (described in P.12 ter), that occurs after the master >>> receives >>>>>>>>>>>> the response to its channel request, but before the master >>> can >>>>>>>>>>>> transmit. At this point, it knows what channels are >>> available, >>>>>>>>>>>> and which one it will use. As far as the slaves are >>> concerned, >>>>>>>>>>>> as they associate, the master will need to gather their >>> details >>>>>>>>>>>> and send further channel usage messages to the database on >>>>>>>>>>>> their behalf. >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> >>>>>>>>>>>> Andy >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- From: paws-bounces@ietf.org >>>>>>>>>>>> [mailto:paws-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>>>>>>>>>> Sent: 06 March 2012 17:05 To: scott.probasco@nokia.com Cc: >>>>>>>>>>>> paws@ietf.org; Cheeseman,CJ,Chris,COD R; Dixon,JS,Johnny,COD >>> R >>>>>>>>>>>> Subject: Re: [paws] WGLC for >>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel >>>>>>>>>>>> reporting >>>>>>>>>>>> >>>>>>>>>>>> Ahh. I think I see where the request and my understanding >>>>>>>>>>>> divurge. If the idea here is that the master must provide, in >>>>>>>>>>>> the request, an indication of what channels it expects to >>> use, >>>>>>>>>>>> I can at least understand that. I will return to technical >>>>>>>>>>>> concerns in a moment. >>>>>>>>>>>> >>>>>>>>>>>> However, when you say "provide channel usage information, in >>>>>>>>>>>> order to evaluate interference", what that says to me is >>>>>>>>>>>> providing, during operation, information as to what channels >>>>>>>>>>>> are being used, and at what power levels. That is what would >>>>>>>>>>>> be needed to analyze actual interference effects. And that is >>>>>>>>>>>> out of scope as I understand our scope. >>>>>>>>>>>> >>>>>>>>>>>> I do see a technical difficulty with having the master >>> provide, >>>>>>>>>>>> as part of either registering or requesting spectrum >>>>>>>>>>>> information, what channels it intends to use. It doesn;t >>> know >>>>>>>>>>>> what channels it intends to use. It intends to use some >>> number >>>>>>>>>>>> of available channels. It will figure out which ones when it >>>>>>>>>>>> is told what is available. How can it send that information >>> in >>>>>>>>>>>> the request? >>>>>>>>>>>> >>>>>>>>>>>> Yours, Joel >>>>>>>>>>>> >>>>>>>>>>>> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> There is a similarity here with device ID. In context of >>> PAWS >>>>>>>>>>>>> we are not concerned with why a device ID is required by a >>>>>>>>>>>>> regulator, we accept it is a requirement from a regulator >>> and >>>>>>>>>>>>> include it to the protocol. Ofcom identifies in 3.18& 3.19 >>>>>>>>>>>>> that channel usage information is required and thus we need >>>>>>>>>>>>> to include this information. Since the master must provide >>>>>>>>>>>>> this information prior to transmitting, PAWS will not >>>>>>>>>>>>> function in the UK without this information and thus I >>>>>>>>>>>>> believe channel usage information is integral to the channel >>>>>>>>>>>>> request& response messaging. >>>>>>>>>>>>> >>>>>>>>>>>>> Kind Regards, Scott >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 3/6/12 10:30 AM, "ext Joel M. >>>>>>>>>>>>> Halpern" wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> I would draw a distinction. Ofcom regulations about >>>>>>>>>>>>>> whitespace requests are very much relevant. Ofcom >>>>>>>>>>>>>> regulations about notification of dynamic behavior (which >>>>>>>>>>>>>> spectrum is being used) are not in scope as I understand >>>>>>>>>>>>>> the earlier discussions, particularly the chartering >>>>>>>>>>>>>> discussions. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The ofcom requirements are very much relevant to the >>>>>>>>>>>>>>> scope of the PAWS WG. The only other regulatory >>>>>>>>>>>>>>> requirements that we have today is the FCC. Ofcom >>>>>>>>>>>>>>> requirements are a good addition to the set. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -Raj >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 3/6/12 10:03 AM, "ext >>>>>>>>>>>>>>> andy.sago@bt.com" wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Joel >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> There's no language I can find in the charter that >>>>>>>>>>>>>>>> explicitly puts this out of scope. On the other hand, >>>>>>>>>>>>>>>> the charter says that the group will "consider input >>>>>>>>>>>>>>>> from regulatory entities", and this is one of the >>>>>>>>>>>>>>>> requirements from Ofcom that they have just published. >>>>>>>>>>>>>>>> The protocol will be worthless for the UK if it omits >>>>>>>>>>>>>>>> some requirements. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Andy >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -----Original Message----- From: Joel M. Halpern >>>>>>>>>>>>>>>> [mailto:jmh@joelhalpern.com] Sent: 06 March 2012 15:53 >>>>>>>>>>>>>>>> To: Sago,AJ,Andy,COD R Cc: paws@ietf.org; >>>>>>>>>>>>>>>> Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for >>>>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel >>>>>>>>>>>>>>>> reporting >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> As I understand, the information you are asking for is >>>>>>>>>>>>>>>> explicitly out of scope for the working group. Yours, >>>>>>>>>>>>>>>> Joel >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >>>>>>>>>>>>>>>>> All >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Comparing the draft with the Ofcom requirements at >>>>>>>>>>>>>>>>> http://www.cept.org/Documents/se- >>>>>>>> 43/4161/SE43(12)Info03_Draft-UK-r >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> egul >>>>>>>>>>>>>>>>> atory-requirements-for-white-space-devices-in-the-UHF- >>> TV- >>>>>>>> band, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> I believe the WG draft is deficient in the area of reporting >>>>>>>>>>>>>>>>> frequencies and powers actually used by masters and >>>>>>>>>>>>>>>>> slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom >>>>>>>>>>>>>>>>> intends to collect this data to assesses the impact >>>>>>>>>>>>>>>>> of aggregate interference into other services. It >>>>>>>>>>>>>>>>> would also provide usage information (frequency in >>>>>>>>>>>>>>>>> use) that would inform the operation of a kill switch >>>>>>>>>>>>>>>>> capability. I suggest this deficiency can be remedied >>>>>>>>>>>>>>>>> with the following changes: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> New P requirements (probably best placed following >>>>>>>>>>>>>>>>> P.12): >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> P.12bis: The protocol MUST support a channel usage >>>>>>>>>>>>>>>>> message from the slave device to the master device. >>>>>>>>>>>>>>>>> The channel usage message MUST include parameters as >>>>>>>>>>>>>>>>> required by local regulatory requirement. These >>>>>>>>>>>>>>>>> parameters MAY include device ID, manufacturer's >>>>>>>>>>>>>>>>> serial number, channel usage and power level >>>>>>>>>>>>>>>>> information. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> P.12ter: The protocol MUST support a channel usage >>>>>>>>>>>>>>>>> message from the master device to the database. The >>>>>>>>>>>>>>>>> channel usage message MUST include parameters as >>>>>>>>>>>>>>>>> required by local regulatory requirement for the >>>>>>>>>>>>>>>>> master and its associated slaves. These parameters >>>>>>>>>>>>>>>>> MAY include device ID, manufacturer's serial number, >>>>>>>>>>>>>>>>> channel usage and power level information. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> P.12qua: The protocol MUST support a channel usage >>>>>>>>>>>>>>>>> message acknowledgement. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> New O requirements (probably best placed following >>>>>>>>>>>>>>>>> O13): >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> O.13bis: According to local regulatory policy, after >>>>>>>>>>>>>>>>> connecting to a master device's radio network a slave >>>>>>>>>>>>>>>>> device MAY inform the master device of the actual >>>>>>>>>>>>>>>>> channel usage. The slave MUST include parameters >>>>>>>>>>>>>>>>> required by local regulatory policy, e.g. device ID, >>>>>>>>>>>>>>>>> manufacturer's serial number, channel usage and power >>>>>>>>>>>>>>>>> level information. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> O.13ter: According to local regulatory policy, a >>>>>>>>>>>>>>>>> master device MAY inform the database of the actual >>>>>>>>>>>>>>>>> channel usage of the master and its slaves. The >>>>>>>>>>>>>>>>> master MUST include parameters required by local >>>>>>>>>>>>>>>>> regulatory policy, e.g. device ID, manufacturer's >>>>>>>>>>>>>>>>> serial number, channel usage and power level >>>>>>>>>>>>>>>>> information of the master and its slaves. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> New steps could be introduced into one or more use >>>>>>>>>>>>>>>>> cases to cover these Ofcom requirements, e.g. new >>>>>>>>>>>>>>>>> steps 6bis and 9bis in the hotspot use case at >>>>>>>>>>>>>>>>> 4.2.1: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 6bis. Prior to initiating transmission, if required >>>>>>>>>>>>>>>>> by local regulation, the master/AP informs the >>>>>>>>>>>>>>>>> database of the channel and power level it has >>>>>>>>>>>>>>>>> chosen. This is repeated for each slave that >>>>>>>>>>>>>>>>> associated with the master. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 9bis. Prior to initiating transmission, if required >>>>>>>>>>>>>>>>> by local regulation, the slave informs the master/AP >>>>>>>>>>>>>>>>> of the channel and power level it has chosen, and the >>>>>>>>>>>>>>>>> master/AP relays this information to the database. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - end of new text - >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> For information, for those not accessing the url in >>>>>>>>>>>>>>>>> the first paragraph of this email, the full Ofcom >>>>>>>>>>>>>>>>> requirements leading to this new PAWS text are as >>>>>>>>>>>>>>>>> follows: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 3.18 After receiving instructions from a WSDB in >>>>>>>>>>>>>>>>> relation to the maximum permitted EIRPs over the DTT >>>>>>>>>>>>>>>>> channels, and prior to initiating transmissions >>>>>>>>>>>>>>>>> within the UHF TV band, a master WSD must communicate >>>>>>>>>>>>>>>>> to the WSDB the following information: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 3.18.1 The lower and upper frequency boundaries^13 of >>>>>>>>>>>>>>>>> the in-block emissions of the master WSD, and those >>>>>>>>>>>>>>>>> of the in-block emissions of its associated slaves. A >>>>>>>>>>>>>>>>> lower frequency will be specified as (470 + 8k + >>>>>>>>>>>>>>>>> 0.2n) MHz, with the corresponding upper frequency >>>>>>>>>>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3Ž4 k 3Ž4 >>>>>>>>>>>>>>>>> 39, 0 3Ž4 n 3Ž4 39, 1 3Ž4 m 3Ž4 40, and n< m. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 3.18.2 The maximum in-block EIRP spectral densities >>>>>>>>>>>>>>>>> (in dBm/(0.2 MHz)) that the master WSD, and its >>>>>>>>>>>>>>>>> associated slaves, actually radiate between each >>>>>>>>>>>>>>>>> reported lower frequency boundary and its >>>>>>>>>>>>>>>>> corresponding upper frequency boundary. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Footnote 13 states: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The use of upper and lower frequency boundaries >>>>>>>>>>>>>>>>> (defined over a 200 kHz raster) allows a WSDB to >>>>>>>>>>>>>>>>> collect more granular information with regards to the >>>>>>>>>>>>>>>>> usage of the frequency resource by narrowband WSD >>>>>>>>>>>>>>>>> technologies. The upper and lower frequencies of a >>>>>>>>>>>>>>>>> boundary pair do not straddle a DTT channel boundary. >>>>>>>>>>>>>>>>> Note that a WSD may transmit over multiple, >>>>>>>>>>>>>>>>> non-contiguous, whole DTT channels or fractions of >>>>>>>>>>>>>>>>> DTT channels. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 3.19 A master WSD must be able to receive the >>>>>>>>>>>>>>>>> following information^14 from a WSDB: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in the >>>>>>>>>>>>>>>>> context of 3.18, that the reported information on the >>>>>>>>>>>>>>>>> DTT channels and EIRP spectral densities actually >>>>>>>>>>>>>>>>> used by the master and slave WSDs were received >>>>>>>>>>>>>>>>> successfully by the WSDB^18 ]. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Footnote 14 states: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 14 While the communication of some of this >>>>>>>>>>>>>>>>> information from a WSDB to a master WSD is optional, >>>>>>>>>>>>>>>>> master WSDs must be able to receive and interpret >>>>>>>>>>>>>>>>> these. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Footnote 18 states: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 18 This forms part of a handshake protocol and may be >>>>>>>>>>>>>>>>> an area where industry could harmonise without the >>>>>>>>>>>>>>>>> need for an explicit requirement in the regulations. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Andy >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> *From:*paws-bounces@ietf.org >>>>>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] *On Behalf Of >>>>>>>>>>>>>>>>> *Gabor.Bajko@nokia.com *Sent:* 05 March 2012 19:46 >>>>>>>>>>>>>>>>> *To:* paws@ietf.org *Subject:* [paws] WGLC for >>>>>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The authors of the use cases and requirements draft >>>>>>>>>>>>>>>>> have just posted a new version of the draft and >>>>>>>>>>>>>>>>> indicated that there are no unresolved >>>>>>>>>>>>>>>>> comments/issues they are aware of. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Therefore, I'd like to initiate a WG Last Call for >>>>>>>>>>>>>>>>> comments on >>>>>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-paws- >>> problem- >>>>>>>> stmt-u >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> seca >>>>>>>>>>>>>>>>> ses-rqmts-03.txt >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Please review the draft and send your comments to the >>>>>>>>>>>>>>>>> list by March 20th, 2012. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> If you review the draft and have no comments, send a >>>>>>>>>>>>>>>>> note to the list that the draft is good as it is, we >>>>>>>>>>>>>>>>> need these notes as much as we need the actual >>>>>>>>>>>>>>>>> comments. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, Gabor >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> From JuanCarlos.Zuniga@InterDigital.com Thu Mar 8 12:41:43 2012 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 3019C21E802D for ; Thu, 8 Mar 2012 12:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.715 X-Spam-Level: X-Spam-Status: No, score=-0.715 tagged_above=-999 required=5 tests=[AWL=-0.743, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, 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 ayVvZ4-49u8M for ; Thu, 8 Mar 2012 12:41:41 -0800 (PST) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id D509D21E8032 for ; Thu, 8 Mar 2012 12:41:33 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 15:41:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Mar 2012 15:41:31 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting Thread-Index: AQHM/WqaGADtHyPWsUCiCGl6fDpM1pZg3BVA References: From: "Zuniga, Juan Carlos" To: , , , X-OriginalArrivalTime: 08 Mar 2012 20:41:32.0974 (UTC) FILETIME=[D8EE84E0:01CCFD6B] Cc: paws@ietf.org, presnick@qualcomm.com, johnny.dixon@bt.com, chris.cheeseman@bt.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 20:41:43 -0000 Hi Raj, I was reusing the language used from Gerald (which I know is familiar to = people working on IEEE 802 WS groups): >> [GC] You got it. This would be useless for spectrum regulators. One=20 >> should realize that, from the spectrum regulator's point of view, the = >> second and third messages could be iterated upon to optimize the=20 >> spectrum use. >> Knowing >> what channels the systems in an area are using, the spectrum=20 >> regulators and/or other entities such as those taking care of=20 >> coexistence could use the database in near-real-time to iterate on=20 >> the two last messages to reduce the range of channels that some=20 >> systems may use once they know precisely what channels are being used = >> in the area. The PAWS protocol would carry the information back and=20 >> forth but would not be involved in such spectrum use optimization. Having said that, I have no issue sticking to the WSDB terminology. I = like keeping things simple :) JC > -----Original Message----- > From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] > Sent: Thursday, March 08, 2012 3:33 PM > To: Zuniga, Juan Carlos; gerald.chouinard@sympatico.ca; > jmh@joelhalpern.com; scott.probasco@nokia.com > Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; > chris.cheeseman@bt.com > Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- > rqmts-03:channel reporting >=20 >=20 > Hi JC, >=20 > Where/why did the coexistence manager come into the picture? Your > comment > about "communicating back to the WSDB/coexistence manager" may result > in > further misunderstanding. If we simply stick to to WSDB I think we are > okay. >=20 > -Raj >=20 > On 3/8/12 2:25 PM, "ext Zuniga, Juan Carlos" > wrote: >=20 > >So, from Gerald and Andy's comments, it seems like from the point of > view > >of (at least) two regulatory entities it is important for the = protocol > to > >allow communicating back to the WSDB/coexistence manager the actual > >channel usage after the first query is made. > > > >This is to me a very clear requirement. > > > >The actual messages/IEs that would carry this information should be > >discussed as part of the solution document, and not the requirements. > > > >JC > > > >> -----Original Message----- > >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On = Behalf > Of > >> Gerald Chouinard > >> Sent: Thursday, March 08, 2012 1:59 PM > >> To: 'Joel M. Halpern'; scott.probasco@nokia.com > >> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; > >> chris.cheeseman@bt.com > >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- > >> rqmts-03:channel reporting > >> > >> Joel, Scott, > >> > >> Interesting discussion! See my comments in line below. > >> > >> Gerald > >> > >> -----Original Message----- > >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On = Behalf > Of > >> Joel > >> M. Halpern > >> Sent: Thursday, 08 March, 2012 13:17 > >> To: scott.probasco@nokia.com > >> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; > >> chris.cheeseman@bt.com > >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- > >> rqmts-03: > >> channel reporting > >> > >> So why won't the device simply say "I will use all of this?" > >> [GC] This would defeat the purpose of the acknowledgement message. > >> After all, that way it needs to do less work with the database. = And > it > >> can change frequencies when it wants. > >> Given that the stated goal of the Ofcom requriement was to be able > to > >> analyze interference effects, it seems that this will not actually > lead > >> to them getting what they want, even if it does comply with the > >> regulations. > >> [GC] You got it. This would be useless for spectrum regulators. = One > >> should > >> realize that, from the spectrum regulator's point of view, the > second > >> and > >> third messages could be iterated upon to optimize the spectrum use. > >> Knowing > >> what channels the systems in an area are using, the spectrum > regulators > >> and/or other entities such as those taking care of coexistence = could > >> use the > >> database in near-real-time to iterate on the two last messages to > >> reduce the > >> range of channels that some systems may use once they know = precisely > >> what > >> channels are being used in the area. The PAWS protocol would carry > the > >> information back and forth but would not be involved in such > spectrum > >> use > >> optimization. > >> > >> Yours, > >> joel > >> > >> On 3/8/2012 1:09 PM, scott.probasco@nokia.com wrote: > >> > Hi Peter, > >> > > >> > Answers below. > >> > > >> > Kind Regards, > >> > Scott > >> > > >> > On 3/8/12 11:39 AM, "ext Peter Saint-Andre" > >> wrote: > >> > > >> >> Hi Scott, I have two clarifying questions: > >> >> > >> >> 1. Does the device know, when it receives the channel response, > >> which > >> >> channel it will actually use? > >> > Scott->This is all new and I am not aware of any existing > >> implementations. > >> > I would argue that the device must decide what channel(s) it will > use > >> when > >> > it receives the channel response. > >> [GC] Agree with Scott but this is only a portion of the > considerations. > >> If a > >> device was to operate on its own, this would be true but a > >> communication > >> device usually implies at least 2 devices to communicate. Hence, = the > >> choice > >> of the channel to be used will need to be negotiated between the = two > >> devices > >> before a choice can be made. The chosen channel will belong to the > set > >> of > >> available channels that is common to both devices. Remember that > some > >> channels may be available at one device and not at the other = because > of > >> their geolocation or other reason. Extending this concept to a star > >> network > >> topology, the channel that will be selected by this network will > have > >> to > >> belong to the set of channels that are available to all devices. > Each > >> device > >> will not be able to decide by itself which channel it wants to use. > >> > >> This is why in such a star topology, it makes sense that the slave > >> devices > >> to a base station or access point be represented by the base = station > >> acting > >> as the master on their behalf to query the database and receive the > >> list of > >> available channels (and/or maximum EIRP per channel). It is then = the > >> responsibility of the base station to identify the set of available > >> channels > >> that is common for itself and all its slaves to decide on the > channel > >> that > >> the network will use. As you can see, in this case, there is no = need > >> for > >> each slave to receive its list of available channels. On its own, = it > >> would > >> not know what to do with it. The only thing that needs to be sent > from > >> the > >> master device to its slaves is the resulting operating channel. > >> > >> I a more sophisticated operation, the master device may add one or = a > >> few > >> backup channels extracted from the common set of available channel > to > >> the > >> message going to its slave so that if a change in channel > availability > >> occurs, an instantaneous switch to the next backup channel can be > made > >> without any further signaling, thus providing for a channel switch > that > >> is > >> transparent to the user. It is the scheme that has been included in > the > >> IEEE > >> 802.22-2011 Standard. This is why I don't believe that PAWS should > get > >> involved in defining this signaling between the base station and = its > >> slaves > >> devices. > >> >> > >> >> 2. If the device then uses another channel or a different > channel, > >> does > >> >> it need to report that change to the database? > >> > Scott->My interpretation of section 3.18 is that the device can > only > >> > transmit within the upper& lower frequencies returned in the > >> > acknowledgment. I do not (quickly) find any reference in the > >> requirements > >> > to changing channels. Thus operationally it could be that the > channel > >> > request process must be repeated before the device can use a > >> different > >> > channel (frequencies). > >> [GC] If the process involves 2 messages, then, the device and its > >> associated > >> devices could change channels at will as long as all these channels > >> belong > >> to the set of available channel. However, if the third message is > >> added, it > >> would make sense that the master device reports to the database any > >> channel > >> change that would occur to the database, otherwise, the status of > the > >> spectrum occupation would be wrong at any moment and would be > useless > >> for > >> the purpose of any spectrum usage optimization such as coexistence. > >> >> > >> >> Thanks! > >> >> > >> >> Peter > >> >> > >> >> On 3/8/12 10:17 AM, scott.probasco@nokia.com wrote: > >> >>> Hi, > >> >>> > >> >>> The point from Brian is very relevant: > >> >>> > >> >>> Channel request > >> >>> Channel response > >> >>> Channel acknowledgement > >> >>> > >> >>> What Ofcom does with the information in the acknowledgement = does > >> not > >> >>> matter. As the regulator in UK, they write rules that must be > >> followed > >> >>> in > >> >>> order to operate a whitespace radio in the UK. I believe the > scope > >> of > >> >>> the > >> >>> WG must be focused on a working solution. If this is simple > channel > >> >>> request& response in one regulator's domain, PAWS can support > >> this. If > >> >>> it > >> >>> means a channel request, response and acknowledgement in = another > >> >>> regulator's domain, PAWS can support this. As a participating > >> member of > >> >>> the work group, I believe the scope should be basic working > >> solution, > >> >>> not > >> >>> limited to a specific number of messages. > >> >>> > >> >>> Kind Regards, > >> >>> Scott > >> >>> > >> >>> > >> >>> > >> >>> On 3/8/12 11:11 AM, "ext Zuniga, Juan Carlos" > >> >>> wrote: > >> >>> > >> >>>> Peter, Nancy, > >> >>>> > >> >>>> I agree should design a protocol with the best of our current > >> >>>> knowledge, > >> >>>> and that should be accounting for all the known regulations at > >> present > >> >>>> time. We should not limit the scope with the purpose of > designing > >> a > >> >>>> protocol 'faster'. Our goal is not only to design a WSDB > protocol. > >> Our > >> >>>> goal is to design a WSDB protocol that is USEFUL to the > community. > >> >>>> > >> >>>> The charter does state that > >> >>>> > >> >>>> "...the group should also reach out to other potential > >> >>>> "customers" for a white space database access method and > consider > >> input > >> >>> >from regulatory entities that are involved in the = specification > of > >> the > >> >>>> rules for secondary use of spectrum in specific radio bands. " > >> >>>> > >> >>>> I think that is exactly what we are doing now. > >> >>>> > >> >>>> Regarding whether the types of requirements belong to #1 or = #2, > I > >> >>>> believe > >> >>>> it is more of #1 type, as the information to be exchanged = would > be > >> >>>> known > >> >>>> after the initial query/response. > >> >>>> > >> >>>> If we know it today, I see no reason why we should not work on > it > >> in > >> >>>> the > >> >>>> first phase of the work. > >> >>>> > >> >>>> Regards, > >> >>>> > >> >>>> Juan Carlos > >> >>>> > >> >>>>> -----Original Message----- > >> >>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On > >> Behalf > >> >>>>> Of > >> >>>>> Peter Saint-Andre > >> >>>>> Sent: Thursday, March 08, 2012 11:59 AM > >> >>>>> To: Nancy Bravin > >> >>>>> Cc: paws@ietf.org; johnny.dixon@bt.com; > chris.cheeseman@bt.com; > >> Pete > >> >>>>> Resnick > >> >>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- > >> usecases- > >> >>>>> rqmts-03: channel reporting > >> >>>>> > >> >>>>> Hi Nancy, > >> >>>>> > >> >>>>> You are absolutely right that different locales will have > >> different > >> >>>>> rules and requirements. We need to understand those, and work > to > >> >>>>> address > >> >>>>> them if possible (although we don't necessarily need to > address > >> them > >> >>>>> all > >> >>>>> at the same time). I see several kinds of requirements: > >> >>>>> > >> >>>>> 1. Some requirements might lead to features beyond the > >> query/response > >> >>>>> protocol we've envisioned so far. One example might be real- > time > >> >>>>> reporting about the channels that a device is actually using. > In > >> my > >> >>>>> opinion, it would be best to handle those in the next phase = of > >> work, > >> >>>>> because as far as I can see they are outside the scope of our > >> charter. > >> >>>>> > >> >>>>> 2. Some requirements might be handled through by defining > >> additional > >> >>>>> fields that can be included in the query or response. We > >> definitely > >> >>>>> planned for that when working on the charter with the IESG: > >> >>>>> > >> >>>>> In addition, the particular > >> >>>>> data exchanged between a device and a database might = depend > on > >> the > >> >>>>> ranges of radio spectrum that are to be used, the > requirements > >> of > >> >>>>> the > >> >>>>> database operators and their governing regulations, and > other > >> >>>>> factors. > >> >>>>> Therefore, the database access method and the > query/response > >> data > >> >>>>> formats that are exchanged using that method need to be > >> designed > >> for > >> >>>>> extensibility rather than being tied to any specific > spectrum, > >> >>>>> country, or phy/mac/air interface. > >> >>>>> > >> >>>>> It's unclear to me right now if the Ofcom requirement fits > into > >> #1 or > >> >>>>> #2, which is why we're having this discussion. :) > >> >>>>> > >> >>>>> Peter > >> >>>>> > >> >>>>> On 3/7/12 8:17 PM, Nancy Bravin wrote: > >> >>>>>> Peter and all, > >> >>>>>> > >> >>>>>> I agree that it is important to revisit now, so that in the > >> future, > >> >>>>>> it will be easy to align things in their proper place. Every > >> country > >> >>>>>> may have different regulations, spectrum, policy and what > >> >>>>>> responsibility is in the domain of the system, and what = comes > >> under > >> >>>>>> the PAWS charter is important. Maybe some separation might > be > >> >>>>>> possible, and dividing and clarifying issues now will help = in > >> the > >> >>>>>> future. Certainly it seems that the FCC may change some > rules, > >> and > >> >>>>>> we know that Ofcom is not yet finished with their > regulations. > >> Canada > >> >>>>>> has their own, and other countries are working on this as > well. > >> Just > >> >>>>>> a thought...Sharing is a realistic goal...as is off > loading... > >> Or you > >> >>>>>> slim line and every 6 months decide what to incorporate in > the > >> >>>>>> protocol based on new information, new ideas, new innovation > new > >> >>>>>> regulations and maybe spend more time than you could if > >> addressed > >> >>>>>> now. > >> >>>>>> > >> >>>>>> That way you leave the door open and outside of referencing > what > >> is > >> >>>>>> known today, by referencing regulations i.e. Ofcom, FCC, > >> Industry > >> >>>>>> Canada etc as of XX-XX-XXXX date. Out of scope not something > we > >> know > >> >>>>>> enough about to say at this point, In my opinion. > >> >>>>>> > >> >>>>>> My 2 cents.. > >> >>>>>> > >> >>>>>> Sincerely, Nancy > >> >>>>>> > >> >>>>>> On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote: > >> >>>>>> > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> As your responsible Area Director (until March 28, when = Pete > >> >>>>>>> Resnick will take over from me), I have reviewed this > thread. > >> >>>>>>> > >> >>>>>>> In my opinion (I am happy to be proven wrong), this new > >> requirement > >> >>>>>>> goes beyond what the charter defined as the scope of this > >> working > >> >>>>>>> group, which was to enable a device to discover the white > space > >> >>>>>>> available to it in its current location. Reporting usage > back > >> to > >> >>>>>>> the database is simply not mentioned in the charter. > >> >>>>>>> > >> >>>>>>> Earlier in this thread, Andy Sago wrote: > >> >>>>>>> > >> >>>>>>> There's no language I can find in the charter that > explicitly > >> puts > >> >>>>>>> this out of scope. > >> >>>>>>> > >> >>>>>>> An IETF charter defines what the working group shall work > on. > >> Many > >> >>>>>>> interesting features could be developed here. However, it = is > >> not > >> >>>>>>> the job of the charter to mention explicitly that each of > those > >> >>>>>>> interesting features is out of scope. > >> >>>>>>> > >> >>>>>>> The charter does say: > >> >>>>>>> > >> >>>>>>> Once the device learns of the available white space (e.g., > in a > >> TV > >> >>>>>>> white space implementation, the list of available channels > at > >> that > >> >>>>>>> location), it can then select one of the bands from the = list > >> and > >> >>>>>>> begin to transmit and receive on the selected band. > >> >>>>>>> > >> >>>>>>> This text might have assumed that no further communication > or > >> >>>>>>> authorization was required in order to select one of the > bands > >> from > >> >>>>>>> the list and then transmit/receive. Perhaps that assumption > was > >> >>>>>>> mistaken. If so, it would be good to have a discussion = about > >> that, > >> >>>>>>> so we can determine if we need to revisit the assumptions = we > >> made > >> >>>>>>> early on. If in fact we made some faulty or limited > >> assumptions, > >> >>>>>>> then let's get that out in the open. > >> >>>>>>> > >> >>>>>>> Peter > >> >>>>>>> > >> >>>>>>> On 3/7/12 9:40 AM, Rosen, Brian wrote: > >> >>>>>>>> I'd also suggest that > our > >> >>>>>>>> charter limitation is really support for sharing of > whitespace > >> by > >> >>>>>>>> whitespace devices. Reporting what you use is not = sharing, > >> it's > >> >>>>>>>> just data gathering. > >> >>>>>>>> > >> >>>>>>>> The point of excluding sharing was to eliminate the > >> complexities > >> >>>>>>>> of what constituted fairness, and what kinds of > communication > >> >>>>>>>> might be needed between databases, where more than one > could > >> >>>>>>>> supply available whitespace in a band. This doesn't have > any > >> of > >> >>>>>>>> those issues, As long as it's just sending information, I > >> don't > >> >>>>>>>> have a problem. Once the database is supposed to do > anything > >> >>>>>>>> with it that involves changing what spectrum it reports, > then > >> I > >> >>>>>>>> think we cross the line. > >> >>>>>>>> > >> >>>>>>>> Brian > >> >>>>>>>> > >> >>>>>>>> On Mar 6, 2012, at 12:28 PM, > >> >>>>>>>> wrote: > >> >>>>>>>> > >> >>>>>>>>> Joel > >> >>>>>>>>> > >> >>>>>>>>> Indeed, the regulator has not described the process or > >> provided > >> >>>>>>>>> a flow diagram, so there may be some wrinkles, but we = need > to > >> >>>>>>>>> provide for their intent. To answer your question, the > >> channels > >> >>>>>>>>> that the master will use are sent in a separate message > >> >>>>>>>>> (described in P.12 ter), that occurs after the master > >> receives > >> >>>>>>>>> the response to its channel request, but before the = master > >> can > >> >>>>>>>>> transmit. At this point, it knows what channels are > >> available, > >> >>>>>>>>> and which one it will use. As far as the slaves are > >> concerned, > >> >>>>>>>>> as they associate, the master will need to gather their > >> details > >> >>>>>>>>> and send further channel usage messages to the database = on > >> >>>>>>>>> their behalf. > >> >>>>>>>>> > >> >>>>>>>>> Regards > >> >>>>>>>>> > >> >>>>>>>>> Andy > >> >>>>>>>>> > >> >>>>>>>>> -----Original Message----- From: paws-bounces@ietf.org > >> >>>>>>>>> [mailto:paws-bounces@ietf.org] On Behalf Of Joel M. > Halpern > >> >>>>>>>>> Sent: 06 March 2012 17:05 To: scott.probasco@nokia.com = Cc: > >> >>>>>>>>> paws@ietf.org; Cheeseman,CJ,Chris,COD R; > Dixon,JS,Johnny,COD > >> R > >> >>>>>>>>> Subject: Re: [paws] WGLC for > >> >>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel > >> >>>>>>>>> reporting > >> >>>>>>>>> > >> >>>>>>>>> Ahh. I think I see where the request and my = understanding > >> >>>>>>>>> divurge. If the idea here is that the master must = provide, > in > >> >>>>>>>>> the request, an indication of what channels it expects to > >> use, > >> >>>>>>>>> I can at least understand that. I will return to > technical > >> >>>>>>>>> concerns in a moment. > >> >>>>>>>>> > >> >>>>>>>>> However, when you say "provide channel usage information, > in > >> >>>>>>>>> order to evaluate interference", what that says to me is > >> >>>>>>>>> providing, during operation, information as to what > channels > >> >>>>>>>>> are being used, and at what power levels. That is what > would > >> >>>>>>>>> be needed to analyze actual interference effects. And = that > is > >> >>>>>>>>> out of scope as I understand our scope. > >> >>>>>>>>> > >> >>>>>>>>> I do see a technical difficulty with having the master > >> provide, > >> >>>>>>>>> as part of either registering or requesting spectrum > >> >>>>>>>>> information, what channels it intends to use. It doesn;t > >> know > >> >>>>>>>>> what channels it intends to use. It intends to use some > >> number > >> >>>>>>>>> of available channels. It will figure out which ones = when > it > >> >>>>>>>>> is told what is available. How can it send that > information > >> in > >> >>>>>>>>> the request? > >> >>>>>>>>> > >> >>>>>>>>> Yours, Joel > >> >>>>>>>>> > >> >>>>>>>>> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: > >> >>>>>>>>>> Hi, > >> >>>>>>>>>> > >> >>>>>>>>>> There is a similarity here with device ID. In context of > >> PAWS > >> >>>>>>>>>> we are not concerned with why a device ID is required by > a > >> >>>>>>>>>> regulator, we accept it is a requirement from a = regulator > >> and > >> >>>>>>>>>> include it to the protocol. Ofcom identifies in 3.18& > 3.19 > >> >>>>>>>>>> that channel usage information is required and thus we > need > >> >>>>>>>>>> to include this information. Since the master must > provide > >> >>>>>>>>>> this information prior to transmitting, PAWS will not > >> >>>>>>>>>> function in the UK without this information and thus I > >> >>>>>>>>>> believe channel usage information is integral to the > channel > >> >>>>>>>>>> request& response messaging. > >> >>>>>>>>>> > >> >>>>>>>>>> Kind Regards, Scott > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> On 3/6/12 10:30 AM, "ext Joel M. > >> >>>>>>>>>> Halpern" wrote: > >> >>>>>>>>>> > >> >>>>>>>>>>> I would draw a distinction. Ofcom regulations about > >> >>>>>>>>>>> whitespace requests are very much relevant. Ofcom > >> >>>>>>>>>>> regulations about notification of dynamic behavior > (which > >> >>>>>>>>>>> spectrum is being used) are not in scope as I = understand > >> >>>>>>>>>>> the earlier discussions, particularly the chartering > >> >>>>>>>>>>> discussions. > >> >>>>>>>>>>> > >> >>>>>>>>>>> Yours, Joel > >> >>>>>>>>>>> > >> >>>>>>>>>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> The ofcom requirements are very much relevant to the > >> >>>>>>>>>>>> scope of the PAWS WG. The only other regulatory > >> >>>>>>>>>>>> requirements that we have today is the FCC. Ofcom > >> >>>>>>>>>>>> requirements are a good addition to the set. > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> -Raj > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> On 3/6/12 10:03 AM, "ext > >> >>>>>>>>>>>> andy.sago@bt.com" wrote: > >> >>>>>>>>>>>> > >> >>>>>>>>>>>>> Hi Joel > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> There's no language I can find in the charter that > >> >>>>>>>>>>>>> explicitly puts this out of scope. On the other hand, > >> >>>>>>>>>>>>> the charter says that the group will "consider input > >> >>>>>>>>>>>>> from regulatory entities", and this is one of the > >> >>>>>>>>>>>>> requirements from Ofcom that they have just = published. > >> >>>>>>>>>>>>> The protocol will be worthless for the UK if it omits > >> >>>>>>>>>>>>> some requirements. > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> Regards > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> Andy > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> -----Original Message----- From: Joel M. Halpern > >> >>>>>>>>>>>>> [mailto:jmh@joelhalpern.com] Sent: 06 March 2012 = 15:53 > >> >>>>>>>>>>>>> To: Sago,AJ,Andy,COD R Cc: paws@ietf.org; > >> >>>>>>>>>>>>> Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for > >> >>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: > channel > >> >>>>>>>>>>>>> reporting > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> As I understand, the information you are asking for = is > >> >>>>>>>>>>>>> explicitly out of scope for the working group. Yours, > >> >>>>>>>>>>>>> Joel > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: > >> >>>>>>>>>>>>>> All > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Comparing the draft with the Ofcom requirements at > >> >>>>>>>>>>>>>> http://www.cept.org/Documents/se- > >> >>>>> 43/4161/SE43(12)Info03_Draft-UK-r > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>> egul > >> >>>>>>>>>>>>>> atory-requirements-for-white-space-devices-in-the- > UHF- > >> TV- > >> >>>>> band, > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>> I believe the WG draft is deficient in the area of reporting > >> >>>>>>>>>>>>>> frequencies and powers actually used by masters and > >> >>>>>>>>>>>>>> slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom > >> >>>>>>>>>>>>>> intends to collect this data to assesses the impact > >> >>>>>>>>>>>>>> of aggregate interference into other services. It > >> >>>>>>>>>>>>>> would also provide usage information (frequency in > >> >>>>>>>>>>>>>> use) that would inform the operation of a kill = switch > >> >>>>>>>>>>>>>> capability. I suggest this deficiency can be = remedied > >> >>>>>>>>>>>>>> with the following changes: > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> New P requirements (probably best placed following > >> >>>>>>>>>>>>>> P.12): > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> P.12bis: The protocol MUST support a channel usage > >> >>>>>>>>>>>>>> message from the slave device to the master device. > >> >>>>>>>>>>>>>> The channel usage message MUST include parameters as > >> >>>>>>>>>>>>>> required by local regulatory requirement. These > >> >>>>>>>>>>>>>> parameters MAY include device ID, manufacturer's > >> >>>>>>>>>>>>>> serial number, channel usage and power level > >> >>>>>>>>>>>>>> information. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> P.12ter: The protocol MUST support a channel usage > >> >>>>>>>>>>>>>> message from the master device to the database. The > >> >>>>>>>>>>>>>> channel usage message MUST include parameters as > >> >>>>>>>>>>>>>> required by local regulatory requirement for the > >> >>>>>>>>>>>>>> master and its associated slaves. These parameters > >> >>>>>>>>>>>>>> MAY include device ID, manufacturer's serial number, > >> >>>>>>>>>>>>>> channel usage and power level information. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> P.12qua: The protocol MUST support a channel usage > >> >>>>>>>>>>>>>> message acknowledgement. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> New O requirements (probably best placed following > >> >>>>>>>>>>>>>> O13): > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> O.13bis: According to local regulatory policy, = after > >> >>>>>>>>>>>>>> connecting to a master device's radio network a = slave > >> >>>>>>>>>>>>>> device MAY inform the master device of the actual > >> >>>>>>>>>>>>>> channel usage. The slave MUST include parameters > >> >>>>>>>>>>>>>> required by local regulatory policy, e.g. device ID, > >> >>>>>>>>>>>>>> manufacturer's serial number, channel usage and = power > >> >>>>>>>>>>>>>> level information. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> O.13ter: According to local regulatory policy, a > >> >>>>>>>>>>>>>> master device MAY inform the database of the actual > >> >>>>>>>>>>>>>> channel usage of the master and its slaves. The > >> >>>>>>>>>>>>>> master MUST include parameters required by local > >> >>>>>>>>>>>>>> regulatory policy, e.g. device ID, manufacturer's > >> >>>>>>>>>>>>>> serial number, channel usage and power level > >> >>>>>>>>>>>>>> information of the master and its slaves. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> New steps could be introduced into one or more use > >> >>>>>>>>>>>>>> cases to cover these Ofcom requirements, e.g. new > >> >>>>>>>>>>>>>> steps 6bis and 9bis in the hotspot use case at > >> >>>>>>>>>>>>>> 4.2.1: > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 6bis. Prior to initiating transmission, if required > >> >>>>>>>>>>>>>> by local regulation, the master/AP informs the > >> >>>>>>>>>>>>>> database of the channel and power level it has > >> >>>>>>>>>>>>>> chosen. This is repeated for each slave that > >> >>>>>>>>>>>>>> associated with the master. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 9bis. Prior to initiating transmission, if required > >> >>>>>>>>>>>>>> by local regulation, the slave informs the master/AP > >> >>>>>>>>>>>>>> of the channel and power level it has chosen, and = the > >> >>>>>>>>>>>>>> master/AP relays this information to the database. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> - end of new text - > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> For information, for those not accessing the url in > >> >>>>>>>>>>>>>> the first paragraph of this email, the full Ofcom > >> >>>>>>>>>>>>>> requirements leading to this new PAWS text are as > >> >>>>>>>>>>>>>> follows: > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 3.18 After receiving instructions from a WSDB in > >> >>>>>>>>>>>>>> relation to the maximum permitted EIRPs over the DTT > >> >>>>>>>>>>>>>> channels, and prior to initiating transmissions > >> >>>>>>>>>>>>>> within the UHF TV band, a master WSD must = communicate > >> >>>>>>>>>>>>>> to the WSDB the following information: > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 3.18.1 The lower and upper frequency boundaries^13 = of > >> >>>>>>>>>>>>>> the in-block emissions of the master WSD, and those > >> >>>>>>>>>>>>>> of the in-block emissions of its associated slaves. = A > >> >>>>>>>>>>>>>> lower frequency will be specified as (470 + 8k + > >> >>>>>>>>>>>>>> 0.2n) MHz, with the corresponding upper frequency > >> >>>>>>>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3=AE4 k = 3=AE4 > >> >>>>>>>>>>>>>> 39, 0 3=AE4 n 3=AE4 39, 1 3=AE4 m 3=AE4 40, and n< = m. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 3.18.2 The maximum in-block EIRP spectral densities > >> >>>>>>>>>>>>>> (in dBm/(0.2 MHz)) that the master WSD, and its > >> >>>>>>>>>>>>>> associated slaves, actually radiate between each > >> >>>>>>>>>>>>>> reported lower frequency boundary and its > >> >>>>>>>>>>>>>> corresponding upper frequency boundary. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Footnote 13 states: > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> The use of upper and lower frequency boundaries > >> >>>>>>>>>>>>>> (defined over a 200 kHz raster) allows a WSDB to > >> >>>>>>>>>>>>>> collect more granular information with regards to = the > >> >>>>>>>>>>>>>> usage of the frequency resource by narrowband WSD > >> >>>>>>>>>>>>>> technologies. The upper and lower frequencies of a > >> >>>>>>>>>>>>>> boundary pair do not straddle a DTT channel = boundary. > >> >>>>>>>>>>>>>> Note that a WSD may transmit over multiple, > >> >>>>>>>>>>>>>> non-contiguous, whole DTT channels or fractions of > >> >>>>>>>>>>>>>> DTT channels. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 3.19 A master WSD must be able to receive the > >> >>>>>>>>>>>>>> following information^14 from a WSDB: > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in the > >> >>>>>>>>>>>>>> context of 3.18, that the reported information on = the > >> >>>>>>>>>>>>>> DTT channels and EIRP spectral densities actually > >> >>>>>>>>>>>>>> used by the master and slave WSDs were received > >> >>>>>>>>>>>>>> successfully by the WSDB^18 ]. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Footnote 14 states: > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 14 While the communication of some of this > >> >>>>>>>>>>>>>> information from a WSDB to a master WSD is optional, > >> >>>>>>>>>>>>>> master WSDs must be able to receive and interpret > >> >>>>>>>>>>>>>> these. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Footnote 18 states: > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 18 This forms part of a handshake protocol and may = be > >> >>>>>>>>>>>>>> an area where industry could harmonise without the > >> >>>>>>>>>>>>>> need for an explicit requirement in the regulations. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Regards > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Andy > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> *From:*paws-bounces@ietf.org > >> >>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] *On Behalf Of > >> >>>>>>>>>>>>>> *Gabor.Bajko@nokia.com *Sent:* 05 March 2012 19:46 > >> >>>>>>>>>>>>>> *To:* paws@ietf.org *Subject:* [paws] WGLC for > >> >>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> The authors of the use cases and requirements draft > >> >>>>>>>>>>>>>> have just posted a new version of the draft and > >> >>>>>>>>>>>>>> indicated that there are no unresolved > >> >>>>>>>>>>>>>> comments/issues they are aware of. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Therefore, I'd like to initiate a WG Last Call for > >> >>>>>>>>>>>>>> comments on > >> >>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-paws- > >> problem- > >> >>>>> stmt-u > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>> seca > >> >>>>>>>>>>>>>> ses-rqmts-03.txt > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Please review the draft and send your comments to = the > >> >>>>>>>>>>>>>> list by March 20th, 2012. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> If you review the draft and have no comments, send a > >> >>>>>>>>>>>>>> note to the list that the draft is good as it is, we > >> >>>>>>>>>>>>>> need these notes as much as we need the actual > >> >>>>>>>>>>>>>> comments. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Thanks, Gabor > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> > > >> > _______________________________________________ > >> > paws mailing list > >> > paws@ietf.org > >> > https://www.ietf.org/mailman/listinfo/paws > >> > > >> _______________________________________________ > >> paws mailing list > >> paws@ietf.org > >> https://www.ietf.org/mailman/listinfo/paws > >> > >> _______________________________________________ > >> paws mailing list > >> paws@ietf.org > >> https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ > >paws mailing list > >paws@ietf.org > >https://www.ietf.org/mailman/listinfo/paws From gerald.chouinard@sympatico.ca Thu Mar 8 12:54:11 2012 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 D436F21F85CC for ; Thu, 8 Mar 2012 12:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, MSGID_FROM_MTA_HEADER=0.803, 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 5bIFB0khs0Y8 for ; Thu, 8 Mar 2012 12:54:07 -0800 (PST) Received: from blu0-omc1-s5.blu0.hotmail.com (blu0-omc1-s5.blu0.hotmail.com [65.55.116.16]) by ietfa.amsl.com (Postfix) with ESMTP id 4E96521F8533 for ; Thu, 8 Mar 2012 12:54:05 -0800 (PST) Received: from BLU0-SMTP78 ([65.55.116.7]) by blu0-omc1-s5.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 12:50:03 -0800 X-Originating-IP: [174.95.243.14] X-Originating-Email: [gerald.chouinard@sympatico.ca] Message-ID: Received: from Gerald2 ([174.95.243.14]) by BLU0-SMTP78.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 12:50:02 -0800 From: Gerald Chouinard To: "'Zuniga, Juan Carlos'" , , , References: Date: Thu, 8 Mar 2012 15:49:57 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AQHM/WqaGADtHyPWsUCiCGl6fDpM1pZg3BVAgAAB3ZA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 08 Mar 2012 20:50:02.0436 (UTC) FILETIME=[08984040:01CCFD6D] Cc: paws@ietf.org, presnick@qualcomm.com, johnny.dixon@bt.com, chris.cheeseman@bt.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 20:54:12 -0000 Juan-Carlos, Raz, I agree to keep it to the WSDB. What this data is used for at the WSDB, = be it statistics on spectrum use, more detailed aggregate interference analysis, co-existence, etc., is beyond the scope of PAWS. As long as = the data is provided to the database by this third level of message, the job would be done as far as the protocol is concerned. Gerald -----Original Message----- From: Zuniga, Juan Carlos [mailto:JuanCarlos.Zuniga@InterDigital.com]=20 Sent: Thursday, 08 March, 2012 15:42 To: Basavaraj.Patil@nokia.com; gerald.chouinard@sympatico.ca; jmh@joelhalpern.com; scott.probasco@nokia.com Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; chris.cheeseman@bt.com Subject: RE: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting Hi Raj, I was reusing the language used from Gerald (which I know is familiar to people working on IEEE 802 WS groups): >> [GC] You got it. This would be useless for spectrum regulators. One=20 >> should realize that, from the spectrum regulator's point of view, the = >> second and third messages could be iterated upon to optimize the=20 >> spectrum use. >> Knowing >> what channels the systems in an area are using, the spectrum=20 >> regulators and/or other entities such as those taking care of=20 >> coexistence could use the database in near-real-time to iterate on=20 >> the two last messages to reduce the range of channels that some=20 >> systems may use once they know precisely what channels are being used = >> in the area. The PAWS protocol would carry the information back and=20 >> forth but would not be involved in such spectrum use optimization. Having said that, I have no issue sticking to the WSDB terminology. I = like keeping things simple :) JC > -----Original Message----- > From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] > Sent: Thursday, March 08, 2012 3:33 PM > To: Zuniga, Juan Carlos; gerald.chouinard@sympatico.ca; > jmh@joelhalpern.com; scott.probasco@nokia.com > Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; > chris.cheeseman@bt.com > Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- > rqmts-03:channel reporting >=20 >=20 > Hi JC, >=20 > Where/why did the coexistence manager come into the picture? Your > comment > about "communicating back to the WSDB/coexistence manager" may result > in > further misunderstanding. If we simply stick to to WSDB I think we are > okay. >=20 > -Raj >=20 > On 3/8/12 2:25 PM, "ext Zuniga, Juan Carlos" > wrote: >=20 > >So, from Gerald and Andy's comments, it seems like from the point of > view > >of (at least) two regulatory entities it is important for the = protocol > to > >allow communicating back to the WSDB/coexistence manager the actual > >channel usage after the first query is made. > > > >This is to me a very clear requirement. > > > >The actual messages/IEs that would carry this information should be > >discussed as part of the solution document, and not the requirements. > > > >JC > > > >> -----Original Message----- > >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On = Behalf > Of > >> Gerald Chouinard > >> Sent: Thursday, March 08, 2012 1:59 PM > >> To: 'Joel M. Halpern'; scott.probasco@nokia.com > >> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; > >> chris.cheeseman@bt.com > >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- > >> rqmts-03:channel reporting > >> > >> Joel, Scott, > >> > >> Interesting discussion! See my comments in line below. > >> > >> Gerald > >> > >> -----Original Message----- > >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On = Behalf > Of > >> Joel > >> M. Halpern > >> Sent: Thursday, 08 March, 2012 13:17 > >> To: scott.probasco@nokia.com > >> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; > >> chris.cheeseman@bt.com > >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- > >> rqmts-03: > >> channel reporting > >> > >> So why won't the device simply say "I will use all of this?" > >> [GC] This would defeat the purpose of the acknowledgement message. > >> After all, that way it needs to do less work with the database. = And > it > >> can change frequencies when it wants. > >> Given that the stated goal of the Ofcom requriement was to be able > to > >> analyze interference effects, it seems that this will not actually > lead > >> to them getting what they want, even if it does comply with the > >> regulations. > >> [GC] You got it. This would be useless for spectrum regulators. = One > >> should > >> realize that, from the spectrum regulator's point of view, the > second > >> and > >> third messages could be iterated upon to optimize the spectrum use. > >> Knowing > >> what channels the systems in an area are using, the spectrum > regulators > >> and/or other entities such as those taking care of coexistence = could > >> use the > >> database in near-real-time to iterate on the two last messages to > >> reduce the > >> range of channels that some systems may use once they know = precisely > >> what > >> channels are being used in the area. The PAWS protocol would carry > the > >> information back and forth but would not be involved in such > spectrum > >> use > >> optimization. > >> > >> Yours, > >> joel > >> > >> On 3/8/2012 1:09 PM, scott.probasco@nokia.com wrote: > >> > Hi Peter, > >> > > >> > Answers below. > >> > > >> > Kind Regards, > >> > Scott > >> > > >> > On 3/8/12 11:39 AM, "ext Peter Saint-Andre" > >> wrote: > >> > > >> >> Hi Scott, I have two clarifying questions: > >> >> > >> >> 1. Does the device know, when it receives the channel response, > >> which > >> >> channel it will actually use? > >> > Scott->This is all new and I am not aware of any existing > >> implementations. > >> > I would argue that the device must decide what channel(s) it will > use > >> when > >> > it receives the channel response. > >> [GC] Agree with Scott but this is only a portion of the > considerations. > >> If a > >> device was to operate on its own, this would be true but a > >> communication > >> device usually implies at least 2 devices to communicate. Hence, = the > >> choice > >> of the channel to be used will need to be negotiated between the = two > >> devices > >> before a choice can be made. The chosen channel will belong to the > set > >> of > >> available channels that is common to both devices. Remember that > some > >> channels may be available at one device and not at the other = because > of > >> their geolocation or other reason. Extending this concept to a star > >> network > >> topology, the channel that will be selected by this network will > have > >> to > >> belong to the set of channels that are available to all devices. > Each > >> device > >> will not be able to decide by itself which channel it wants to use. > >> > >> This is why in such a star topology, it makes sense that the slave > >> devices > >> to a base station or access point be represented by the base = station > >> acting > >> as the master on their behalf to query the database and receive the > >> list of > >> available channels (and/or maximum EIRP per channel). It is then = the > >> responsibility of the base station to identify the set of available > >> channels > >> that is common for itself and all its slaves to decide on the > channel > >> that > >> the network will use. As you can see, in this case, there is no = need > >> for > >> each slave to receive its list of available channels. On its own, = it > >> would > >> not know what to do with it. The only thing that needs to be sent > from > >> the > >> master device to its slaves is the resulting operating channel. > >> > >> I a more sophisticated operation, the master device may add one or = a > >> few > >> backup channels extracted from the common set of available channel > to > >> the > >> message going to its slave so that if a change in channel > availability > >> occurs, an instantaneous switch to the next backup channel can be > made > >> without any further signaling, thus providing for a channel switch > that > >> is > >> transparent to the user. It is the scheme that has been included in > the > >> IEEE > >> 802.22-2011 Standard. This is why I don't believe that PAWS should > get > >> involved in defining this signaling between the base station and = its > >> slaves > >> devices. > >> >> > >> >> 2. If the device then uses another channel or a different > channel, > >> does > >> >> it need to report that change to the database? > >> > Scott->My interpretation of section 3.18 is that the device can > only > >> > transmit within the upper& lower frequencies returned in the > >> > acknowledgment. I do not (quickly) find any reference in the > >> requirements > >> > to changing channels. Thus operationally it could be that the > channel > >> > request process must be repeated before the device can use a > >> different > >> > channel (frequencies). > >> [GC] If the process involves 2 messages, then, the device and its > >> associated > >> devices could change channels at will as long as all these channels > >> belong > >> to the set of available channel. However, if the third message is > >> added, it > >> would make sense that the master device reports to the database any > >> channel > >> change that would occur to the database, otherwise, the status of > the > >> spectrum occupation would be wrong at any moment and would be > useless > >> for > >> the purpose of any spectrum usage optimization such as coexistence. > >> >> > >> >> Thanks! > >> >> > >> >> Peter > >> >> > >> >> On 3/8/12 10:17 AM, scott.probasco@nokia.com wrote: > >> >>> Hi, > >> >>> > >> >>> The point from Brian is very relevant: > >> >>> > >> >>> Channel request > >> >>> Channel response > >> >>> Channel acknowledgement > >> >>> > >> >>> What Ofcom does with the information in the acknowledgement = does > >> not > >> >>> matter. As the regulator in UK, they write rules that must be > >> followed > >> >>> in > >> >>> order to operate a whitespace radio in the UK. I believe the > scope > >> of > >> >>> the > >> >>> WG must be focused on a working solution. If this is simple > channel > >> >>> request& response in one regulator's domain, PAWS can support > >> this. If > >> >>> it > >> >>> means a channel request, response and acknowledgement in = another > >> >>> regulator's domain, PAWS can support this. As a participating > >> member of > >> >>> the work group, I believe the scope should be basic working > >> solution, > >> >>> not > >> >>> limited to a specific number of messages. > >> >>> > >> >>> Kind Regards, > >> >>> Scott > >> >>> > >> >>> > >> >>> > >> >>> On 3/8/12 11:11 AM, "ext Zuniga, Juan Carlos" > >> >>> wrote: > >> >>> > >> >>>> Peter, Nancy, > >> >>>> > >> >>>> I agree should design a protocol with the best of our current > >> >>>> knowledge, > >> >>>> and that should be accounting for all the known regulations at > >> present > >> >>>> time. We should not limit the scope with the purpose of > designing > >> a > >> >>>> protocol 'faster'. Our goal is not only to design a WSDB > protocol. > >> Our > >> >>>> goal is to design a WSDB protocol that is USEFUL to the > community. > >> >>>> > >> >>>> The charter does state that > >> >>>> > >> >>>> "...the group should also reach out to other potential > >> >>>> "customers" for a white space database access method and > consider > >> input > >> >>> >from regulatory entities that are involved in the = specification > of > >> the > >> >>>> rules for secondary use of spectrum in specific radio bands. " > >> >>>> > >> >>>> I think that is exactly what we are doing now. > >> >>>> > >> >>>> Regarding whether the types of requirements belong to #1 or = #2, > I > >> >>>> believe > >> >>>> it is more of #1 type, as the information to be exchanged = would > be > >> >>>> known > >> >>>> after the initial query/response. > >> >>>> > >> >>>> If we know it today, I see no reason why we should not work on > it > >> in > >> >>>> the > >> >>>> first phase of the work. > >> >>>> > >> >>>> Regards, > >> >>>> > >> >>>> Juan Carlos > >> >>>> > >> >>>>> -----Original Message----- > >> >>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On > >> Behalf > >> >>>>> Of > >> >>>>> Peter Saint-Andre > >> >>>>> Sent: Thursday, March 08, 2012 11:59 AM > >> >>>>> To: Nancy Bravin > >> >>>>> Cc: paws@ietf.org; johnny.dixon@bt.com; > chris.cheeseman@bt.com; > >> Pete > >> >>>>> Resnick > >> >>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- > >> usecases- > >> >>>>> rqmts-03: channel reporting > >> >>>>> > >> >>>>> Hi Nancy, > >> >>>>> > >> >>>>> You are absolutely right that different locales will have > >> different > >> >>>>> rules and requirements. We need to understand those, and work > to > >> >>>>> address > >> >>>>> them if possible (although we don't necessarily need to > address > >> them > >> >>>>> all > >> >>>>> at the same time). I see several kinds of requirements: > >> >>>>> > >> >>>>> 1. Some requirements might lead to features beyond the > >> query/response > >> >>>>> protocol we've envisioned so far. One example might be real- > time > >> >>>>> reporting about the channels that a device is actually using. > In > >> my > >> >>>>> opinion, it would be best to handle those in the next phase = of > >> work, > >> >>>>> because as far as I can see they are outside the scope of our > >> charter. > >> >>>>> > >> >>>>> 2. Some requirements might be handled through by defining > >> additional > >> >>>>> fields that can be included in the query or response. We > >> definitely > >> >>>>> planned for that when working on the charter with the IESG: > >> >>>>> > >> >>>>> In addition, the particular > >> >>>>> data exchanged between a device and a database might = depend > on > >> the > >> >>>>> ranges of radio spectrum that are to be used, the > requirements > >> of > >> >>>>> the > >> >>>>> database operators and their governing regulations, and > other > >> >>>>> factors. > >> >>>>> Therefore, the database access method and the > query/response > >> data > >> >>>>> formats that are exchanged using that method need to be > >> designed > >> for > >> >>>>> extensibility rather than being tied to any specific > spectrum, > >> >>>>> country, or phy/mac/air interface. > >> >>>>> > >> >>>>> It's unclear to me right now if the Ofcom requirement fits > into > >> #1 or > >> >>>>> #2, which is why we're having this discussion. :) > >> >>>>> > >> >>>>> Peter > >> >>>>> > >> >>>>> On 3/7/12 8:17 PM, Nancy Bravin wrote: > >> >>>>>> Peter and all, > >> >>>>>> > >> >>>>>> I agree that it is important to revisit now, so that in the > >> future, > >> >>>>>> it will be easy to align things in their proper place. Every > >> country > >> >>>>>> may have different regulations, spectrum, policy and what > >> >>>>>> responsibility is in the domain of the system, and what = comes > >> under > >> >>>>>> the PAWS charter is important. Maybe some separation might > be > >> >>>>>> possible, and dividing and clarifying issues now will help = in > >> the > >> >>>>>> future. Certainly it seems that the FCC may change some > rules, > >> and > >> >>>>>> we know that Ofcom is not yet finished with their > regulations. > >> Canada > >> >>>>>> has their own, and other countries are working on this as > well. > >> Just > >> >>>>>> a thought...Sharing is a realistic goal...as is off > loading... > >> Or you > >> >>>>>> slim line and every 6 months decide what to incorporate in > the > >> >>>>>> protocol based on new information, new ideas, new innovation > new > >> >>>>>> regulations and maybe spend more time than you could if > >> addressed > >> >>>>>> now. > >> >>>>>> > >> >>>>>> That way you leave the door open and outside of referencing > what > >> is > >> >>>>>> known today, by referencing regulations i.e. Ofcom, FCC, > >> Industry > >> >>>>>> Canada etc as of XX-XX-XXXX date. Out of scope not something > we > >> know > >> >>>>>> enough about to say at this point, In my opinion. > >> >>>>>> > >> >>>>>> My 2 cents.. > >> >>>>>> > >> >>>>>> Sincerely, Nancy > >> >>>>>> > >> >>>>>> On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote: > >> >>>>>> > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> As your responsible Area Director (until March 28, when = Pete > >> >>>>>>> Resnick will take over from me), I have reviewed this > thread. > >> >>>>>>> > >> >>>>>>> In my opinion (I am happy to be proven wrong), this new > >> requirement > >> >>>>>>> goes beyond what the charter defined as the scope of this > >> working > >> >>>>>>> group, which was to enable a device to discover the white > space > >> >>>>>>> available to it in its current location. Reporting usage > back > >> to > >> >>>>>>> the database is simply not mentioned in the charter. > >> >>>>>>> > >> >>>>>>> Earlier in this thread, Andy Sago wrote: > >> >>>>>>> > >> >>>>>>> There's no language I can find in the charter that > explicitly > >> puts > >> >>>>>>> this out of scope. > >> >>>>>>> > >> >>>>>>> An IETF charter defines what the working group shall work > on. > >> Many > >> >>>>>>> interesting features could be developed here. However, it = is > >> not > >> >>>>>>> the job of the charter to mention explicitly that each of > those > >> >>>>>>> interesting features is out of scope. > >> >>>>>>> > >> >>>>>>> The charter does say: > >> >>>>>>> > >> >>>>>>> Once the device learns of the available white space (e.g., > in a > >> TV > >> >>>>>>> white space implementation, the list of available channels > at > >> that > >> >>>>>>> location), it can then select one of the bands from the = list > >> and > >> >>>>>>> begin to transmit and receive on the selected band. > >> >>>>>>> > >> >>>>>>> This text might have assumed that no further communication > or > >> >>>>>>> authorization was required in order to select one of the > bands > >> from > >> >>>>>>> the list and then transmit/receive. Perhaps that assumption > was > >> >>>>>>> mistaken. If so, it would be good to have a discussion = about > >> that, > >> >>>>>>> so we can determine if we need to revisit the assumptions = we > >> made > >> >>>>>>> early on. If in fact we made some faulty or limited > >> assumptions, > >> >>>>>>> then let's get that out in the open. > >> >>>>>>> > >> >>>>>>> Peter > >> >>>>>>> > >> >>>>>>> On 3/7/12 9:40 AM, Rosen, Brian wrote: > >> >>>>>>>> I'd also suggest that > our > >> >>>>>>>> charter limitation is really support for sharing of > whitespace > >> by > >> >>>>>>>> whitespace devices. Reporting what you use is not = sharing, > >> it's > >> >>>>>>>> just data gathering. > >> >>>>>>>> > >> >>>>>>>> The point of excluding sharing was to eliminate the > >> complexities > >> >>>>>>>> of what constituted fairness, and what kinds of > communication > >> >>>>>>>> might be needed between databases, where more than one > could > >> >>>>>>>> supply available whitespace in a band. This doesn't have > any > >> of > >> >>>>>>>> those issues, As long as it's just sending information, I > >> don't > >> >>>>>>>> have a problem. Once the database is supposed to do > anything > >> >>>>>>>> with it that involves changing what spectrum it reports, > then > >> I > >> >>>>>>>> think we cross the line. > >> >>>>>>>> > >> >>>>>>>> Brian > >> >>>>>>>> > >> >>>>>>>> On Mar 6, 2012, at 12:28 PM, > >> >>>>>>>> wrote: > >> >>>>>>>> > >> >>>>>>>>> Joel > >> >>>>>>>>> > >> >>>>>>>>> Indeed, the regulator has not described the process or > >> provided > >> >>>>>>>>> a flow diagram, so there may be some wrinkles, but we = need > to > >> >>>>>>>>> provide for their intent. To answer your question, the > >> channels > >> >>>>>>>>> that the master will use are sent in a separate message > >> >>>>>>>>> (described in P.12 ter), that occurs after the master > >> receives > >> >>>>>>>>> the response to its channel request, but before the = master > >> can > >> >>>>>>>>> transmit. At this point, it knows what channels are > >> available, > >> >>>>>>>>> and which one it will use. As far as the slaves are > >> concerned, > >> >>>>>>>>> as they associate, the master will need to gather their > >> details > >> >>>>>>>>> and send further channel usage messages to the database = on > >> >>>>>>>>> their behalf. > >> >>>>>>>>> > >> >>>>>>>>> Regards > >> >>>>>>>>> > >> >>>>>>>>> Andy > >> >>>>>>>>> > >> >>>>>>>>> -----Original Message----- From: paws-bounces@ietf.org > >> >>>>>>>>> [mailto:paws-bounces@ietf.org] On Behalf Of Joel M. > Halpern > >> >>>>>>>>> Sent: 06 March 2012 17:05 To: scott.probasco@nokia.com = Cc: > >> >>>>>>>>> paws@ietf.org; Cheeseman,CJ,Chris,COD R; > Dixon,JS,Johnny,COD > >> R > >> >>>>>>>>> Subject: Re: [paws] WGLC for > >> >>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel > >> >>>>>>>>> reporting > >> >>>>>>>>> > >> >>>>>>>>> Ahh. I think I see where the request and my = understanding > >> >>>>>>>>> divurge. If the idea here is that the master must = provide, > in > >> >>>>>>>>> the request, an indication of what channels it expects to > >> use, > >> >>>>>>>>> I can at least understand that. I will return to > technical > >> >>>>>>>>> concerns in a moment. > >> >>>>>>>>> > >> >>>>>>>>> However, when you say "provide channel usage information, > in > >> >>>>>>>>> order to evaluate interference", what that says to me is > >> >>>>>>>>> providing, during operation, information as to what > channels > >> >>>>>>>>> are being used, and at what power levels. That is what > would > >> >>>>>>>>> be needed to analyze actual interference effects. And = that > is > >> >>>>>>>>> out of scope as I understand our scope. > >> >>>>>>>>> > >> >>>>>>>>> I do see a technical difficulty with having the master > >> provide, > >> >>>>>>>>> as part of either registering or requesting spectrum > >> >>>>>>>>> information, what channels it intends to use. It doesn;t > >> know > >> >>>>>>>>> what channels it intends to use. It intends to use some > >> number > >> >>>>>>>>> of available channels. It will figure out which ones = when > it > >> >>>>>>>>> is told what is available. How can it send that > information > >> in > >> >>>>>>>>> the request? > >> >>>>>>>>> > >> >>>>>>>>> Yours, Joel > >> >>>>>>>>> > >> >>>>>>>>> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: > >> >>>>>>>>>> Hi, > >> >>>>>>>>>> > >> >>>>>>>>>> There is a similarity here with device ID. In context of > >> PAWS > >> >>>>>>>>>> we are not concerned with why a device ID is required by > a > >> >>>>>>>>>> regulator, we accept it is a requirement from a = regulator > >> and > >> >>>>>>>>>> include it to the protocol. Ofcom identifies in 3.18& > 3.19 > >> >>>>>>>>>> that channel usage information is required and thus we > need > >> >>>>>>>>>> to include this information. Since the master must > provide > >> >>>>>>>>>> this information prior to transmitting, PAWS will not > >> >>>>>>>>>> function in the UK without this information and thus I > >> >>>>>>>>>> believe channel usage information is integral to the > channel > >> >>>>>>>>>> request& response messaging. > >> >>>>>>>>>> > >> >>>>>>>>>> Kind Regards, Scott > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> On 3/6/12 10:30 AM, "ext Joel M. > >> >>>>>>>>>> Halpern" wrote: > >> >>>>>>>>>> > >> >>>>>>>>>>> I would draw a distinction. Ofcom regulations about > >> >>>>>>>>>>> whitespace requests are very much relevant. Ofcom > >> >>>>>>>>>>> regulations about notification of dynamic behavior > (which > >> >>>>>>>>>>> spectrum is being used) are not in scope as I = understand > >> >>>>>>>>>>> the earlier discussions, particularly the chartering > >> >>>>>>>>>>> discussions. > >> >>>>>>>>>>> > >> >>>>>>>>>>> Yours, Joel > >> >>>>>>>>>>> > >> >>>>>>>>>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> The ofcom requirements are very much relevant to the > >> >>>>>>>>>>>> scope of the PAWS WG. The only other regulatory > >> >>>>>>>>>>>> requirements that we have today is the FCC. Ofcom > >> >>>>>>>>>>>> requirements are a good addition to the set. > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> -Raj > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> On 3/6/12 10:03 AM, "ext > >> >>>>>>>>>>>> andy.sago@bt.com" wrote: > >> >>>>>>>>>>>> > >> >>>>>>>>>>>>> Hi Joel > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> There's no language I can find in the charter that > >> >>>>>>>>>>>>> explicitly puts this out of scope. On the other hand, > >> >>>>>>>>>>>>> the charter says that the group will "consider input > >> >>>>>>>>>>>>> from regulatory entities", and this is one of the > >> >>>>>>>>>>>>> requirements from Ofcom that they have just = published. > >> >>>>>>>>>>>>> The protocol will be worthless for the UK if it omits > >> >>>>>>>>>>>>> some requirements. > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> Regards > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> Andy > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> -----Original Message----- From: Joel M. Halpern > >> >>>>>>>>>>>>> [mailto:jmh@joelhalpern.com] Sent: 06 March 2012 = 15:53 > >> >>>>>>>>>>>>> To: Sago,AJ,Andy,COD R Cc: paws@ietf.org; > >> >>>>>>>>>>>>> Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for > >> >>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: > channel > >> >>>>>>>>>>>>> reporting > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> As I understand, the information you are asking for = is > >> >>>>>>>>>>>>> explicitly out of scope for the working group. Yours, > >> >>>>>>>>>>>>> Joel > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: > >> >>>>>>>>>>>>>> All > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Comparing the draft with the Ofcom requirements at > >> >>>>>>>>>>>>>> http://www.cept.org/Documents/se- > >> >>>>> 43/4161/SE43(12)Info03_Draft-UK-r > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>> egul > >> >>>>>>>>>>>>>> atory-requirements-for-white-space-devices-in-the- > UHF- > >> TV- > >> >>>>> band, > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>> I believe the WG draft is deficient in the area of reporting > >> >>>>>>>>>>>>>> frequencies and powers actually used by masters and > >> >>>>>>>>>>>>>> slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom > >> >>>>>>>>>>>>>> intends to collect this data to assesses the impact > >> >>>>>>>>>>>>>> of aggregate interference into other services. It > >> >>>>>>>>>>>>>> would also provide usage information (frequency in > >> >>>>>>>>>>>>>> use) that would inform the operation of a kill = switch > >> >>>>>>>>>>>>>> capability. I suggest this deficiency can be = remedied > >> >>>>>>>>>>>>>> with the following changes: > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> New P requirements (probably best placed following > >> >>>>>>>>>>>>>> P.12): > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> P.12bis: The protocol MUST support a channel usage > >> >>>>>>>>>>>>>> message from the slave device to the master device. > >> >>>>>>>>>>>>>> The channel usage message MUST include parameters as > >> >>>>>>>>>>>>>> required by local regulatory requirement. These > >> >>>>>>>>>>>>>> parameters MAY include device ID, manufacturer's > >> >>>>>>>>>>>>>> serial number, channel usage and power level > >> >>>>>>>>>>>>>> information. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> P.12ter: The protocol MUST support a channel usage > >> >>>>>>>>>>>>>> message from the master device to the database. The > >> >>>>>>>>>>>>>> channel usage message MUST include parameters as > >> >>>>>>>>>>>>>> required by local regulatory requirement for the > >> >>>>>>>>>>>>>> master and its associated slaves. These parameters > >> >>>>>>>>>>>>>> MAY include device ID, manufacturer's serial number, > >> >>>>>>>>>>>>>> channel usage and power level information. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> P.12qua: The protocol MUST support a channel usage > >> >>>>>>>>>>>>>> message acknowledgement. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> New O requirements (probably best placed following > >> >>>>>>>>>>>>>> O13): > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> O.13bis: According to local regulatory policy, = after > >> >>>>>>>>>>>>>> connecting to a master device's radio network a = slave > >> >>>>>>>>>>>>>> device MAY inform the master device of the actual > >> >>>>>>>>>>>>>> channel usage. The slave MUST include parameters > >> >>>>>>>>>>>>>> required by local regulatory policy, e.g. device ID, > >> >>>>>>>>>>>>>> manufacturer's serial number, channel usage and = power > >> >>>>>>>>>>>>>> level information. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> O.13ter: According to local regulatory policy, a > >> >>>>>>>>>>>>>> master device MAY inform the database of the actual > >> >>>>>>>>>>>>>> channel usage of the master and its slaves. The > >> >>>>>>>>>>>>>> master MUST include parameters required by local > >> >>>>>>>>>>>>>> regulatory policy, e.g. device ID, manufacturer's > >> >>>>>>>>>>>>>> serial number, channel usage and power level > >> >>>>>>>>>>>>>> information of the master and its slaves. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> New steps could be introduced into one or more use > >> >>>>>>>>>>>>>> cases to cover these Ofcom requirements, e.g. new > >> >>>>>>>>>>>>>> steps 6bis and 9bis in the hotspot use case at > >> >>>>>>>>>>>>>> 4.2.1: > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 6bis. Prior to initiating transmission, if required > >> >>>>>>>>>>>>>> by local regulation, the master/AP informs the > >> >>>>>>>>>>>>>> database of the channel and power level it has > >> >>>>>>>>>>>>>> chosen. This is repeated for each slave that > >> >>>>>>>>>>>>>> associated with the master. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 9bis. Prior to initiating transmission, if required > >> >>>>>>>>>>>>>> by local regulation, the slave informs the master/AP > >> >>>>>>>>>>>>>> of the channel and power level it has chosen, and = the > >> >>>>>>>>>>>>>> master/AP relays this information to the database. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> - end of new text - > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> For information, for those not accessing the url in > >> >>>>>>>>>>>>>> the first paragraph of this email, the full Ofcom > >> >>>>>>>>>>>>>> requirements leading to this new PAWS text are as > >> >>>>>>>>>>>>>> follows: > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 3.18 After receiving instructions from a WSDB in > >> >>>>>>>>>>>>>> relation to the maximum permitted EIRPs over the DTT > >> >>>>>>>>>>>>>> channels, and prior to initiating transmissions > >> >>>>>>>>>>>>>> within the UHF TV band, a master WSD must = communicate > >> >>>>>>>>>>>>>> to the WSDB the following information: > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 3.18.1 The lower and upper frequency boundaries^13 = of > >> >>>>>>>>>>>>>> the in-block emissions of the master WSD, and those > >> >>>>>>>>>>>>>> of the in-block emissions of its associated slaves. = A > >> >>>>>>>>>>>>>> lower frequency will be specified as (470 + 8k + > >> >>>>>>>>>>>>>> 0.2n) MHz, with the corresponding upper frequency > >> >>>>>>>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3=AE4 k = 3=AE4 > >> >>>>>>>>>>>>>> 39, 0 3=AE4 n 3=AE4 39, 1 3=AE4 m 3=AE4 40, and n< = m. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 3.18.2 The maximum in-block EIRP spectral densities > >> >>>>>>>>>>>>>> (in dBm/(0.2 MHz)) that the master WSD, and its > >> >>>>>>>>>>>>>> associated slaves, actually radiate between each > >> >>>>>>>>>>>>>> reported lower frequency boundary and its > >> >>>>>>>>>>>>>> corresponding upper frequency boundary. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Footnote 13 states: > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> The use of upper and lower frequency boundaries > >> >>>>>>>>>>>>>> (defined over a 200 kHz raster) allows a WSDB to > >> >>>>>>>>>>>>>> collect more granular information with regards to = the > >> >>>>>>>>>>>>>> usage of the frequency resource by narrowband WSD > >> >>>>>>>>>>>>>> technologies. The upper and lower frequencies of a > >> >>>>>>>>>>>>>> boundary pair do not straddle a DTT channel = boundary. > >> >>>>>>>>>>>>>> Note that a WSD may transmit over multiple, > >> >>>>>>>>>>>>>> non-contiguous, whole DTT channels or fractions of > >> >>>>>>>>>>>>>> DTT channels. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 3.19 A master WSD must be able to receive the > >> >>>>>>>>>>>>>> following information^14 from a WSDB: > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in the > >> >>>>>>>>>>>>>> context of 3.18, that the reported information on = the > >> >>>>>>>>>>>>>> DTT channels and EIRP spectral densities actually > >> >>>>>>>>>>>>>> used by the master and slave WSDs were received > >> >>>>>>>>>>>>>> successfully by the WSDB^18 ]. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Footnote 14 states: > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 14 While the communication of some of this > >> >>>>>>>>>>>>>> information from a WSDB to a master WSD is optional, > >> >>>>>>>>>>>>>> master WSDs must be able to receive and interpret > >> >>>>>>>>>>>>>> these. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Footnote 18 states: > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 18 This forms part of a handshake protocol and may = be > >> >>>>>>>>>>>>>> an area where industry could harmonise without the > >> >>>>>>>>>>>>>> need for an explicit requirement in the regulations. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Regards > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Andy > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> *From:*paws-bounces@ietf.org > >> >>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] *On Behalf Of > >> >>>>>>>>>>>>>> *Gabor.Bajko@nokia.com *Sent:* 05 March 2012 19:46 > >> >>>>>>>>>>>>>> *To:* paws@ietf.org *Subject:* [paws] WGLC for > >> >>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> The authors of the use cases and requirements draft > >> >>>>>>>>>>>>>> have just posted a new version of the draft and > >> >>>>>>>>>>>>>> indicated that there are no unresolved > >> >>>>>>>>>>>>>> comments/issues they are aware of. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Therefore, I'd like to initiate a WG Last Call for > >> >>>>>>>>>>>>>> comments on > >> >>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-paws- > >> problem- > >> >>>>> stmt-u > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>> seca > >> >>>>>>>>>>>>>> ses-rqmts-03.txt > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Please review the draft and send your comments to = the > >> >>>>>>>>>>>>>> list by March 20th, 2012. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> If you review the draft and have no comments, send a > >> >>>>>>>>>>>>>> note to the list that the draft is good as it is, we > >> >>>>>>>>>>>>>> need these notes as much as we need the actual > >> >>>>>>>>>>>>>> comments. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Thanks, Gabor > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> > > >> > _______________________________________________ > >> > paws mailing list > >> > paws@ietf.org > >> > https://www.ietf.org/mailman/listinfo/paws > >> > > >> _______________________________________________ > >> paws mailing list > >> paws@ietf.org > >> https://www.ietf.org/mailman/listinfo/paws > >> > >> _______________________________________________ > >> paws mailing list > >> paws@ietf.org > >> https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ > >paws mailing list > >paws@ietf.org > >https://www.ietf.org/mailman/listinfo/paws From Basavaraj.Patil@nokia.com Thu Mar 8 12:54:12 2012 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 3605F21F85CC for ; Thu, 8 Mar 2012 12:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.8 X-Spam-Level: X-Spam-Status: No, score=-103.8 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4, 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 cOmK3hzkE57x for ; Thu, 8 Mar 2012 12:54:05 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id DFC7F21F8527 for ; Thu, 8 Mar 2012 12:54:00 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q28Kruhk021600; Thu, 8 Mar 2012 22:53:56 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 22:53:56 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.150]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0355.003; Thu, 8 Mar 2012 21:53:55 +0100 From: To: , , , Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting Thread-Index: AQHM/WqaGADtHyPWsUCiCGl6fDpM1pZg3BVAgAAB3ZD//40LgA== Date: Thu, 8 Mar 2012 20:53:55 +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.14.0.111121 x-originating-ip: [172.19.59.135] Content-Type: text/plain; charset="iso-8859-2" Content-ID: <0FA0A1E125797B41A5E740F0EDD2BADE@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Mar 2012 20:53:56.0448 (UTC) FILETIME=[9413A600:01CCFD6D] X-Nokia-AV: Clean Cc: paws@ietf.org, presnick@qualcomm.com, johnny.dixon@bt.com, chris.cheeseman@bt.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 20:54:12 -0000 Agree. Lets keep it simple and stick to the term WSDB in PAWS. Co-existence is a rathole at this point in time which we should studiously avoid. -Raj On 3/8/12 2:49 PM, "ext Gerald Chouinard" wrote: >Juan-Carlos, Raz, > >I agree to keep it to the WSDB. What this data is used for at the WSDB, be >it statistics on spectrum use, more detailed aggregate interference >analysis, co-existence, etc., is beyond the scope of PAWS. As long as the >data is provided to the database by this third level of message, the job >would be done as far as the protocol is concerned. > >Gerald > > >-----Original Message----- >From: Zuniga, Juan Carlos [mailto:JuanCarlos.Zuniga@InterDigital.com] >Sent: Thursday, 08 March, 2012 15:42 >To: Basavaraj.Patil@nokia.com; gerald.chouinard@sympatico.ca; >jmh@joelhalpern.com; scott.probasco@nokia.com >Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >chris.cheeseman@bt.com >Subject: RE: [paws] WGLC for >draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting > >Hi Raj, > >I was reusing the language used from Gerald (which I know is familiar to >people working on IEEE 802 WS groups): > >>> [GC] You got it. This would be useless for spectrum regulators. One >>> should realize that, from the spectrum regulator's point of view, the >>> second and third messages could be iterated upon to optimize the >>> spectrum use. >>> Knowing >>> what channels the systems in an area are using, the spectrum >>> regulators and/or other entities such as those taking care of >>> coexistence could use the database in near-real-time to iterate on >>> the two last messages to reduce the range of channels that some >>> systems may use once they know precisely what channels are being used >>> in the area. The PAWS protocol would carry the information back and >>> forth but would not be involved in such spectrum use optimization. > >Having said that, I have no issue sticking to the WSDB terminology. I like >keeping things simple :) > >JC > >> -----Original Message----- >> From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] >> Sent: Thursday, March 08, 2012 3:33 PM >> To: Zuniga, Juan Carlos; gerald.chouinard@sympatico.ca; >> jmh@joelhalpern.com; scott.probasco@nokia.com >> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >> chris.cheeseman@bt.com >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >> rqmts-03:channel reporting >>=20 >>=20 >> Hi JC, >>=20 >> Where/why did the coexistence manager come into the picture? Your >> comment >> about "communicating back to the WSDB/coexistence manager" may result >> in >> further misunderstanding. If we simply stick to to WSDB I think we are >> okay. >>=20 >> -Raj >>=20 >> On 3/8/12 2:25 PM, "ext Zuniga, Juan Carlos" >> wrote: >>=20 >> >So, from Gerald and Andy's comments, it seems like from the point of >> view >> >of (at least) two regulatory entities it is important for the protocol >> to >> >allow communicating back to the WSDB/coexistence manager the actual >> >channel usage after the first query is made. >> > >> >This is to me a very clear requirement. >> > >> >The actual messages/IEs that would carry this information should be >> >discussed as part of the solution document, and not the requirements. >> > >> >JC >> > >> >> -----Original Message----- >> >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >> Of >> >> Gerald Chouinard >> >> Sent: Thursday, March 08, 2012 1:59 PM >> >> To: 'Joel M. Halpern'; scott.probasco@nokia.com >> >> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >> >> chris.cheeseman@bt.com >> >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >> >> rqmts-03:channel reporting >> >> >> >> Joel, Scott, >> >> >> >> Interesting discussion! See my comments in line below. >> >> >> >> Gerald >> >> >> >> -----Original Message----- >> >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >> Of >> >> Joel >> >> M. Halpern >> >> Sent: Thursday, 08 March, 2012 13:17 >> >> To: scott.probasco@nokia.com >> >> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >> >> chris.cheeseman@bt.com >> >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >> >> rqmts-03: >> >> channel reporting >> >> >> >> So why won't the device simply say "I will use all of this?" >> >> [GC] This would defeat the purpose of the acknowledgement message. >> >> After all, that way it needs to do less work with the database. And >> it >> >> can change frequencies when it wants. >> >> Given that the stated goal of the Ofcom requriement was to be able >> to >> >> analyze interference effects, it seems that this will not actually >> lead >> >> to them getting what they want, even if it does comply with the >> >> regulations. >> >> [GC] You got it. This would be useless for spectrum regulators. One >> >> should >> >> realize that, from the spectrum regulator's point of view, the >> second >> >> and >> >> third messages could be iterated upon to optimize the spectrum use. >> >> Knowing >> >> what channels the systems in an area are using, the spectrum >> regulators >> >> and/or other entities such as those taking care of coexistence could >> >> use the >> >> database in near-real-time to iterate on the two last messages to >> >> reduce the >> >> range of channels that some systems may use once they know precisely >> >> what >> >> channels are being used in the area. The PAWS protocol would carry >> the >> >> information back and forth but would not be involved in such >> spectrum >> >> use >> >> optimization. >> >> >> >> Yours, >> >> joel >> >> >> >> On 3/8/2012 1:09 PM, scott.probasco@nokia.com wrote: >> >> > Hi Peter, >> >> > >> >> > Answers below. >> >> > >> >> > Kind Regards, >> >> > Scott >> >> > >> >> > On 3/8/12 11:39 AM, "ext Peter Saint-Andre" >> >> wrote: >> >> > >> >> >> Hi Scott, I have two clarifying questions: >> >> >> >> >> >> 1. Does the device know, when it receives the channel response, >> >> which >> >> >> channel it will actually use? >> >> > Scott->This is all new and I am not aware of any existing >> >> implementations. >> >> > I would argue that the device must decide what channel(s) it will >> use >> >> when >> >> > it receives the channel response. >> >> [GC] Agree with Scott but this is only a portion of the >> considerations. >> >> If a >> >> device was to operate on its own, this would be true but a >> >> communication >> >> device usually implies at least 2 devices to communicate. Hence, the >> >> choice >> >> of the channel to be used will need to be negotiated between the two >> >> devices >> >> before a choice can be made. The chosen channel will belong to the >> set >> >> of >> >> available channels that is common to both devices. Remember that >> some >> >> channels may be available at one device and not at the other because >> of >> >> their geolocation or other reason. Extending this concept to a star >> >> network >> >> topology, the channel that will be selected by this network will >> have >> >> to >> >> belong to the set of channels that are available to all devices. >> Each >> >> device >> >> will not be able to decide by itself which channel it wants to use. >> >> >> >> This is why in such a star topology, it makes sense that the slave >> >> devices >> >> to a base station or access point be represented by the base station >> >> acting >> >> as the master on their behalf to query the database and receive the >> >> list of >> >> available channels (and/or maximum EIRP per channel). It is then the >> >> responsibility of the base station to identify the set of available >> >> channels >> >> that is common for itself and all its slaves to decide on the >> channel >> >> that >> >> the network will use. As you can see, in this case, there is no need >> >> for >> >> each slave to receive its list of available channels. On its own, it >> >> would >> >> not know what to do with it. The only thing that needs to be sent >> from >> >> the >> >> master device to its slaves is the resulting operating channel. >> >> >> >> I a more sophisticated operation, the master device may add one or a >> >> few >> >> backup channels extracted from the common set of available channel >> to >> >> the >> >> message going to its slave so that if a change in channel >> availability >> >> occurs, an instantaneous switch to the next backup channel can be >> made >> >> without any further signaling, thus providing for a channel switch >> that >> >> is >> >> transparent to the user. It is the scheme that has been included in >> the >> >> IEEE >> >> 802.22-2011 Standard. This is why I don't believe that PAWS should >> get >> >> involved in defining this signaling between the base station and its >> >> slaves >> >> devices. >> >> >> >> >> >> 2. If the device then uses another channel or a different >> channel, >> >> does >> >> >> it need to report that change to the database? >> >> > Scott->My interpretation of section 3.18 is that the device can >> only >> >> > transmit within the upper& lower frequencies returned in the >> >> > acknowledgment. I do not (quickly) find any reference in the >> >> requirements >> >> > to changing channels. Thus operationally it could be that the >> channel >> >> > request process must be repeated before the device can use a >> >> different >> >> > channel (frequencies). >> >> [GC] If the process involves 2 messages, then, the device and its >> >> associated >> >> devices could change channels at will as long as all these channels >> >> belong >> >> to the set of available channel. However, if the third message is >> >> added, it >> >> would make sense that the master device reports to the database any >> >> channel >> >> change that would occur to the database, otherwise, the status of >> the >> >> spectrum occupation would be wrong at any moment and would be >> useless >> >> for >> >> the purpose of any spectrum usage optimization such as coexistence. >> >> >> >> >> >> Thanks! >> >> >> >> >> >> Peter >> >> >> >> >> >> On 3/8/12 10:17 AM, scott.probasco@nokia.com wrote: >> >> >>> Hi, >> >> >>> >> >> >>> The point from Brian is very relevant: >> >> >>> >> >> >>> Channel request >> >> >>> Channel response >> >> >>> Channel acknowledgement >> >> >>> >> >> >>> What Ofcom does with the information in the acknowledgement does >> >> not >> >> >>> matter. As the regulator in UK, they write rules that must be >> >> followed >> >> >>> in >> >> >>> order to operate a whitespace radio in the UK. I believe the >> scope >> >> of >> >> >>> the >> >> >>> WG must be focused on a working solution. If this is simple >> channel >> >> >>> request& response in one regulator's domain, PAWS can support >> >> this. If >> >> >>> it >> >> >>> means a channel request, response and acknowledgement in another >> >> >>> regulator's domain, PAWS can support this. As a participating >> >> member of >> >> >>> the work group, I believe the scope should be basic working >> >> solution, >> >> >>> not >> >> >>> limited to a specific number of messages. >> >> >>> >> >> >>> Kind Regards, >> >> >>> Scott >> >> >>> >> >> >>> >> >> >>> >> >> >>> On 3/8/12 11:11 AM, "ext Zuniga, Juan Carlos" >> >> >>> wrote: >> >> >>> >> >> >>>> Peter, Nancy, >> >> >>>> >> >> >>>> I agree should design a protocol with the best of our current >> >> >>>> knowledge, >> >> >>>> and that should be accounting for all the known regulations at >> >> present >> >> >>>> time. We should not limit the scope with the purpose of >> designing >> >> a >> >> >>>> protocol 'faster'. Our goal is not only to design a WSDB >> protocol. >> >> Our >> >> >>>> goal is to design a WSDB protocol that is USEFUL to the >> community. >> >> >>>> >> >> >>>> The charter does state that >> >> >>>> >> >> >>>> "...the group should also reach out to other potential >> >> >>>> "customers" for a white space database access method and >> consider >> >> input >> >> >>> >from regulatory entities that are involved in the specification >> of >> >> the >> >> >>>> rules for secondary use of spectrum in specific radio bands. " >> >> >>>> >> >> >>>> I think that is exactly what we are doing now. >> >> >>>> >> >> >>>> Regarding whether the types of requirements belong to #1 or #2, >> I >> >> >>>> believe >> >> >>>> it is more of #1 type, as the information to be exchanged would >> be >> >> >>>> known >> >> >>>> after the initial query/response. >> >> >>>> >> >> >>>> If we know it today, I see no reason why we should not work on >> it >> >> in >> >> >>>> the >> >> >>>> first phase of the work. >> >> >>>> >> >> >>>> Regards, >> >> >>>> >> >> >>>> Juan Carlos >> >> >>>> >> >> >>>>> -----Original Message----- >> >> >>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >> >> Behalf >> >> >>>>> Of >> >> >>>>> Peter Saint-Andre >> >> >>>>> Sent: Thursday, March 08, 2012 11:59 AM >> >> >>>>> To: Nancy Bravin >> >> >>>>> Cc: paws@ietf.org; johnny.dixon@bt.com; >> chris.cheeseman@bt.com; >> >> Pete >> >> >>>>> Resnick >> >> >>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- >> >> usecases- >> >> >>>>> rqmts-03: channel reporting >> >> >>>>> >> >> >>>>> Hi Nancy, >> >> >>>>> >> >> >>>>> You are absolutely right that different locales will have >> >> different >> >> >>>>> rules and requirements. We need to understand those, and work >> to >> >> >>>>> address >> >> >>>>> them if possible (although we don't necessarily need to >> address >> >> them >> >> >>>>> all >> >> >>>>> at the same time). I see several kinds of requirements: >> >> >>>>> >> >> >>>>> 1. Some requirements might lead to features beyond the >> >> query/response >> >> >>>>> protocol we've envisioned so far. One example might be real- >> time >> >> >>>>> reporting about the channels that a device is actually using. >> In >> >> my >> >> >>>>> opinion, it would be best to handle those in the next phase of >> >> work, >> >> >>>>> because as far as I can see they are outside the scope of our >> >> charter. >> >> >>>>> >> >> >>>>> 2. Some requirements might be handled through by defining >> >> additional >> >> >>>>> fields that can be included in the query or response. We >> >> definitely >> >> >>>>> planned for that when working on the charter with the IESG: >> >> >>>>> >> >> >>>>> In addition, the particular >> >> >>>>> data exchanged between a device and a database might depend >> on >> >> the >> >> >>>>> ranges of radio spectrum that are to be used, the >> requirements >> >> of >> >> >>>>> the >> >> >>>>> database operators and their governing regulations, and >> other >> >> >>>>> factors. >> >> >>>>> Therefore, the database access method and the >> query/response >> >> data >> >> >>>>> formats that are exchanged using that method need to be >> >> designed >> >> for >> >> >>>>> extensibility rather than being tied to any specific >> spectrum, >> >> >>>>> country, or phy/mac/air interface. >> >> >>>>> >> >> >>>>> It's unclear to me right now if the Ofcom requirement fits >> into >> >> #1 or >> >> >>>>> #2, which is why we're having this discussion. :) >> >> >>>>> >> >> >>>>> Peter >> >> >>>>> >> >> >>>>> On 3/7/12 8:17 PM, Nancy Bravin wrote: >> >> >>>>>> Peter and all, >> >> >>>>>> >> >> >>>>>> I agree that it is important to revisit now, so that in the >> >> future, >> >> >>>>>> it will be easy to align things in their proper place. Every >> >> country >> >> >>>>>> may have different regulations, spectrum, policy and what >> >> >>>>>> responsibility is in the domain of the system, and what comes >> >> under >> >> >>>>>> the PAWS charter is important. Maybe some separation might >> be >> >> >>>>>> possible, and dividing and clarifying issues now will help in >> >> the >> >> >>>>>> future. Certainly it seems that the FCC may change some >> rules, >> >> and >> >> >>>>>> we know that Ofcom is not yet finished with their >> regulations. >> >> Canada >> >> >>>>>> has their own, and other countries are working on this as >> well. >> >> Just >> >> >>>>>> a thought...Sharing is a realistic goal...as is off >> loading... >> >> Or you >> >> >>>>>> slim line and every 6 months decide what to incorporate in >> the >> >> >>>>>> protocol based on new information, new ideas, new innovation >> new >> >> >>>>>> regulations and maybe spend more time than you could if >> >> addressed >> >> >>>>>> now. >> >> >>>>>> >> >> >>>>>> That way you leave the door open and outside of referencing >> what >> >> is >> >> >>>>>> known today, by referencing regulations i.e. Ofcom, FCC, >> >> Industry >> >> >>>>>> Canada etc as of XX-XX-XXXX date. Out of scope not something >> we >> >> know >> >> >>>>>> enough about to say at this point, In my opinion. >> >> >>>>>> >> >> >>>>>> My 2 cents.. >> >> >>>>>> >> >> >>>>>> Sincerely, Nancy >> >> >>>>>> >> >> >>>>>> On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote: >> >> >>>>>> >> >> >>>>>>> >> >> >>>>>>> >> >> >>>>>>> As your responsible Area Director (until March 28, when Pete >> >> >>>>>>> Resnick will take over from me), I have reviewed this >> thread. >> >> >>>>>>> >> >> >>>>>>> In my opinion (I am happy to be proven wrong), this new >> >> requirement >> >> >>>>>>> goes beyond what the charter defined as the scope of this >> >> working >> >> >>>>>>> group, which was to enable a device to discover the white >> space >> >> >>>>>>> available to it in its current location. Reporting usage >> back >> >> to >> >> >>>>>>> the database is simply not mentioned in the charter. >> >> >>>>>>> >> >> >>>>>>> Earlier in this thread, Andy Sago wrote: >> >> >>>>>>> >> >> >>>>>>> There's no language I can find in the charter that >> explicitly >> >> puts >> >> >>>>>>> this out of scope. >> >> >>>>>>> >> >> >>>>>>> An IETF charter defines what the working group shall work >> on. >> >> Many >> >> >>>>>>> interesting features could be developed here. However, it is >> >> not >> >> >>>>>>> the job of the charter to mention explicitly that each of >> those >> >> >>>>>>> interesting features is out of scope. >> >> >>>>>>> >> >> >>>>>>> The charter does say: >> >> >>>>>>> >> >> >>>>>>> Once the device learns of the available white space (e.g., >> in a >> >> TV >> >> >>>>>>> white space implementation, the list of available channels >> at >> >> that >> >> >>>>>>> location), it can then select one of the bands from the list >> >> and >> >> >>>>>>> begin to transmit and receive on the selected band. >> >> >>>>>>> >> >> >>>>>>> This text might have assumed that no further communication >> or >> >> >>>>>>> authorization was required in order to select one of the >> bands >> >> from >> >> >>>>>>> the list and then transmit/receive. Perhaps that assumption >> was >> >> >>>>>>> mistaken. If so, it would be good to have a discussion about >> >> that, >> >> >>>>>>> so we can determine if we need to revisit the assumptions we >> >> made >> >> >>>>>>> early on. If in fact we made some faulty or limited >> >> assumptions, >> >> >>>>>>> then let's get that out in the open. >> >> >>>>>>> >> >> >>>>>>> Peter >> >> >>>>>>> >> >> >>>>>>> On 3/7/12 9:40 AM, Rosen, Brian wrote: >> >> >>>>>>>> I'd also suggest that >> our >> >> >>>>>>>> charter limitation is really support for sharing of >> whitespace >> >> by >> >> >>>>>>>> whitespace devices. Reporting what you use is not sharing, >> >> it's >> >> >>>>>>>> just data gathering. >> >> >>>>>>>> >> >> >>>>>>>> The point of excluding sharing was to eliminate the >> >> complexities >> >> >>>>>>>> of what constituted fairness, and what kinds of >> communication >> >> >>>>>>>> might be needed between databases, where more than one >> could >> >> >>>>>>>> supply available whitespace in a band. This doesn't have >> any >> >> of >> >> >>>>>>>> those issues, As long as it's just sending information, I >> >> don't >> >> >>>>>>>> have a problem. Once the database is supposed to do >> anything >> >> >>>>>>>> with it that involves changing what spectrum it reports, >> then >> >> I >> >> >>>>>>>> think we cross the line. >> >> >>>>>>>> >> >> >>>>>>>> Brian >> >> >>>>>>>> >> >> >>>>>>>> On Mar 6, 2012, at 12:28 PM, >> >> >>>>>>>> wrote: >> >> >>>>>>>> >> >> >>>>>>>>> Joel >> >> >>>>>>>>> >> >> >>>>>>>>> Indeed, the regulator has not described the process or >> >> provided >> >> >>>>>>>>> a flow diagram, so there may be some wrinkles, but we need >> to >> >> >>>>>>>>> provide for their intent. To answer your question, the >> >> channels >> >> >>>>>>>>> that the master will use are sent in a separate message >> >> >>>>>>>>> (described in P.12 ter), that occurs after the master >> >> receives >> >> >>>>>>>>> the response to its channel request, but before the master >> >> can >> >> >>>>>>>>> transmit. At this point, it knows what channels are >> >> available, >> >> >>>>>>>>> and which one it will use. As far as the slaves are >> >> concerned, >> >> >>>>>>>>> as they associate, the master will need to gather their >> >> details >> >> >>>>>>>>> and send further channel usage messages to the database on >> >> >>>>>>>>> their behalf. >> >> >>>>>>>>> >> >> >>>>>>>>> Regards >> >> >>>>>>>>> >> >> >>>>>>>>> Andy >> >> >>>>>>>>> >> >> >>>>>>>>> -----Original Message----- From: paws-bounces@ietf.org >> >> >>>>>>>>> [mailto:paws-bounces@ietf.org] On Behalf Of Joel M. >> Halpern >> >> >>>>>>>>> Sent: 06 March 2012 17:05 To: scott.probasco@nokia.com Cc: >> >> >>>>>>>>> paws@ietf.org; Cheeseman,CJ,Chris,COD R; >> Dixon,JS,Johnny,COD >> >> R >> >> >>>>>>>>> Subject: Re: [paws] WGLC for >> >> >>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel >> >> >>>>>>>>> reporting >> >> >>>>>>>>> >> >> >>>>>>>>> Ahh. I think I see where the request and my understanding >> >> >>>>>>>>> divurge. If the idea here is that the master must provide, >> in >> >> >>>>>>>>> the request, an indication of what channels it expects to >> >> use, >> >> >>>>>>>>> I can at least understand that. I will return to >> technical >> >> >>>>>>>>> concerns in a moment. >> >> >>>>>>>>> >> >> >>>>>>>>> However, when you say "provide channel usage information, >> in >> >> >>>>>>>>> order to evaluate interference", what that says to me is >> >> >>>>>>>>> providing, during operation, information as to what >> channels >> >> >>>>>>>>> are being used, and at what power levels. That is what >> would >> >> >>>>>>>>> be needed to analyze actual interference effects. And that >> is >> >> >>>>>>>>> out of scope as I understand our scope. >> >> >>>>>>>>> >> >> >>>>>>>>> I do see a technical difficulty with having the master >> >> provide, >> >> >>>>>>>>> as part of either registering or requesting spectrum >> >> >>>>>>>>> information, what channels it intends to use. It doesn;t >> >> know >> >> >>>>>>>>> what channels it intends to use. It intends to use some >> >> number >> >> >>>>>>>>> of available channels. It will figure out which ones when >> it >> >> >>>>>>>>> is told what is available. How can it send that >> information >> >> in >> >> >>>>>>>>> the request? >> >> >>>>>>>>> >> >> >>>>>>>>> Yours, Joel >> >> >>>>>>>>> >> >> >>>>>>>>> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: >> >> >>>>>>>>>> Hi, >> >> >>>>>>>>>> >> >> >>>>>>>>>> There is a similarity here with device ID. In context of >> >> PAWS >> >> >>>>>>>>>> we are not concerned with why a device ID is required by >> a >> >> >>>>>>>>>> regulator, we accept it is a requirement from a regulator >> >> and >> >> >>>>>>>>>> include it to the protocol. Ofcom identifies in 3.18& >> 3.19 >> >> >>>>>>>>>> that channel usage information is required and thus we >> need >> >> >>>>>>>>>> to include this information. Since the master must >> provide >> >> >>>>>>>>>> this information prior to transmitting, PAWS will not >> >> >>>>>>>>>> function in the UK without this information and thus I >> >> >>>>>>>>>> believe channel usage information is integral to the >> channel >> >> >>>>>>>>>> request& response messaging. >> >> >>>>>>>>>> >> >> >>>>>>>>>> Kind Regards, Scott >> >> >>>>>>>>>> >> >> >>>>>>>>>> >> >> >>>>>>>>>> On 3/6/12 10:30 AM, "ext Joel M. >> >> >>>>>>>>>> Halpern" wrote: >> >> >>>>>>>>>> >> >> >>>>>>>>>>> I would draw a distinction. Ofcom regulations about >> >> >>>>>>>>>>> whitespace requests are very much relevant. Ofcom >> >> >>>>>>>>>>> regulations about notification of dynamic behavior >> (which >> >> >>>>>>>>>>> spectrum is being used) are not in scope as I understand >> >> >>>>>>>>>>> the earlier discussions, particularly the chartering >> >> >>>>>>>>>>> discussions. >> >> >>>>>>>>>>> >> >> >>>>>>>>>>> Yours, Joel >> >> >>>>>>>>>>> >> >> >>>>>>>>>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: >> >> >>>>>>>>>>>> >> >> >>>>>>>>>>>> The ofcom requirements are very much relevant to the >> >> >>>>>>>>>>>> scope of the PAWS WG. The only other regulatory >> >> >>>>>>>>>>>> requirements that we have today is the FCC. Ofcom >> >> >>>>>>>>>>>> requirements are a good addition to the set. >> >> >>>>>>>>>>>> >> >> >>>>>>>>>>>> -Raj >> >> >>>>>>>>>>>> >> >> >>>>>>>>>>>> On 3/6/12 10:03 AM, "ext >> >> >>>>>>>>>>>> andy.sago@bt.com" wrote: >> >> >>>>>>>>>>>> >> >> >>>>>>>>>>>>> Hi Joel >> >> >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> There's no language I can find in the charter that >> >> >>>>>>>>>>>>> explicitly puts this out of scope. On the other hand, >> >> >>>>>>>>>>>>> the charter says that the group will "consider input >> >> >>>>>>>>>>>>> from regulatory entities", and this is one of the >> >> >>>>>>>>>>>>> requirements from Ofcom that they have just published. >> >> >>>>>>>>>>>>> The protocol will be worthless for the UK if it omits >> >> >>>>>>>>>>>>> some requirements. >> >> >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> Regards >> >> >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> Andy >> >> >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> -----Original Message----- From: Joel M. Halpern >> >> >>>>>>>>>>>>> [mailto:jmh@joelhalpern.com] Sent: 06 March 2012 15:53 >> >> >>>>>>>>>>>>> To: Sago,AJ,Andy,COD R Cc: paws@ietf.org; >> >> >>>>>>>>>>>>> Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for >> >> >>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: >> channel >> >> >>>>>>>>>>>>> reporting >> >> >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> As I understand, the information you are asking for is >> >> >>>>>>>>>>>>> explicitly out of scope for the working group. Yours, >> >> >>>>>>>>>>>>> Joel >> >> >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >> >> >>>>>>>>>>>>>> All >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Comparing the draft with the Ofcom requirements at >> >> >>>>>>>>>>>>>> http://www.cept.org/Documents/se- >> >> >>>>> 43/4161/SE43(12)Info03_Draft-UK-r >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> >>>>> egul >> >> >>>>>>>>>>>>>> atory-requirements-for-white-space-devices-in-the- >> UHF- >> >> TV- >> >> >>>>> band, >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> >>>>> I believe the WG draft is deficient in the area of reporting >> >> >>>>>>>>>>>>>> frequencies and powers actually used by masters and >> >> >>>>>>>>>>>>>> slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom >> >> >>>>>>>>>>>>>> intends to collect this data to assesses the impact >> >> >>>>>>>>>>>>>> of aggregate interference into other services. It >> >> >>>>>>>>>>>>>> would also provide usage information (frequency in >> >> >>>>>>>>>>>>>> use) that would inform the operation of a kill switch >> >> >>>>>>>>>>>>>> capability. I suggest this deficiency can be remedied >> >> >>>>>>>>>>>>>> with the following changes: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> New P requirements (probably best placed following >> >> >>>>>>>>>>>>>> P.12): >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> P.12bis: The protocol MUST support a channel usage >> >> >>>>>>>>>>>>>> message from the slave device to the master device. >> >> >>>>>>>>>>>>>> The channel usage message MUST include parameters as >> >> >>>>>>>>>>>>>> required by local regulatory requirement. These >> >> >>>>>>>>>>>>>> parameters MAY include device ID, manufacturer's >> >> >>>>>>>>>>>>>> serial number, channel usage and power level >> >> >>>>>>>>>>>>>> information. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> P.12ter: The protocol MUST support a channel usage >> >> >>>>>>>>>>>>>> message from the master device to the database. The >> >> >>>>>>>>>>>>>> channel usage message MUST include parameters as >> >> >>>>>>>>>>>>>> required by local regulatory requirement for the >> >> >>>>>>>>>>>>>> master and its associated slaves. These parameters >> >> >>>>>>>>>>>>>> MAY include device ID, manufacturer's serial number, >> >> >>>>>>>>>>>>>> channel usage and power level information. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> P.12qua: The protocol MUST support a channel usage >> >> >>>>>>>>>>>>>> message acknowledgement. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> New O requirements (probably best placed following >> >> >>>>>>>>>>>>>> O13): >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> O.13bis: According to local regulatory policy, after >> >> >>>>>>>>>>>>>> connecting to a master device's radio network a slave >> >> >>>>>>>>>>>>>> device MAY inform the master device of the actual >> >> >>>>>>>>>>>>>> channel usage. The slave MUST include parameters >> >> >>>>>>>>>>>>>> required by local regulatory policy, e.g. device ID, >> >> >>>>>>>>>>>>>> manufacturer's serial number, channel usage and power >> >> >>>>>>>>>>>>>> level information. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> O.13ter: According to local regulatory policy, a >> >> >>>>>>>>>>>>>> master device MAY inform the database of the actual >> >> >>>>>>>>>>>>>> channel usage of the master and its slaves. The >> >> >>>>>>>>>>>>>> master MUST include parameters required by local >> >> >>>>>>>>>>>>>> regulatory policy, e.g. device ID, manufacturer's >> >> >>>>>>>>>>>>>> serial number, channel usage and power level >> >> >>>>>>>>>>>>>> information of the master and its slaves. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> New steps could be introduced into one or more use >> >> >>>>>>>>>>>>>> cases to cover these Ofcom requirements, e.g. new >> >> >>>>>>>>>>>>>> steps 6bis and 9bis in the hotspot use case at >> >> >>>>>>>>>>>>>> 4.2.1: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 6bis. Prior to initiating transmission, if required >> >> >>>>>>>>>>>>>> by local regulation, the master/AP informs the >> >> >>>>>>>>>>>>>> database of the channel and power level it has >> >> >>>>>>>>>>>>>> chosen. This is repeated for each slave that >> >> >>>>>>>>>>>>>> associated with the master. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 9bis. Prior to initiating transmission, if required >> >> >>>>>>>>>>>>>> by local regulation, the slave informs the master/AP >> >> >>>>>>>>>>>>>> of the channel and power level it has chosen, and the >> >> >>>>>>>>>>>>>> master/AP relays this information to the database. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> - end of new text - >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> For information, for those not accessing the url in >> >> >>>>>>>>>>>>>> the first paragraph of this email, the full Ofcom >> >> >>>>>>>>>>>>>> requirements leading to this new PAWS text are as >> >> >>>>>>>>>>>>>> follows: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 3.18 After receiving instructions from a WSDB in >> >> >>>>>>>>>>>>>> relation to the maximum permitted EIRPs over the DTT >> >> >>>>>>>>>>>>>> channels, and prior to initiating transmissions >> >> >>>>>>>>>>>>>> within the UHF TV band, a master WSD must communicate >> >> >>>>>>>>>>>>>> to the WSDB the following information: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 3.18.1 The lower and upper frequency boundaries^13 of >> >> >>>>>>>>>>>>>> the in-block emissions of the master WSD, and those >> >> >>>>>>>>>>>>>> of the in-block emissions of its associated slaves. A >> >> >>>>>>>>>>>>>> lower frequency will be specified as (470 + 8k + >> >> >>>>>>>>>>>>>> 0.2n) MHz, with the corresponding upper frequency >> >> >>>>>>>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3=AE4 k 3= =AE4 >> >> >>>>>>>>>>>>>> 39, 0 3=AE4 n 3=AE4 39, 1 3=AE4 m 3=AE4 40, and n< = m. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 3.18.2 The maximum in-block EIRP spectral densities >> >> >>>>>>>>>>>>>> (in dBm/(0.2 MHz)) that the master WSD, and its >> >> >>>>>>>>>>>>>> associated slaves, actually radiate between each >> >> >>>>>>>>>>>>>> reported lower frequency boundary and its >> >> >>>>>>>>>>>>>> corresponding upper frequency boundary. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Footnote 13 states: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> The use of upper and lower frequency boundaries >> >> >>>>>>>>>>>>>> (defined over a 200 kHz raster) allows a WSDB to >> >> >>>>>>>>>>>>>> collect more granular information with regards to the >> >> >>>>>>>>>>>>>> usage of the frequency resource by narrowband WSD >> >> >>>>>>>>>>>>>> technologies. The upper and lower frequencies of a >> >> >>>>>>>>>>>>>> boundary pair do not straddle a DTT channel boundary. >> >> >>>>>>>>>>>>>> Note that a WSD may transmit over multiple, >> >> >>>>>>>>>>>>>> non-contiguous, whole DTT channels or fractions of >> >> >>>>>>>>>>>>>> DTT channels. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 3.19 A master WSD must be able to receive the >> >> >>>>>>>>>>>>>> following information^14 from a WSDB: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in the >> >> >>>>>>>>>>>>>> context of 3.18, that the reported information on the >> >> >>>>>>>>>>>>>> DTT channels and EIRP spectral densities actually >> >> >>>>>>>>>>>>>> used by the master and slave WSDs were received >> >> >>>>>>>>>>>>>> successfully by the WSDB^18 ]. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Footnote 14 states: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 14 While the communication of some of this >> >> >>>>>>>>>>>>>> information from a WSDB to a master WSD is optional, >> >> >>>>>>>>>>>>>> master WSDs must be able to receive and interpret >> >> >>>>>>>>>>>>>> these. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Footnote 18 states: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 18 This forms part of a handshake protocol and may be >> >> >>>>>>>>>>>>>> an area where industry could harmonise without the >> >> >>>>>>>>>>>>>> need for an explicit requirement in the regulations. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Regards >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Andy >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> *From:*paws-bounces@ietf.org >> >> >>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] *On Behalf Of >> >> >>>>>>>>>>>>>> *Gabor.Bajko@nokia.com *Sent:* 05 March 2012 19:46 >> >> >>>>>>>>>>>>>> *To:* paws@ietf.org *Subject:* [paws] WGLC for >> >> >>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> The authors of the use cases and requirements draft >> >> >>>>>>>>>>>>>> have just posted a new version of the draft and >> >> >>>>>>>>>>>>>> indicated that there are no unresolved >> >> >>>>>>>>>>>>>> comments/issues they are aware of. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Therefore, I'd like to initiate a WG Last Call for >> >> >>>>>>>>>>>>>> comments on >> >> >>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-paws- >> >> problem- >> >> >>>>> stmt-u >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> >>>>> seca >> >> >>>>>>>>>>>>>> ses-rqmts-03.txt >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Please review the draft and send your comments to the >> >> >>>>>>>>>>>>>> list by March 20th, 2012. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> If you review the draft and have no comments, send a >> >> >>>>>>>>>>>>>> note to the list that the draft is good as it is, we >> >> >>>>>>>>>>>>>> need these notes as much as we need the actual >> >> >>>>>>>>>>>>>> comments. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Thanks, Gabor >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> > >> >> > _______________________________________________ >> >> > paws mailing list >> >> > paws@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/paws >> >> > >> >> _______________________________________________ >> >> paws mailing list >> >> paws@ietf.org >> >> https://www.ietf.org/mailman/listinfo/paws >> >> >> >> _______________________________________________ >> >> paws mailing list >> >> paws@ietf.org >> >> https://www.ietf.org/mailman/listinfo/paws >> >_______________________________________________ >> >paws mailing list >> >paws@ietf.org >> >https://www.ietf.org/mailman/listinfo/paws > > From SiewYoon.Tan@ofcom.org.uk Thu Mar 8 13:06:58 2012 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 867AF21F8698 for ; Thu, 8 Mar 2012 13:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.971 X-Spam-Level: X-Spam-Status: No, score=-0.971 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=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 PBuedT7YebL4 for ; Thu, 8 Mar 2012 13:06:56 -0800 (PST) Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.242]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9C021F8694 for ; Thu, 8 Mar 2012 13:06:55 -0800 (PST) Received: from [85.158.143.35:56652] by server-2.bemta-4.messagelabs.com id 0F/76-17550-E6F195F4; Thu, 08 Mar 2012 21:06:54 +0000 X-Env-Sender: SiewYoon.Tan@ofcom.org.uk X-Msg-Ref: server-5.tower-21.messagelabs.com!1331240813!3430524!2 X-Originating-IP: [194.33.160.65] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20437 invoked from network); 8 Mar 2012 21:06:53 -0000 Received: from unknown (HELO WOK-INTRA-EDG02.intra.ofcom.local) (194.33.160.65) by server-5.tower-21.messagelabs.com with AES128-SHA encrypted SMTP; 8 Mar 2012 21:06:53 -0000 Received: from WOK-INTRA-EXC01.intra.ofcom.local (10.130.130.67) by WOK-INTRA-EDG02.intra.ofcom.local (10.130.239.20) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 8 Mar 2012 21:06:53 +0000 Received: from WOK-INTRA-EXC02.intra.ofcom.local ([fe80::550e:933d:224e:6a19]) by WOK-INTRA-EXC01.intra.ofcom.local ([fe80::f0b6:2506:a722:c58b%15]) with mapi id 14.01.0289.001; Thu, 8 Mar 2012 21:05:47 +0000 From: Siew Yoon Tan To: "Zuniga, Juan Carlos" , "Basavaraj.Patil@nokia.com" , "gerald.chouinard@sympatico.ca" , "jmh@joelhalpern.com" , "scott.probasco@nokia.com" Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting Thread-Index: AQHM/WviNpCv+n9H8keCAeTMh9mY+ZZg3YAS Date: Thu, 8 Mar 2012 21:05:46 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.239.247] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 08 Mar 2012 15:15:06 -0800 Cc: "paws@ietf.org" , "presnick@qualcomm.com" , Reza Karimi , "johnny.dixon@bt.com" , "chris.cheeseman@bt.com" Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 21:06:58 -0000 Dear All, Regarding Ofcom's requirement to have a return channel as part of the proto= col between the WSD and WSDB, I would like to confirm to following sequence= of messaging Channel request Channel response Channel acknowledgement which was raised in an earlier email to this list. Our view is that it would be beneficial to define the protocol between WSD = and WSDB that supports this requirement even though how the information cou= ld be used is still subject to discussion in the UK. Best regards, Siew Yoon ________________________________________ From: paws-bounces@ietf.org [paws-bounces@ietf.org] on behalf of Zuniga, Ju= an Carlos [JuanCarlos.Zuniga@InterDigital.com] Sent: 08 March 2012 20:41 To: Basavaraj.Patil@nokia.com; gerald.chouinard@sympatico.ca; jmh@joelhalpe= rn.com; scott.probasco@nokia.com Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; chris.cheese= man@bt.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts= -03:channel reporting Hi Raj, I was reusing the language used from Gerald (which I know is familiar to pe= ople working on IEEE 802 WS groups): >> [GC] You got it. This would be useless for spectrum regulators. One >> should realize that, from the spectrum regulator's point of view, the >> second and third messages could be iterated upon to optimize the >> spectrum use. >> Knowing >> what channels the systems in an area are using, the spectrum >> regulators and/or other entities such as those taking care of >> coexistence could use the database in near-real-time to iterate on >> the two last messages to reduce the range of channels that some >> systems may use once they know precisely what channels are being used >> in the area. The PAWS protocol would carry the information back and >> forth but would not be involved in such spectrum use optimization. Having said that, I have no issue sticking to the WSDB terminology. I like = keeping things simple :) JC > -----Original Message----- > From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] > Sent: Thursday, March 08, 2012 3:33 PM > To: Zuniga, Juan Carlos; gerald.chouinard@sympatico.ca; > jmh@joelhalpern.com; scott.probasco@nokia.com > Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; > chris.cheeseman@bt.com > Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- > rqmts-03:channel reporting > > > Hi JC, > > Where/why did the coexistence manager come into the picture? Your > comment > about "communicating back to the WSDB/coexistence manager" may result > in > further misunderstanding. If we simply stick to to WSDB I think we are > okay. > > -Raj > > On 3/8/12 2:25 PM, "ext Zuniga, Juan Carlos" > wrote: > > >So, from Gerald and Andy's comments, it seems like from the point of > view > >of (at least) two regulatory entities it is important for the protocol > to > >allow communicating back to the WSDB/coexistence manager the actual > >channel usage after the first query is made. > > > >This is to me a very clear requirement. > > > >The actual messages/IEs that would carry this information should be > >discussed as part of the solution document, and not the requirements. > > > >JC > > > >> -----Original Message----- > >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf > Of > >> Gerald Chouinard > >> Sent: Thursday, March 08, 2012 1:59 PM > >> To: 'Joel M. Halpern'; scott.probasco@nokia.com > >> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; > >> chris.cheeseman@bt.com > >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- > >> rqmts-03:channel reporting > >> > >> Joel, Scott, > >> > >> Interesting discussion! See my comments in line below. > >> > >> Gerald > >> > >> -----Original Message----- > >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf > Of > >> Joel > >> M. Halpern > >> Sent: Thursday, 08 March, 2012 13:17 > >> To: scott.probasco@nokia.com > >> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; > >> chris.cheeseman@bt.com > >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- > >> rqmts-03: > >> channel reporting > >> > >> So why won't the device simply say "I will use all of this?" > >> [GC] This would defeat the purpose of the acknowledgement message. > >> After all, that way it needs to do less work with the database. And > it > >> can change frequencies when it wants. > >> Given that the stated goal of the Ofcom requriement was to be able > to > >> analyze interference effects, it seems that this will not actually > lead > >> to them getting what they want, even if it does comply with the > >> regulations. > >> [GC] You got it. This would be useless for spectrum regulators. One > >> should > >> realize that, from the spectrum regulator's point of view, the > second > >> and > >> third messages could be iterated upon to optimize the spectrum use. > >> Knowing > >> what channels the systems in an area are using, the spectrum > regulators > >> and/or other entities such as those taking care of coexistence could > >> use the > >> database in near-real-time to iterate on the two last messages to > >> reduce the > >> range of channels that some systems may use once they know precisely > >> what > >> channels are being used in the area. The PAWS protocol would carry > the > >> information back and forth but would not be involved in such > spectrum > >> use > >> optimization. > >> > >> Yours, > >> joel > >> > >> On 3/8/2012 1:09 PM, scott.probasco@nokia.com wrote: > >> > Hi Peter, > >> > > >> > Answers below. > >> > > >> > Kind Regards, > >> > Scott > >> > > >> > On 3/8/12 11:39 AM, "ext Peter Saint-Andre" > >> wrote: > >> > > >> >> Hi Scott, I have two clarifying questions: > >> >> > >> >> 1. Does the device know, when it receives the channel response, > >> which > >> >> channel it will actually use? > >> > Scott->This is all new and I am not aware of any existing > >> implementations. > >> > I would argue that the device must decide what channel(s) it will > use > >> when > >> > it receives the channel response. > >> [GC] Agree with Scott but this is only a portion of the > considerations. > >> If a > >> device was to operate on its own, this would be true but a > >> communication > >> device usually implies at least 2 devices to communicate. Hence, the > >> choice > >> of the channel to be used will need to be negotiated between the two > >> devices > >> before a choice can be made. The chosen channel will belong to the > set > >> of > >> available channels that is common to both devices. Remember that > some > >> channels may be available at one device and not at the other because > of > >> their geolocation or other reason. Extending this concept to a star > >> network > >> topology, the channel that will be selected by this network will > have > >> to > >> belong to the set of channels that are available to all devices. > Each > >> device > >> will not be able to decide by itself which channel it wants to use. > >> > >> This is why in such a star topology, it makes sense that the slave > >> devices > >> to a base station or access point be represented by the base station > >> acting > >> as the master on their behalf to query the database and receive the > >> list of > >> available channels (and/or maximum EIRP per channel). It is then the > >> responsibility of the base station to identify the set of available > >> channels > >> that is common for itself and all its slaves to decide on the > channel > >> that > >> the network will use. As you can see, in this case, there is no need > >> for > >> each slave to receive its list of available channels. On its own, it > >> would > >> not know what to do with it. The only thing that needs to be sent > from > >> the > >> master device to its slaves is the resulting operating channel. > >> > >> I a more sophisticated operation, the master device may add one or a > >> few > >> backup channels extracted from the common set of available channel > to > >> the > >> message going to its slave so that if a change in channel > availability > >> occurs, an instantaneous switch to the next backup channel can be > made > >> without any further signaling, thus providing for a channel switch > that > >> is > >> transparent to the user. It is the scheme that has been included in > the > >> IEEE > >> 802.22-2011 Standard. This is why I don't believe that PAWS should > get > >> involved in defining this signaling between the base station and its > >> slaves > >> devices. > >> >> > >> >> 2. If the device then uses another channel or a different > channel, > >> does > >> >> it need to report that change to the database? > >> > Scott->My interpretation of section 3.18 is that the device can > only > >> > transmit within the upper& lower frequencies returned in the > >> > acknowledgment. I do not (quickly) find any reference in the > >> requirements > >> > to changing channels. Thus operationally it could be that the > channel > >> > request process must be repeated before the device can use a > >> different > >> > channel (frequencies). > >> [GC] If the process involves 2 messages, then, the device and its > >> associated > >> devices could change channels at will as long as all these channels > >> belong > >> to the set of available channel. However, if the third message is > >> added, it > >> would make sense that the master device reports to the database any > >> channel > >> change that would occur to the database, otherwise, the status of > the > >> spectrum occupation would be wrong at any moment and would be > useless > >> for > >> the purpose of any spectrum usage optimization such as coexistence. > >> >> > >> >> Thanks! > >> >> > >> >> Peter > >> >> > >> >> On 3/8/12 10:17 AM, scott.probasco@nokia.com wrote: > >> >>> Hi, > >> >>> > >> >>> The point from Brian is very relevant: > >> >>> > >> >>> Channel request > >> >>> Channel response > >> >>> Channel acknowledgement > >> >>> > >> >>> What Ofcom does with the information in the acknowledgement does > >> not > >> >>> matter. As the regulator in UK, they write rules that must be > >> followed > >> >>> in > >> >>> order to operate a whitespace radio in the UK. I believe the > scope > >> of > >> >>> the > >> >>> WG must be focused on a working solution. If this is simple > channel > >> >>> request& response in one regulator's domain, PAWS can support > >> this. If > >> >>> it > >> >>> means a channel request, response and acknowledgement in another > >> >>> regulator's domain, PAWS can support this. As a participating > >> member of > >> >>> the work group, I believe the scope should be basic working > >> solution, > >> >>> not > >> >>> limited to a specific number of messages. > >> >>> > >> >>> Kind Regards, > >> >>> Scott > >> >>> > >> >>> > >> >>> > >> >>> On 3/8/12 11:11 AM, "ext Zuniga, Juan Carlos" > >> >>> wrote: > >> >>> > >> >>>> Peter, Nancy, > >> >>>> > >> >>>> I agree should design a protocol with the best of our current > >> >>>> knowledge, > >> >>>> and that should be accounting for all the known regulations at > >> present > >> >>>> time. We should not limit the scope with the purpose of > designing > >> a > >> >>>> protocol 'faster'. Our goal is not only to design a WSDB > protocol. > >> Our > >> >>>> goal is to design a WSDB protocol that is USEFUL to the > community. > >> >>>> > >> >>>> The charter does state that > >> >>>> > >> >>>> "...the group should also reach out to other potential > >> >>>> "customers" for a white space database access method and > consider > >> input > >> >>> >from regulatory entities that are involved in the specification > of > >> the > >> >>>> rules for secondary use of spectrum in specific radio bands. " > >> >>>> > >> >>>> I think that is exactly what we are doing now. > >> >>>> > >> >>>> Regarding whether the types of requirements belong to #1 or #2, > I > >> >>>> believe > >> >>>> it is more of #1 type, as the information to be exchanged would > be > >> >>>> known > >> >>>> after the initial query/response. > >> >>>> > >> >>>> If we know it today, I see no reason why we should not work on > it > >> in > >> >>>> the > >> >>>> first phase of the work. > >> >>>> > >> >>>> Regards, > >> >>>> > >> >>>> Juan Carlos > >> >>>> > >> >>>>> -----Original Message----- > >> >>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On > >> Behalf > >> >>>>> Of > >> >>>>> Peter Saint-Andre > >> >>>>> Sent: Thursday, March 08, 2012 11:59 AM > >> >>>>> To: Nancy Bravin > >> >>>>> Cc: paws@ietf.org; johnny.dixon@bt.com; > chris.cheeseman@bt.com; > >> Pete > >> >>>>> Resnick > >> >>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- > >> usecases- > >> >>>>> rqmts-03: channel reporting > >> >>>>> > >> >>>>> Hi Nancy, > >> >>>>> > >> >>>>> You are absolutely right that different locales will have > >> different > >> >>>>> rules and requirements. We need to understand those, and work > to > >> >>>>> address > >> >>>>> them if possible (although we don't necessarily need to > address > >> them > >> >>>>> all > >> >>>>> at the same time). I see several kinds of requirements: > >> >>>>> > >> >>>>> 1. Some requirements might lead to features beyond the > >> query/response > >> >>>>> protocol we've envisioned so far. One example might be real- > time > >> >>>>> reporting about the channels that a device is actually using. > In > >> my > >> >>>>> opinion, it would be best to handle those in the next phase of > >> work, > >> >>>>> because as far as I can see they are outside the scope of our > >> charter. > >> >>>>> > >> >>>>> 2. Some requirements might be handled through by defining > >> additional > >> >>>>> fields that can be included in the query or response. We > >> definitely > >> >>>>> planned for that when working on the charter with the IESG: > >> >>>>> > >> >>>>> In addition, the particular > >> >>>>> data exchanged between a device and a database might depend > on > >> the > >> >>>>> ranges of radio spectrum that are to be used, the > requirements > >> of > >> >>>>> the > >> >>>>> database operators and their governing regulations, and > other > >> >>>>> factors. > >> >>>>> Therefore, the database access method and the > query/response > >> data > >> >>>>> formats that are exchanged using that method need to be > >> designed > >> for > >> >>>>> extensibility rather than being tied to any specific > spectrum, > >> >>>>> country, or phy/mac/air interface. > >> >>>>> > >> >>>>> It's unclear to me right now if the Ofcom requirement fits > into > >> #1 or > >> >>>>> #2, which is why we're having this discussion. :) > >> >>>>> > >> >>>>> Peter > >> >>>>> > >> >>>>> On 3/7/12 8:17 PM, Nancy Bravin wrote: > >> >>>>>> Peter and all, > >> >>>>>> > >> >>>>>> I agree that it is important to revisit now, so that in the > >> future, > >> >>>>>> it will be easy to align things in their proper place. Every > >> country > >> >>>>>> may have different regulations, spectrum, policy and what > >> >>>>>> responsibility is in the domain of the system, and what comes > >> under > >> >>>>>> the PAWS charter is important. Maybe some separation might > be > >> >>>>>> possible, and dividing and clarifying issues now will help in > >> the > >> >>>>>> future. Certainly it seems that the FCC may change some > rules, > >> and > >> >>>>>> we know that Ofcom is not yet finished with their > regulations. > >> Canada > >> >>>>>> has their own, and other countries are working on this as > well. > >> Just > >> >>>>>> a thought...Sharing is a realistic goal...as is off > loading... > >> Or you > >> >>>>>> slim line and every 6 months decide what to incorporate in > the > >> >>>>>> protocol based on new information, new ideas, new innovation > new > >> >>>>>> regulations and maybe spend more time than you could if > >> addressed > >> >>>>>> now. > >> >>>>>> > >> >>>>>> That way you leave the door open and outside of referencing > what > >> is > >> >>>>>> known today, by referencing regulations i.e. Ofcom, FCC, > >> Industry > >> >>>>>> Canada etc as of XX-XX-XXXX date. Out of scope not something > we > >> know > >> >>>>>> enough about to say at this point, In my opinion. > >> >>>>>> > >> >>>>>> My 2 cents.. > >> >>>>>> > >> >>>>>> Sincerely, Nancy > >> >>>>>> > >> >>>>>> On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote: > >> >>>>>> > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> As your responsible Area Director (until March 28, when Pete > >> >>>>>>> Resnick will take over from me), I have reviewed this > thread. > >> >>>>>>> > >> >>>>>>> In my opinion (I am happy to be proven wrong), this new > >> requirement > >> >>>>>>> goes beyond what the charter defined as the scope of this > >> working > >> >>>>>>> group, which was to enable a device to discover the white > space > >> >>>>>>> available to it in its current location. Reporting usage > back > >> to > >> >>>>>>> the database is simply not mentioned in the charter. > >> >>>>>>> > >> >>>>>>> Earlier in this thread, Andy Sago wrote: > >> >>>>>>> > >> >>>>>>> There's no language I can find in the charter that > explicitly > >> puts > >> >>>>>>> this out of scope. > >> >>>>>>> > >> >>>>>>> An IETF charter defines what the working group shall work > on. > >> Many > >> >>>>>>> interesting features could be developed here. However, it is > >> not > >> >>>>>>> the job of the charter to mention explicitly that each of > those > >> >>>>>>> interesting features is out of scope. > >> >>>>>>> > >> >>>>>>> The charter does say: > >> >>>>>>> > >> >>>>>>> Once the device learns of the available white space (e.g., > in a > >> TV > >> >>>>>>> white space implementation, the list of available channels > at > >> that > >> >>>>>>> location), it can then select one of the bands from the list > >> and > >> >>>>>>> begin to transmit and receive on the selected band. > >> >>>>>>> > >> >>>>>>> This text might have assumed that no further communication > or > >> >>>>>>> authorization was required in order to select one of the > bands > >> from > >> >>>>>>> the list and then transmit/receive. Perhaps that assumption > was > >> >>>>>>> mistaken. If so, it would be good to have a discussion about > >> that, > >> >>>>>>> so we can determine if we need to revisit the assumptions we > >> made > >> >>>>>>> early on. If in fact we made some faulty or limited > >> assumptions, > >> >>>>>>> then let's get that out in the open. > >> >>>>>>> > >> >>>>>>> Peter > >> >>>>>>> > >> >>>>>>> On 3/7/12 9:40 AM, Rosen, Brian wrote: > >> >>>>>>>> I'd also suggest that > our > >> >>>>>>>> charter limitation is really support for sharing of > whitespace > >> by > >> >>>>>>>> whitespace devices. Reporting what you use is not sharing, > >> it's > >> >>>>>>>> just data gathering. > >> >>>>>>>> > >> >>>>>>>> The point of excluding sharing was to eliminate the > >> complexities > >> >>>>>>>> of what constituted fairness, and what kinds of > communication > >> >>>>>>>> might be needed between databases, where more than one > could > >> >>>>>>>> supply available whitespace in a band. This doesn't have > any > >> of > >> >>>>>>>> those issues, As long as it's just sending information, I > >> don't > >> >>>>>>>> have a problem. Once the database is supposed to do > anything > >> >>>>>>>> with it that involves changing what spectrum it reports, > then > >> I > >> >>>>>>>> think we cross the line. > >> >>>>>>>> > >> >>>>>>>> Brian > >> >>>>>>>> > >> >>>>>>>> On Mar 6, 2012, at 12:28 PM, > >> >>>>>>>> wrote: > >> >>>>>>>> > >> >>>>>>>>> Joel > >> >>>>>>>>> > >> >>>>>>>>> Indeed, the regulator has not described the process or > >> provided > >> >>>>>>>>> a flow diagram, so there may be some wrinkles, but we need > to > >> >>>>>>>>> provide for their intent. To answer your question, the > >> channels > >> >>>>>>>>> that the master will use are sent in a separate message > >> >>>>>>>>> (described in P.12 ter), that occurs after the master > >> receives > >> >>>>>>>>> the response to its channel request, but before the master > >> can > >> >>>>>>>>> transmit. At this point, it knows what channels are > >> available, > >> >>>>>>>>> and which one it will use. As far as the slaves are > >> concerned, > >> >>>>>>>>> as they associate, the master will need to gather their > >> details > >> >>>>>>>>> and send further channel usage messages to the database on > >> >>>>>>>>> their behalf. > >> >>>>>>>>> > >> >>>>>>>>> Regards > >> >>>>>>>>> > >> >>>>>>>>> Andy > >> >>>>>>>>> > >> >>>>>>>>> -----Original Message----- From: paws-bounces@ietf.org > >> >>>>>>>>> [mailto:paws-bounces@ietf.org] On Behalf Of Joel M. > Halpern > >> >>>>>>>>> Sent: 06 March 2012 17:05 To: scott.probasco@nokia.com Cc: > >> >>>>>>>>> paws@ietf.org; Cheeseman,CJ,Chris,COD R; > Dixon,JS,Johnny,COD > >> R > >> >>>>>>>>> Subject: Re: [paws] WGLC for > >> >>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel > >> >>>>>>>>> reporting > >> >>>>>>>>> > >> >>>>>>>>> Ahh. I think I see where the request and my understanding > >> >>>>>>>>> divurge. If the idea here is that the master must provide, > in > >> >>>>>>>>> the request, an indication of what channels it expects to > >> use, > >> >>>>>>>>> I can at least understand that. I will return to > technical > >> >>>>>>>>> concerns in a moment. > >> >>>>>>>>> > >> >>>>>>>>> However, when you say "provide channel usage information, > in > >> >>>>>>>>> order to evaluate interference", what that says to me is > >> >>>>>>>>> providing, during operation, information as to what > channels > >> >>>>>>>>> are being used, and at what power levels. That is what > would > >> >>>>>>>>> be needed to analyze actual interference effects. And that > is > >> >>>>>>>>> out of scope as I understand our scope. > >> >>>>>>>>> > >> >>>>>>>>> I do see a technical difficulty with having the master > >> provide, > >> >>>>>>>>> as part of either registering or requesting spectrum > >> >>>>>>>>> information, what channels it intends to use. It doesn;t > >> know > >> >>>>>>>>> what channels it intends to use. It intends to use some > >> number > >> >>>>>>>>> of available channels. It will figure out which ones when > it > >> >>>>>>>>> is told what is available. How can it send that > information > >> in > >> >>>>>>>>> the request? > >> >>>>>>>>> > >> >>>>>>>>> Yours, Joel > >> >>>>>>>>> > >> >>>>>>>>> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: > >> >>>>>>>>>> Hi, > >> >>>>>>>>>> > >> >>>>>>>>>> There is a similarity here with device ID. In context of > >> PAWS > >> >>>>>>>>>> we are not concerned with why a device ID is required by > a > >> >>>>>>>>>> regulator, we accept it is a requirement from a regulator > >> and > >> >>>>>>>>>> include it to the protocol. Ofcom identifies in 3.18& > 3.19 > >> >>>>>>>>>> that channel usage information is required and thus we > need > >> >>>>>>>>>> to include this information. Since the master must > provide > >> >>>>>>>>>> this information prior to transmitting, PAWS will not > >> >>>>>>>>>> function in the UK without this information and thus I > >> >>>>>>>>>> believe channel usage information is integral to the > channel > >> >>>>>>>>>> request& response messaging. > >> >>>>>>>>>> > >> >>>>>>>>>> Kind Regards, Scott > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> On 3/6/12 10:30 AM, "ext Joel M. > >> >>>>>>>>>> Halpern" wrote: > >> >>>>>>>>>> > >> >>>>>>>>>>> I would draw a distinction. Ofcom regulations about > >> >>>>>>>>>>> whitespace requests are very much relevant. Ofcom > >> >>>>>>>>>>> regulations about notification of dynamic behavior > (which > >> >>>>>>>>>>> spectrum is being used) are not in scope as I understand > >> >>>>>>>>>>> the earlier discussions, particularly the chartering > >> >>>>>>>>>>> discussions. > >> >>>>>>>>>>> > >> >>>>>>>>>>> Yours, Joel > >> >>>>>>>>>>> > >> >>>>>>>>>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> The ofcom requirements are very much relevant to the > >> >>>>>>>>>>>> scope of the PAWS WG. The only other regulatory > >> >>>>>>>>>>>> requirements that we have today is the FCC. Ofcom > >> >>>>>>>>>>>> requirements are a good addition to the set. > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> -Raj > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> On 3/6/12 10:03 AM, "ext > >> >>>>>>>>>>>> andy.sago@bt.com" wrote: > >> >>>>>>>>>>>> > >> >>>>>>>>>>>>> Hi Joel > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> There's no language I can find in the charter that > >> >>>>>>>>>>>>> explicitly puts this out of scope. On the other hand, > >> >>>>>>>>>>>>> the charter says that the group will "consider input > >> >>>>>>>>>>>>> from regulatory entities", and this is one of the > >> >>>>>>>>>>>>> requirements from Ofcom that they have just published. > >> >>>>>>>>>>>>> The protocol will be worthless for the UK if it omits > >> >>>>>>>>>>>>> some requirements. > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> Regards > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> Andy > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> -----Original Message----- From: Joel M. Halpern > >> >>>>>>>>>>>>> [mailto:jmh@joelhalpern.com] Sent: 06 March 2012 15:53 > >> >>>>>>>>>>>>> To: Sago,AJ,Andy,COD R Cc: paws@ietf.org; > >> >>>>>>>>>>>>> Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for > >> >>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: > channel > >> >>>>>>>>>>>>> reporting > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> As I understand, the information you are asking for is > >> >>>>>>>>>>>>> explicitly out of scope for the working group. Yours, > >> >>>>>>>>>>>>> Joel > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: > >> >>>>>>>>>>>>>> All > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Comparing the draft with the Ofcom requirements at > >> >>>>>>>>>>>>>> http://www.cept.org/Documents/se- > >> >>>>> 43/4161/SE43(12)Info03_Draft-UK-r > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>> egul > >> >>>>>>>>>>>>>> atory-requirements-for-white-space-devices-in-the- > UHF- > >> TV- > >> >>>>> band, > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>> I believe the WG draft is deficient in the area of reporting > >> >>>>>>>>>>>>>> frequencies and powers actually used by masters and > >> >>>>>>>>>>>>>> slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom > >> >>>>>>>>>>>>>> intends to collect this data to assesses the impact > >> >>>>>>>>>>>>>> of aggregate interference into other services. It > >> >>>>>>>>>>>>>> would also provide usage information (frequency in > >> >>>>>>>>>>>>>> use) that would inform the operation of a kill switch > >> >>>>>>>>>>>>>> capability. I suggest this deficiency can be remedied > >> >>>>>>>>>>>>>> with the following changes: > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> New P requirements (probably best placed following > >> >>>>>>>>>>>>>> P.12): > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> P.12bis: The protocol MUST support a channel usage > >> >>>>>>>>>>>>>> message from the slave device to the master device. > >> >>>>>>>>>>>>>> The channel usage message MUST include parameters as > >> >>>>>>>>>>>>>> required by local regulatory requirement. These > >> >>>>>>>>>>>>>> parameters MAY include device ID, manufacturer's > >> >>>>>>>>>>>>>> serial number, channel usage and power level > >> >>>>>>>>>>>>>> information. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> P.12ter: The protocol MUST support a channel usage > >> >>>>>>>>>>>>>> message from the master device to the database. The > >> >>>>>>>>>>>>>> channel usage message MUST include parameters as > >> >>>>>>>>>>>>>> required by local regulatory requirement for the > >> >>>>>>>>>>>>>> master and its associated slaves. These parameters > >> >>>>>>>>>>>>>> MAY include device ID, manufacturer's serial number, > >> >>>>>>>>>>>>>> channel usage and power level information. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> P.12qua: The protocol MUST support a channel usage > >> >>>>>>>>>>>>>> message acknowledgement. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> New O requirements (probably best placed following > >> >>>>>>>>>>>>>> O13): > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> O.13bis: According to local regulatory policy, after > >> >>>>>>>>>>>>>> connecting to a master device's radio network a slave > >> >>>>>>>>>>>>>> device MAY inform the master device of the actual > >> >>>>>>>>>>>>>> channel usage. The slave MUST include parameters > >> >>>>>>>>>>>>>> required by local regulatory policy, e.g. device ID, > >> >>>>>>>>>>>>>> manufacturer's serial number, channel usage and power > >> >>>>>>>>>>>>>> level information. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> O.13ter: According to local regulatory policy, a > >> >>>>>>>>>>>>>> master device MAY inform the database of the actual > >> >>>>>>>>>>>>>> channel usage of the master and its slaves. The > >> >>>>>>>>>>>>>> master MUST include parameters required by local > >> >>>>>>>>>>>>>> regulatory policy, e.g. device ID, manufacturer's > >> >>>>>>>>>>>>>> serial number, channel usage and power level > >> >>>>>>>>>>>>>> information of the master and its slaves. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> New steps could be introduced into one or more use > >> >>>>>>>>>>>>>> cases to cover these Ofcom requirements, e.g. new > >> >>>>>>>>>>>>>> steps 6bis and 9bis in the hotspot use case at > >> >>>>>>>>>>>>>> 4.2.1: > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 6bis. Prior to initiating transmission, if required > >> >>>>>>>>>>>>>> by local regulation, the master/AP informs the > >> >>>>>>>>>>>>>> database of the channel and power level it has > >> >>>>>>>>>>>>>> chosen. This is repeated for each slave that > >> >>>>>>>>>>>>>> associated with the master. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 9bis. Prior to initiating transmission, if required > >> >>>>>>>>>>>>>> by local regulation, the slave informs the master/AP > >> >>>>>>>>>>>>>> of the channel and power level it has chosen, and the > >> >>>>>>>>>>>>>> master/AP relays this information to the database. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> - end of new text - > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> For information, for those not accessing the url in > >> >>>>>>>>>>>>>> the first paragraph of this email, the full Ofcom > >> >>>>>>>>>>>>>> requirements leading to this new PAWS text are as > >> >>>>>>>>>>>>>> follows: > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 3.18 After receiving instructions from a WSDB in > >> >>>>>>>>>>>>>> relation to the maximum permitted EIRPs over the DTT > >> >>>>>>>>>>>>>> channels, and prior to initiating transmissions > >> >>>>>>>>>>>>>> within the UHF TV band, a master WSD must communicate > >> >>>>>>>>>>>>>> to the WSDB the following information: > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 3.18.1 The lower and upper frequency boundaries^13 of > >> >>>>>>>>>>>>>> the in-block emissions of the master WSD, and those > >> >>>>>>>>>>>>>> of the in-block emissions of its associated slaves. A > >> >>>>>>>>>>>>>> lower frequency will be specified as (470 + 8k + > >> >>>>>>>>>>>>>> 0.2n) MHz, with the corresponding upper frequency > >> >>>>>>>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3?4 k 3?4 > >> >>>>>>>>>>>>>> 39, 0 3?4 n 3?4 39, 1 3?4 m 3?4 40, and n< m. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 3.18.2 The maximum in-block EIRP spectral densities > >> >>>>>>>>>>>>>> (in dBm/(0.2 MHz)) that the master WSD, and its > >> >>>>>>>>>>>>>> associated slaves, actually radiate between each > >> >>>>>>>>>>>>>> reported lower frequency boundary and its > >> >>>>>>>>>>>>>> corresponding upper frequency boundary. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Footnote 13 states: > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> The use of upper and lower frequency boundaries > >> >>>>>>>>>>>>>> (defined over a 200 kHz raster) allows a WSDB to > >> >>>>>>>>>>>>>> collect more granular information with regards to the > >> >>>>>>>>>>>>>> usage of the frequency resource by narrowband WSD > >> >>>>>>>>>>>>>> technologies. The upper and lower frequencies of a > >> >>>>>>>>>>>>>> boundary pair do not straddle a DTT channel boundary. > >> >>>>>>>>>>>>>> Note that a WSD may transmit over multiple, > >> >>>>>>>>>>>>>> non-contiguous, whole DTT channels or fractions of > >> >>>>>>>>>>>>>> DTT channels. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 3.19 A master WSD must be able to receive the > >> >>>>>>>>>>>>>> following information^14 from a WSDB: > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in the > >> >>>>>>>>>>>>>> context of 3.18, that the reported information on the > >> >>>>>>>>>>>>>> DTT channels and EIRP spectral densities actually > >> >>>>>>>>>>>>>> used by the master and slave WSDs were received > >> >>>>>>>>>>>>>> successfully by the WSDB^18 ]. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Footnote 14 states: > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 14 While the communication of some of this > >> >>>>>>>>>>>>>> information from a WSDB to a master WSD is optional, > >> >>>>>>>>>>>>>> master WSDs must be able to receive and interpret > >> >>>>>>>>>>>>>> these. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Footnote 18 states: > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 18 This forms part of a handshake protocol and may be > >> >>>>>>>>>>>>>> an area where industry could harmonise without the > >> >>>>>>>>>>>>>> need for an explicit requirement in the regulations. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Regards > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Andy > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> *From:*paws-bounces@ietf.org > >> >>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] *On Behalf Of > >> >>>>>>>>>>>>>> *Gabor.Bajko@nokia.com *Sent:* 05 March 2012 19:46 > >> >>>>>>>>>>>>>> *To:* paws@ietf.org *Subject:* [paws] WGLC for > >> >>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> The authors of the use cases and requirements draft > >> >>>>>>>>>>>>>> have just posted a new version of the draft and > >> >>>>>>>>>>>>>> indicated that there are no unresolved > >> >>>>>>>>>>>>>> comments/issues they are aware of. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Therefore, I'd like to initiate a WG Last Call for > >> >>>>>>>>>>>>>> comments on > >> >>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-paws- > >> problem- > >> >>>>> stmt-u > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>> seca > >> >>>>>>>>>>>>>> ses-rqmts-03.txt > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Please review the draft and send your comments to the > >> >>>>>>>>>>>>>> list by March 20th, 2012. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> If you review the draft and have no comments, send a > >> >>>>>>>>>>>>>> note to the list that the draft is good as it is, we > >> >>>>>>>>>>>>>> need these notes as much as we need the actual > >> >>>>>>>>>>>>>> comments. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Thanks, Gabor > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> > > >> > _______________________________________________ > >> > paws mailing list > >> > paws@ietf.org > >> > https://www.ietf.org/mailman/listinfo/paws > >> > > >> _______________________________________________ > >> paws mailing list > >> paws@ietf.org > >> https://www.ietf.org/mailman/listinfo/paws > >> > >> _______________________________________________ > >> paws mailing list > >> paws@ietf.org > >> https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ > >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 ________________________________ ***************************************************************************= *************************************** 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. ***************************************************************************= *************************************** From sdas@appcomsci.com Thu Mar 8 16:23:39 2012 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 074AE21F83EF for ; Thu, 8 Mar 2012 16:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.028 X-Spam-Level: X-Spam-Status: No, score=0.028 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, 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 PX1fhEjs0fBm for ; Thu, 8 Mar 2012 16:23:36 -0800 (PST) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id 533E221E8067 for ; Thu, 8 Mar 2012 16:23:29 -0800 (PST) Received: from bambi.research.telcordia.com (bambi.research.telcordia.com [192.4.5.54]) by thumper.research.telcordia.com (8.14.2/8.14.2) with ESMTP id q290NOPe024901; Thu, 8 Mar 2012 19:23:24 -0500 (EST) Received: from rrc-ats-exhb1.ats.atsinnovate.com (exch.research.telcordia.com [192.4.5.63]) by bambi.research.telcordia.com (8.14.4/8.13.4) with ESMTP id q290NNbO002854; Thu, 8 Mar 2012 19:23:23 -0500 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at bambi Received: from rrc-ats-exmb1.ats.atsinnovate.com ([192.4.5.65]) by rrc-ats-exhb1.ats.atsinnovate.com ([2002:c004:53f::c004:53f]) with mapi id 14.01.0355.002; Thu, 8 Mar 2012 19:23:42 -0500 From: "Das, Subir" To: "'Siew Yoon Tan'" , "Zuniga, Juan Carlos" , "Basavaraj.Patil@nokia.com" , "gerald.chouinard@sympatico.ca" , "jmh@joelhalpern.com" , "scott.probasco@nokia.com" Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting Thread-Index: AQHM/YFmF0824TXodkK/mH1uWWNaL5ZhGdfg Date: Fri, 9 Mar 2012 00:23:42 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.18.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 08 Mar 2012 17:50:55 -0800 Cc: "paws@ietf.org" , "presnick@qualcomm.com" , Reza Karimi , "johnny.dixon@bt.com" , "chris.cheeseman@bt.com" Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 00:23:39 -0000 I have a question here. Is it really an acknowledgement or we would like to= see a kind of notification message that includes channel, and other parame= ters? Regards, _Subir=20 -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Sie= w Yoon Tan Sent: Thursday, March 08, 2012 4:06 PM To: Zuniga, Juan Carlos; Basavaraj.Patil@nokia.com; gerald.chouinard@sympat= ico.ca; jmh@joelhalpern.com; scott.probasco@nokia.com Cc: paws@ietf.org; presnick@qualcomm.com; Reza Karimi; johnny.dixon@bt.com;= chris.cheeseman@bt.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03= :channel reporting Dear All, Regarding Ofcom's requirement to have a return channel as part of the proto= col between the WSD and WSDB, I would like to confirm to following sequence= of messaging Channel request Channel response Channel acknowledgement which was raised in an earlier email to this list. Our view is that it would be beneficial to define the protocol between WSD = and WSDB that supports this requirement even though how the information cou= ld be used is still subject to discussion in the UK. Best regards, Siew Yoon ________________________________________ From: paws-bounces@ietf.org [paws-bounces@ietf.org] on behalf of Zuniga, Ju= an Carlos [JuanCarlos.Zuniga@InterDigital.com] Sent: 08 March 2012 20:41 To: Basavaraj.Patil@nokia.com; gerald.chouinard@sympatico.ca; jmh@joelhalpe= rn.com; scott.probasco@nokia.com Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; chris.cheese= man@bt.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts= -03:channel reporting Hi Raj, I was reusing the language used from Gerald (which I know is familiar to pe= ople working on IEEE 802 WS groups): >> [GC] You got it. This would be useless for spectrum regulators. One=20 >> should realize that, from the spectrum regulator's point of view, the=20 >> second and third messages could be iterated upon to optimize the=20 >> spectrum use. >> Knowing >> what channels the systems in an area are using, the spectrum=20 >> regulators and/or other entities such as those taking care of=20 >> coexistence could use the database in near-real-time to iterate on=20 >> the two last messages to reduce the range of channels that some=20 >> systems may use once they know precisely what channels are being used=20 >> in the area. The PAWS protocol would carry the information back and=20 >> forth but would not be involved in such spectrum use optimization. Having said that, I have no issue sticking to the WSDB terminology. I like = keeping things simple :) JC > -----Original Message----- > From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] > Sent: Thursday, March 08, 2012 3:33 PM > To: Zuniga, Juan Carlos; gerald.chouinard@sympatico.ca;=20 > jmh@joelhalpern.com; scott.probasco@nokia.com > Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com;=20 > chris.cheeseman@bt.com > Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- > rqmts-03:channel reporting > > > Hi JC, > > Where/why did the coexistence manager come into the picture? Your=20 > comment about "communicating back to the WSDB/coexistence manager" may=20 > result in further misunderstanding. If we simply stick to to WSDB I=20 > think we are okay. > > -Raj > > On 3/8/12 2:25 PM, "ext Zuniga, Juan Carlos" > wrote: > > >So, from Gerald and Andy's comments, it seems like from the point of > view > >of (at least) two regulatory entities it is important for the=20 > >protocol > to > >allow communicating back to the WSDB/coexistence manager the actual=20 > >channel usage after the first query is made. > > > >This is to me a very clear requirement. > > > >The actual messages/IEs that would carry this information should be=20 > >discussed as part of the solution document, and not the requirements. > > > >JC > > > >> -----Original Message----- > >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On=20 > >> Behalf > Of > >> Gerald Chouinard > >> Sent: Thursday, March 08, 2012 1:59 PM > >> To: 'Joel M. Halpern'; scott.probasco@nokia.com > >> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com;=20 > >> chris.cheeseman@bt.com > >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- > >> rqmts-03:channel reporting > >> > >> Joel, Scott, > >> > >> Interesting discussion! See my comments in line below. > >> > >> Gerald > >> > >> -----Original Message----- > >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On=20 > >> Behalf > Of > >> Joel > >> M. Halpern > >> Sent: Thursday, 08 March, 2012 13:17 > >> To: scott.probasco@nokia.com > >> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com;=20 > >> chris.cheeseman@bt.com > >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- > >> rqmts-03: > >> channel reporting > >> > >> So why won't the device simply say "I will use all of this?" > >> [GC] This would defeat the purpose of the acknowledgement message. > >> After all, that way it needs to do less work with the database. =20 > >> And > it > >> can change frequencies when it wants. > >> Given that the stated goal of the Ofcom requriement was to be able > to > >> analyze interference effects, it seems that this will not actually > lead > >> to them getting what they want, even if it does comply with the=20 > >> regulations. > >> [GC] You got it. This would be useless for spectrum regulators.=20 > >> One should realize that, from the spectrum regulator's point of=20 > >> view, the > second > >> and > >> third messages could be iterated upon to optimize the spectrum use. > >> Knowing > >> what channels the systems in an area are using, the spectrum > regulators > >> and/or other entities such as those taking care of coexistence=20 > >> could use the database in near-real-time to iterate on the two last=20 > >> messages to reduce the range of channels that some systems may use=20 > >> once they know precisely what channels are being used in the area.=20 > >> The PAWS protocol would carry > the > >> information back and forth but would not be involved in such > spectrum > >> use > >> optimization. > >> > >> Yours, > >> joel > >> > >> On 3/8/2012 1:09 PM, scott.probasco@nokia.com wrote: > >> > Hi Peter, > >> > > >> > Answers below. > >> > > >> > Kind Regards, > >> > Scott > >> > > >> > On 3/8/12 11:39 AM, "ext Peter Saint-Andre" > >> wrote: > >> > > >> >> Hi Scott, I have two clarifying questions: > >> >> > >> >> 1. Does the device know, when it receives the channel response, > >> which > >> >> channel it will actually use? > >> > Scott->This is all new and I am not aware of any existing > >> implementations. > >> > I would argue that the device must decide what channel(s) it will > use > >> when > >> > it receives the channel response. > >> [GC] Agree with Scott but this is only a portion of the > considerations. > >> If a > >> device was to operate on its own, this would be true but a=20 > >> communication device usually implies at least 2 devices to=20 > >> communicate. Hence, the choice of the channel to be used will need=20 > >> to be negotiated between the two devices before a choice can be=20 > >> made. The chosen channel will belong to the > set > >> of > >> available channels that is common to both devices. Remember that > some > >> channels may be available at one device and not at the other=20 > >> because > of > >> their geolocation or other reason. Extending this concept to a star=20 > >> network topology, the channel that will be selected by this network=20 > >> will > have > >> to > >> belong to the set of channels that are available to all devices. > Each > >> device > >> will not be able to decide by itself which channel it wants to use. > >> > >> This is why in such a star topology, it makes sense that the slave=20 > >> devices to a base station or access point be represented by the=20 > >> base station acting as the master on their behalf to query the=20 > >> database and receive the list of available channels (and/or maximum=20 > >> EIRP per channel). It is then the responsibility of the base=20 > >> station to identify the set of available channels that is common=20 > >> for itself and all its slaves to decide on the > channel > >> that > >> the network will use. As you can see, in this case, there is no=20 > >> need for each slave to receive its list of available channels. On=20 > >> its own, it would not know what to do with it. The only thing that=20 > >> needs to be sent > from > >> the > >> master device to its slaves is the resulting operating channel. > >> > >> I a more sophisticated operation, the master device may add one or=20 > >> a few backup channels extracted from the common set of available=20 > >> channel > to > >> the > >> message going to its slave so that if a change in channel > availability > >> occurs, an instantaneous switch to the next backup channel can be > made > >> without any further signaling, thus providing for a channel switch > that > >> is > >> transparent to the user. It is the scheme that has been included in > the > >> IEEE > >> 802.22-2011 Standard. This is why I don't believe that PAWS should > get > >> involved in defining this signaling between the base station and=20 > >> its slaves devices. > >> >> > >> >> 2. If the device then uses another channel or a different > channel, > >> does > >> >> it need to report that change to the database? > >> > Scott->My interpretation of section 3.18 is that the device can > only > >> > transmit within the upper& lower frequencies returned in the=20 > >> > acknowledgment. I do not (quickly) find any reference in the > >> requirements > >> > to changing channels. Thus operationally it could be that the > channel > >> > request process must be repeated before the device can use a > >> different > >> > channel (frequencies). > >> [GC] If the process involves 2 messages, then, the device and its=20 > >> associated devices could change channels at will as long as all=20 > >> these channels belong to the set of available channel. However, if=20 > >> the third message is added, it would make sense that the master=20 > >> device reports to the database any channel change that would occur=20 > >> to the database, otherwise, the status of > the > >> spectrum occupation would be wrong at any moment and would be > useless > >> for > >> the purpose of any spectrum usage optimization such as coexistence. > >> >> > >> >> Thanks! > >> >> > >> >> Peter > >> >> > >> >> On 3/8/12 10:17 AM, scott.probasco@nokia.com wrote: > >> >>> Hi, > >> >>> > >> >>> The point from Brian is very relevant: > >> >>> > >> >>> Channel request > >> >>> Channel response > >> >>> Channel acknowledgement > >> >>> > >> >>> What Ofcom does with the information in the acknowledgement=20 > >> >>> does > >> not > >> >>> matter. As the regulator in UK, they write rules that must be > >> followed > >> >>> in > >> >>> order to operate a whitespace radio in the UK. I believe the > scope > >> of > >> >>> the > >> >>> WG must be focused on a working solution. If this is simple > channel > >> >>> request& response in one regulator's domain, PAWS can support > >> this. If > >> >>> it > >> >>> means a channel request, response and acknowledgement in=20 > >> >>> another regulator's domain, PAWS can support this. As a=20 > >> >>> participating > >> member of > >> >>> the work group, I believe the scope should be basic working > >> solution, > >> >>> not > >> >>> limited to a specific number of messages. > >> >>> > >> >>> Kind Regards, > >> >>> Scott > >> >>> > >> >>> > >> >>> > >> >>> On 3/8/12 11:11 AM, "ext Zuniga, Juan Carlos" > >> >>> wrote: > >> >>> > >> >>>> Peter, Nancy, > >> >>>> > >> >>>> I agree should design a protocol with the best of our current=20 > >> >>>> knowledge, and that should be accounting for all the known=20 > >> >>>> regulations at > >> present > >> >>>> time. We should not limit the scope with the purpose of > designing > >> a > >> >>>> protocol 'faster'. Our goal is not only to design a WSDB > protocol. > >> Our > >> >>>> goal is to design a WSDB protocol that is USEFUL to the > community. > >> >>>> > >> >>>> The charter does state that > >> >>>> > >> >>>> "...the group should also reach out to other potential=20 > >> >>>> "customers" for a white space database access method and > consider > >> input > >> >>> >from regulatory entities that are involved in the=20 > >> >>> >specification > of > >> the > >> >>>> rules for secondary use of spectrum in specific radio bands. " > >> >>>> > >> >>>> I think that is exactly what we are doing now. > >> >>>> > >> >>>> Regarding whether the types of requirements belong to #1 or=20 > >> >>>> #2, > I > >> >>>> believe > >> >>>> it is more of #1 type, as the information to be exchanged=20 > >> >>>> would > be > >> >>>> known > >> >>>> after the initial query/response. > >> >>>> > >> >>>> If we know it today, I see no reason why we should not work on > it > >> in > >> >>>> the > >> >>>> first phase of the work. > >> >>>> > >> >>>> Regards, > >> >>>> > >> >>>> Juan Carlos > >> >>>> > >> >>>>> -----Original Message----- > >> >>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On > >> Behalf > >> >>>>> Of > >> >>>>> Peter Saint-Andre > >> >>>>> Sent: Thursday, March 08, 2012 11:59 AM > >> >>>>> To: Nancy Bravin > >> >>>>> Cc: paws@ietf.org; johnny.dixon@bt.com; > chris.cheeseman@bt.com; > >> Pete > >> >>>>> Resnick > >> >>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- > >> usecases- > >> >>>>> rqmts-03: channel reporting > >> >>>>> > >> >>>>> Hi Nancy, > >> >>>>> > >> >>>>> You are absolutely right that different locales will have > >> different > >> >>>>> rules and requirements. We need to understand those, and work > to > >> >>>>> address > >> >>>>> them if possible (although we don't necessarily need to > address > >> them > >> >>>>> all > >> >>>>> at the same time). I see several kinds of requirements: > >> >>>>> > >> >>>>> 1. Some requirements might lead to features beyond the > >> query/response > >> >>>>> protocol we've envisioned so far. One example might be real- > time > >> >>>>> reporting about the channels that a device is actually using. > In > >> my > >> >>>>> opinion, it would be best to handle those in the next phase=20 > >> >>>>> of > >> work, > >> >>>>> because as far as I can see they are outside the scope of our > >> charter. > >> >>>>> > >> >>>>> 2. Some requirements might be handled through by defining > >> additional > >> >>>>> fields that can be included in the query or response. We > >> definitely > >> >>>>> planned for that when working on the charter with the IESG: > >> >>>>> > >> >>>>> In addition, the particular > >> >>>>> data exchanged between a device and a database might=20 > >> >>>>> 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. > >> >>>>> Therefore, the database access method and the > query/response > >> data > >> >>>>> formats that are exchanged using that method need to be > >> designed > >> for > >> >>>>> extensibility rather than being tied to any specific > spectrum, > >> >>>>> country, or phy/mac/air interface. > >> >>>>> > >> >>>>> It's unclear to me right now if the Ofcom requirement fits > into > >> #1 or > >> >>>>> #2, which is why we're having this discussion. :) > >> >>>>> > >> >>>>> Peter > >> >>>>> > >> >>>>> On 3/7/12 8:17 PM, Nancy Bravin wrote: > >> >>>>>> Peter and all, > >> >>>>>> > >> >>>>>> I agree that it is important to revisit now, so that in the > >> future, > >> >>>>>> it will be easy to align things in their proper place. Every > >> country > >> >>>>>> may have different regulations, spectrum, policy and what=20 > >> >>>>>> responsibility is in the domain of the system, and what=20 > >> >>>>>> comes > >> under > >> >>>>>> the PAWS charter is important. Maybe some separation might > be > >> >>>>>> possible, and dividing and clarifying issues now will help=20 > >> >>>>>> in > >> the > >> >>>>>> future. Certainly it seems that the FCC may change some > rules, > >> and > >> >>>>>> we know that Ofcom is not yet finished with their > regulations. > >> Canada > >> >>>>>> has their own, and other countries are working on this as > well. > >> Just > >> >>>>>> a thought...Sharing is a realistic goal...as is off > loading... > >> Or you > >> >>>>>> slim line and every 6 months decide what to incorporate in > the > >> >>>>>> protocol based on new information, new ideas, new innovation > new > >> >>>>>> regulations and maybe spend more time than you could if > >> addressed > >> >>>>>> now. > >> >>>>>> > >> >>>>>> That way you leave the door open and outside of referencing > what > >> is > >> >>>>>> known today, by referencing regulations i.e. Ofcom, FCC, > >> Industry > >> >>>>>> Canada etc as of XX-XX-XXXX date. Out of scope not something > we > >> know > >> >>>>>> enough about to say at this point, In my opinion. > >> >>>>>> > >> >>>>>> My 2 cents.. > >> >>>>>> > >> >>>>>> Sincerely, Nancy > >> >>>>>> > >> >>>>>> On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote: > >> >>>>>> > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> As your responsible Area Director (until March 28, when=20 > >> >>>>>>> Pete Resnick will take over from me), I have reviewed this > thread. > >> >>>>>>> > >> >>>>>>> In my opinion (I am happy to be proven wrong), this new > >> requirement > >> >>>>>>> goes beyond what the charter defined as the scope of this > >> working > >> >>>>>>> group, which was to enable a device to discover the white > space > >> >>>>>>> available to it in its current location. Reporting usage > back > >> to > >> >>>>>>> the database is simply not mentioned in the charter. > >> >>>>>>> > >> >>>>>>> Earlier in this thread, Andy Sago wrote: > >> >>>>>>> > >> >>>>>>> There's no language I can find in the charter that > explicitly > >> puts > >> >>>>>>> this out of scope. > >> >>>>>>> > >> >>>>>>> An IETF charter defines what the working group shall work > on. > >> Many > >> >>>>>>> interesting features could be developed here. However, it=20 > >> >>>>>>> is > >> not > >> >>>>>>> the job of the charter to mention explicitly that each of > those > >> >>>>>>> interesting features is out of scope. > >> >>>>>>> > >> >>>>>>> The charter does say: > >> >>>>>>> > >> >>>>>>> Once the device learns of the available white space (e.g., > in a > >> TV > >> >>>>>>> white space implementation, the list of available channels > at > >> that > >> >>>>>>> location), it can then select one of the bands from the=20 > >> >>>>>>> list > >> and > >> >>>>>>> begin to transmit and receive on the selected band. > >> >>>>>>> > >> >>>>>>> This text might have assumed that no further communication > or > >> >>>>>>> authorization was required in order to select one of the > bands > >> from > >> >>>>>>> the list and then transmit/receive. Perhaps that assumption > was > >> >>>>>>> mistaken. If so, it would be good to have a discussion=20 > >> >>>>>>> about > >> that, > >> >>>>>>> so we can determine if we need to revisit the assumptions=20 > >> >>>>>>> we > >> made > >> >>>>>>> early on. If in fact we made some faulty or limited > >> assumptions, > >> >>>>>>> then let's get that out in the open. > >> >>>>>>> > >> >>>>>>> Peter > >> >>>>>>> > >> >>>>>>> On 3/7/12 9:40 AM, Rosen, Brian wrote: > >> >>>>>>>> I'd also suggest that > our > >> >>>>>>>> charter limitation is really support for sharing of > whitespace > >> by > >> >>>>>>>> whitespace devices. Reporting what you use is not=20 > >> >>>>>>>> sharing, > >> it's > >> >>>>>>>> just data gathering. > >> >>>>>>>> > >> >>>>>>>> The point of excluding sharing was to eliminate the > >> complexities > >> >>>>>>>> of what constituted fairness, and what kinds of > communication > >> >>>>>>>> might be needed between databases, where more than one > could > >> >>>>>>>> supply available whitespace in a band. This doesn't have > any > >> of > >> >>>>>>>> those issues, As long as it's just sending information, I > >> don't > >> >>>>>>>> have a problem. Once the database is supposed to do > anything > >> >>>>>>>> with it that involves changing what spectrum it reports, > then > >> I > >> >>>>>>>> think we cross the line. > >> >>>>>>>> > >> >>>>>>>> Brian > >> >>>>>>>> > >> >>>>>>>> On Mar 6, 2012, at 12:28 PM,=20 > >> >>>>>>>> wrote: > >> >>>>>>>> > >> >>>>>>>>> Joel > >> >>>>>>>>> > >> >>>>>>>>> Indeed, the regulator has not described the process or > >> provided > >> >>>>>>>>> a flow diagram, so there may be some wrinkles, but we=20 > >> >>>>>>>>> need > to > >> >>>>>>>>> provide for their intent. To answer your question, the > >> channels > >> >>>>>>>>> that the master will use are sent in a separate message=20 > >> >>>>>>>>> (described in P.12 ter), that occurs after the master > >> receives > >> >>>>>>>>> the response to its channel request, but before the=20 > >> >>>>>>>>> master > >> can > >> >>>>>>>>> transmit. At this point, it knows what channels are > >> available, > >> >>>>>>>>> and which one it will use. As far as the slaves are > >> concerned, > >> >>>>>>>>> as they associate, the master will need to gather their > >> details > >> >>>>>>>>> and send further channel usage messages to the database=20 > >> >>>>>>>>> on their behalf. > >> >>>>>>>>> > >> >>>>>>>>> Regards > >> >>>>>>>>> > >> >>>>>>>>> Andy > >> >>>>>>>>> > >> >>>>>>>>> -----Original Message----- From: paws-bounces@ietf.org=20 > >> >>>>>>>>> [mailto:paws-bounces@ietf.org] On Behalf Of Joel M. > Halpern > >> >>>>>>>>> Sent: 06 March 2012 17:05 To: scott.probasco@nokia.com Cc: > >> >>>>>>>>> paws@ietf.org; Cheeseman,CJ,Chris,COD R; > Dixon,JS,Johnny,COD > >> R > >> >>>>>>>>> Subject: Re: [paws] WGLC for > >> >>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel=20 > >> >>>>>>>>> reporting > >> >>>>>>>>> > >> >>>>>>>>> Ahh. I think I see where the request and my=20 > >> >>>>>>>>> understanding divurge. If the idea here is that the=20 > >> >>>>>>>>> master must provide, > in > >> >>>>>>>>> the request, an indication of what channels it expects to > >> use, > >> >>>>>>>>> I can at least understand that. I will return to > technical > >> >>>>>>>>> concerns in a moment. > >> >>>>>>>>> > >> >>>>>>>>> However, when you say "provide channel usage information, > in > >> >>>>>>>>> order to evaluate interference", what that says to me is=20 > >> >>>>>>>>> providing, during operation, information as to what > channels > >> >>>>>>>>> are being used, and at what power levels. That is what > would > >> >>>>>>>>> be needed to analyze actual interference effects. And=20 > >> >>>>>>>>> that > is > >> >>>>>>>>> out of scope as I understand our scope. > >> >>>>>>>>> > >> >>>>>>>>> I do see a technical difficulty with having the master > >> provide, > >> >>>>>>>>> as part of either registering or requesting spectrum=20 > >> >>>>>>>>> information, what channels it intends to use. It doesn;t > >> know > >> >>>>>>>>> what channels it intends to use. It intends to use some > >> number > >> >>>>>>>>> of available channels. It will figure out which ones=20 > >> >>>>>>>>> when > it > >> >>>>>>>>> is told what is available. How can it send that > information > >> in > >> >>>>>>>>> the request? > >> >>>>>>>>> > >> >>>>>>>>> Yours, Joel > >> >>>>>>>>> > >> >>>>>>>>> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: > >> >>>>>>>>>> Hi, > >> >>>>>>>>>> > >> >>>>>>>>>> There is a similarity here with device ID. In context of > >> PAWS > >> >>>>>>>>>> we are not concerned with why a device ID is required by > a > >> >>>>>>>>>> regulator, we accept it is a requirement from a=20 > >> >>>>>>>>>> regulator > >> and > >> >>>>>>>>>> include it to the protocol. Ofcom identifies in 3.18& > 3.19 > >> >>>>>>>>>> that channel usage information is required and thus we > need > >> >>>>>>>>>> to include this information. Since the master must > provide > >> >>>>>>>>>> this information prior to transmitting, PAWS will not=20 > >> >>>>>>>>>> function in the UK without this information and thus I=20 > >> >>>>>>>>>> believe channel usage information is integral to the > channel > >> >>>>>>>>>> request& response messaging. > >> >>>>>>>>>> > >> >>>>>>>>>> Kind Regards, Scott > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> On 3/6/12 10:30 AM, "ext Joel M. > >> >>>>>>>>>> Halpern" wrote: > >> >>>>>>>>>> > >> >>>>>>>>>>> I would draw a distinction. Ofcom regulations about=20 > >> >>>>>>>>>>> whitespace requests are very much relevant. Ofcom=20 > >> >>>>>>>>>>> regulations about notification of dynamic behavior > (which > >> >>>>>>>>>>> spectrum is being used) are not in scope as I=20 > >> >>>>>>>>>>> understand the earlier discussions, particularly the=20 > >> >>>>>>>>>>> chartering discussions. > >> >>>>>>>>>>> > >> >>>>>>>>>>> Yours, Joel > >> >>>>>>>>>>> > >> >>>>>>>>>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> The ofcom requirements are very much relevant to the=20 > >> >>>>>>>>>>>> scope of the PAWS WG. The only other regulatory=20 > >> >>>>>>>>>>>> requirements that we have today is the FCC. Ofcom=20 > >> >>>>>>>>>>>> requirements are a good addition to the set. > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> -Raj > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> On 3/6/12 10:03 AM, "ext > >> >>>>>>>>>>>> andy.sago@bt.com" wrote: > >> >>>>>>>>>>>> > >> >>>>>>>>>>>>> Hi Joel > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> There's no language I can find in the charter that=20 > >> >>>>>>>>>>>>> explicitly puts this out of scope. On the other hand,=20 > >> >>>>>>>>>>>>> the charter says that the group will "consider input=20 > >> >>>>>>>>>>>>> from regulatory entities", and this is one of the=20 > >> >>>>>>>>>>>>> requirements from Ofcom that they have just published. > >> >>>>>>>>>>>>> The protocol will be worthless for the UK if it omits=20 > >> >>>>>>>>>>>>> some requirements. > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> Regards > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> Andy > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> -----Original Message----- From: Joel M. Halpern=20 > >> >>>>>>>>>>>>> [mailto:jmh@joelhalpern.com] Sent: 06 March 2012=20 > >> >>>>>>>>>>>>> 15:53 > >> >>>>>>>>>>>>> To: Sago,AJ,Andy,COD R Cc: paws@ietf.org;=20 > >> >>>>>>>>>>>>> Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for > >> >>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: > channel > >> >>>>>>>>>>>>> reporting > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> As I understand, the information you are asking for=20 > >> >>>>>>>>>>>>> is explicitly out of scope for the working group.=20 > >> >>>>>>>>>>>>> Yours, Joel > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: > >> >>>>>>>>>>>>>> All > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Comparing the draft with the Ofcom requirements at > >> >>>>>>>>>>>>>> http://www.cept.org/Documents/se- > >> >>>>> 43/4161/SE43(12)Info03_Draft-UK-r > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>> egul > >> >>>>>>>>>>>>>> atory-requirements-for-white-space-devices-in-the- > UHF- > >> TV- > >> >>>>> band, > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>> I believe the WG draft is deficient in the area of reporting > >> >>>>>>>>>>>>>> frequencies and powers actually used by masters and=20 > >> >>>>>>>>>>>>>> slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom=20 > >> >>>>>>>>>>>>>> intends to collect this data to assesses the impact=20 > >> >>>>>>>>>>>>>> of aggregate interference into other services. It=20 > >> >>>>>>>>>>>>>> would also provide usage information (frequency in > >> >>>>>>>>>>>>>> use) that would inform the operation of a kill=20 > >> >>>>>>>>>>>>>> switch capability. I suggest this deficiency can be=20 > >> >>>>>>>>>>>>>> remedied with the following changes: > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> New P requirements (probably best placed following > >> >>>>>>>>>>>>>> P.12): > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> P.12bis: The protocol MUST support a channel usage=20 > >> >>>>>>>>>>>>>> message from the slave device to the master device. > >> >>>>>>>>>>>>>> The channel usage message MUST include parameters as=20 > >> >>>>>>>>>>>>>> required by local regulatory requirement. These=20 > >> >>>>>>>>>>>>>> parameters MAY include device ID, manufacturer's=20 > >> >>>>>>>>>>>>>> serial number, channel usage and power level=20 > >> >>>>>>>>>>>>>> information. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> P.12ter: The protocol MUST support a channel usage=20 > >> >>>>>>>>>>>>>> message from the master device to the database. The=20 > >> >>>>>>>>>>>>>> channel usage message MUST include parameters as=20 > >> >>>>>>>>>>>>>> required by local regulatory requirement for the=20 > >> >>>>>>>>>>>>>> master and its associated slaves. These parameters=20 > >> >>>>>>>>>>>>>> MAY include device ID, manufacturer's serial number,=20 > >> >>>>>>>>>>>>>> channel usage and power level information. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> P.12qua: The protocol MUST support a channel usage=20 > >> >>>>>>>>>>>>>> message acknowledgement. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> New O requirements (probably best placed following > >> >>>>>>>>>>>>>> O13): > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> O.13bis: According to local regulatory policy,=20 > >> >>>>>>>>>>>>>> after connecting to a master device's radio network=20 > >> >>>>>>>>>>>>>> a slave device MAY inform the master device of the=20 > >> >>>>>>>>>>>>>> actual channel usage. The slave MUST include=20 > >> >>>>>>>>>>>>>> parameters required by local regulatory policy, e.g.=20 > >> >>>>>>>>>>>>>> device ID, manufacturer's serial number, channel=20 > >> >>>>>>>>>>>>>> usage and power level information. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> O.13ter: According to local regulatory policy, a=20 > >> >>>>>>>>>>>>>> master device MAY inform the database of the actual=20 > >> >>>>>>>>>>>>>> channel usage of the master and its slaves. The=20 > >> >>>>>>>>>>>>>> master MUST include parameters required by local=20 > >> >>>>>>>>>>>>>> regulatory policy, e.g. device ID, manufacturer's=20 > >> >>>>>>>>>>>>>> serial number, channel usage and power level=20 > >> >>>>>>>>>>>>>> information of the master and its slaves. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> New steps could be introduced into one or more use=20 > >> >>>>>>>>>>>>>> cases to cover these Ofcom requirements, e.g. new=20 > >> >>>>>>>>>>>>>> steps 6bis and 9bis in the hotspot use case at > >> >>>>>>>>>>>>>> 4.2.1: > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 6bis. Prior to initiating transmission, if required=20 > >> >>>>>>>>>>>>>> by local regulation, the master/AP informs the=20 > >> >>>>>>>>>>>>>> database of the channel and power level it has=20 > >> >>>>>>>>>>>>>> chosen. This is repeated for each slave that=20 > >> >>>>>>>>>>>>>> associated with the master. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 9bis. Prior to initiating transmission, if required=20 > >> >>>>>>>>>>>>>> by local regulation, the slave informs the master/AP=20 > >> >>>>>>>>>>>>>> of the channel and power level it has chosen, and=20 > >> >>>>>>>>>>>>>> the master/AP relays this information to the database. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> - end of new text - > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> For information, for those not accessing the url in=20 > >> >>>>>>>>>>>>>> the first paragraph of this email, the full Ofcom=20 > >> >>>>>>>>>>>>>> requirements leading to this new PAWS text are as > >> >>>>>>>>>>>>>> follows: > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 3.18 After receiving instructions from a WSDB in=20 > >> >>>>>>>>>>>>>> relation to the maximum permitted EIRPs over the DTT=20 > >> >>>>>>>>>>>>>> channels, and prior to initiating transmissions=20 > >> >>>>>>>>>>>>>> within the UHF TV band, a master WSD must=20 > >> >>>>>>>>>>>>>> communicate to the WSDB the following information: > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 3.18.1 The lower and upper frequency boundaries^13=20 > >> >>>>>>>>>>>>>> of the in-block emissions of the master WSD, and=20 > >> >>>>>>>>>>>>>> those of the in-block emissions of its associated=20 > >> >>>>>>>>>>>>>> slaves. A lower frequency will be specified as (470=20 > >> >>>>>>>>>>>>>> + 8k + > >> >>>>>>>>>>>>>> 0.2n) MHz, with the corresponding upper frequency=20 > >> >>>>>>>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3?4 k 3?4 > >> >>>>>>>>>>>>>> 39, 0 3?4 n 3?4 39, 1 3?4 m 3?4 40, and n< m. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 3.18.2 The maximum in-block EIRP spectral densities=20 > >> >>>>>>>>>>>>>> (in dBm/(0.2 MHz)) that the master WSD, and its=20 > >> >>>>>>>>>>>>>> associated slaves, actually radiate between each=20 > >> >>>>>>>>>>>>>> reported lower frequency boundary and its=20 > >> >>>>>>>>>>>>>> corresponding upper frequency boundary. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Footnote 13 states: > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> The use of upper and lower frequency boundaries=20 > >> >>>>>>>>>>>>>> (defined over a 200 kHz raster) allows a WSDB to=20 > >> >>>>>>>>>>>>>> collect more granular information with regards to=20 > >> >>>>>>>>>>>>>> the usage of the frequency resource by narrowband=20 > >> >>>>>>>>>>>>>> WSD technologies. The upper and lower frequencies of=20 > >> >>>>>>>>>>>>>> a boundary pair do not straddle a DTT channel boundary. > >> >>>>>>>>>>>>>> Note that a WSD may transmit over multiple,=20 > >> >>>>>>>>>>>>>> non-contiguous, whole DTT channels or fractions of=20 > >> >>>>>>>>>>>>>> DTT channels. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 3.19 A master WSD must be able to receive the=20 > >> >>>>>>>>>>>>>> following information^14 from a WSDB: > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in the > >> >>>>>>>>>>>>>> context of 3.18, that the reported information on=20 > >> >>>>>>>>>>>>>> the DTT channels and EIRP spectral densities=20 > >> >>>>>>>>>>>>>> actually used by the master and slave WSDs were=20 > >> >>>>>>>>>>>>>> received successfully by the WSDB^18 ]. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Footnote 14 states: > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 14 While the communication of some of this=20 > >> >>>>>>>>>>>>>> information from a WSDB to a master WSD is optional,=20 > >> >>>>>>>>>>>>>> master WSDs must be able to receive and interpret=20 > >> >>>>>>>>>>>>>> these. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Footnote 18 states: > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> 18 This forms part of a handshake protocol and may=20 > >> >>>>>>>>>>>>>> be an area where industry could harmonise without=20 > >> >>>>>>>>>>>>>> the need for an explicit requirement in the regulations= . > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Regards > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Andy > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> *From:*paws-bounces@ietf.org=20 > >> >>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] *On Behalf Of=20 > >> >>>>>>>>>>>>>> *Gabor.Bajko@nokia.com *Sent:* 05 March 2012 19:46 > >> >>>>>>>>>>>>>> *To:* paws@ietf.org *Subject:* [paws] WGLC for > >> >>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> The authors of the use cases and requirements draft=20 > >> >>>>>>>>>>>>>> have just posted a new version of the draft and=20 > >> >>>>>>>>>>>>>> indicated that there are no unresolved=20 > >> >>>>>>>>>>>>>> comments/issues they are aware of. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Therefore, I'd like to initiate a WG Last Call for=20 > >> >>>>>>>>>>>>>> comments on > >> >>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-paws- > >> problem- > >> >>>>> stmt-u > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>> seca > >> >>>>>>>>>>>>>> ses-rqmts-03.txt > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Please review the draft and send your comments to=20 > >> >>>>>>>>>>>>>> the list by March 20th, 2012. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> If you review the draft and have no comments, send a=20 > >> >>>>>>>>>>>>>> note to the list that the draft is good as it is, we=20 > >> >>>>>>>>>>>>>> need these notes as much as we need the actual=20 > >> >>>>>>>>>>>>>> comments. > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> Thanks, Gabor > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> > > >> > _______________________________________________ > >> > paws mailing list > >> > paws@ietf.org > >> > https://www.ietf.org/mailman/listinfo/paws > >> > > >> _______________________________________________ > >> paws mailing list > >> paws@ietf.org > >> https://www.ietf.org/mailman/listinfo/paws > >> > >> _______________________________________________ > >> paws mailing list > >> paws@ietf.org > >> https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ > >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 ________________________________ ***************************************************************************= *************************************** 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. ***************************************************************************= *************************************** _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From paul@marvell.com Thu Mar 8 18:16:03 2012 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 7358311E8073 for ; Thu, 8 Mar 2012 18:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.127 X-Spam-Level: X-Spam-Status: No, score=-5.127 tagged_above=-999 required=5 tests=[AWL=-1.155, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4, 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 AChULpMg4k0Z for ; Thu, 8 Mar 2012 18:16:01 -0800 (PST) Received: from na3sys009aog116.obsmtp.com (na3sys009aog116.obsmtp.com [74.125.149.240]) by ietfa.amsl.com (Postfix) with ESMTP id 1C40911E8072 for ; Thu, 8 Mar 2012 18:15:56 -0800 (PST) Received: from sc-owa02.marvell.com ([65.219.4.130]) (using TLSv1) by na3sys009aob116.postini.com ([74.125.148.12]) with SMTP ID DSNKT1ln0hgndGyw8DF6SIvowvJRt9RxpF+U@postini.com; Thu, 08 Mar 2012 18:16:00 PST Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Thu, 8 Mar 2012 18:15:21 -0800 From: Paul Lambert To: "Das, Subir" , 'Siew Yoon Tan' , "Zuniga, Juan Carlos" , "Basavaraj.Patil@nokia.com" , "gerald.chouinard@sympatico.ca" , "jmh@joelhalpern.com" , "scott.probasco@nokia.com" Date: Thu, 8 Mar 2012 18:15:20 -0800 Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting Thread-Index: AQHM/YFmF0824TXodkK/mH1uWWNaL5ZhGdfggAAfIxA= Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D0157A034B37@SC-VEXCH2.marvell.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 X-Mailman-Approved-At: Thu, 08 Mar 2012 18:34:00 -0800 Cc: "paws@ietf.org" , "presnick@qualcomm.com" , Reza Karimi , "johnny.dixon@bt.com" , "chris.cheeseman@bt.com" Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 02:16:03 -0000 >I have a question here. Is it really an acknowledgement or we would like >to see a kind of notification message that includes channel, and other >parameters? What if it's multiple channels? What happens if the device adapts and chan= ges between modulation technique or bandwidth? Does every change over the = air need to be indicated to the GDB? This Channel acknowledgement does not seem useful and would limit real worl= d behaviors (like channel and modulation adaptation). If viewed as a potential regulatory requirement - does this imply we need t= o parameterize the protocol to have different behaviors in different region= s? Paul > >Regards, >_Subir > >-----Original Message----- >From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >Siew Yoon Tan >Sent: Thursday, March 08, 2012 4:06 PM >To: Zuniga, Juan Carlos; Basavaraj.Patil@nokia.com; >gerald.chouinard@sympatico.ca; jmh@joelhalpern.com; >scott.probasco@nokia.com >Cc: paws@ietf.org; presnick@qualcomm.com; Reza Karimi; >johnny.dixon@bt.com; chris.cheeseman@bt.com >Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >rqmts-03:channel reporting > >Dear All, > >Regarding Ofcom's requirement to have a return channel as part of the >protocol between the WSD and WSDB, I would like to confirm to following >sequence of messaging > >Channel request >Channel response >Channel acknowledgement > >which was raised in an earlier email to this list. > >Our view is that it would be beneficial to define the protocol between >WSD and WSDB that supports this requirement even though how the >information could be used is still subject to discussion in the UK. > > >Best regards, > >Siew Yoon > > >________________________________________ >From: paws-bounces@ietf.org [paws-bounces@ietf.org] on behalf of Zuniga, >Juan Carlos [JuanCarlos.Zuniga@InterDigital.com] >Sent: 08 March 2012 20:41 >To: Basavaraj.Patil@nokia.com; gerald.chouinard@sympatico.ca; >jmh@joelhalpern.com; scott.probasco@nokia.com >Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >chris.cheeseman@bt.com >Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >rqmts-03:channel reporting > >Hi Raj, > >I was reusing the language used from Gerald (which I know is familiar to >people working on IEEE 802 WS groups): > >>> [GC] You got it. This would be useless for spectrum regulators. One >>> should realize that, from the spectrum regulator's point of view, the >>> second and third messages could be iterated upon to optimize the >>> spectrum use. >>> Knowing >>> what channels the systems in an area are using, the spectrum >>> regulators and/or other entities such as those taking care of >>> coexistence could use the database in near-real-time to iterate on >>> the two last messages to reduce the range of channels that some >>> systems may use once they know precisely what channels are being used >>> in the area. The PAWS protocol would carry the information back and >>> forth but would not be involved in such spectrum use optimization. > >Having said that, I have no issue sticking to the WSDB terminology. I >like keeping things simple :) > >JC > >> -----Original Message----- >> From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] >> Sent: Thursday, March 08, 2012 3:33 PM >> To: Zuniga, Juan Carlos; gerald.chouinard@sympatico.ca; >> jmh@joelhalpern.com; scott.probasco@nokia.com >> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >> chris.cheeseman@bt.com >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >> rqmts-03:channel reporting >> >> >> Hi JC, >> >> Where/why did the coexistence manager come into the picture? Your >> comment about "communicating back to the WSDB/coexistence manager" may >> result in further misunderstanding. If we simply stick to to WSDB I >> think we are okay. >> >> -Raj >> >> On 3/8/12 2:25 PM, "ext Zuniga, Juan Carlos" >> wrote: >> >> >So, from Gerald and Andy's comments, it seems like from the point of >> view >> >of (at least) two regulatory entities it is important for the >> >protocol >> to >> >allow communicating back to the WSDB/coexistence manager the actual >> >channel usage after the first query is made. >> > >> >This is to me a very clear requirement. >> > >> >The actual messages/IEs that would carry this information should be >> >discussed as part of the solution document, and not the requirements. >> > >> >JC >> > >> >> -----Original Message----- >> >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >> >> Behalf >> Of >> >> Gerald Chouinard >> >> Sent: Thursday, March 08, 2012 1:59 PM >> >> To: 'Joel M. Halpern'; scott.probasco@nokia.com >> >> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >> >> chris.cheeseman@bt.com >> >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >> >> rqmts-03:channel reporting >> >> >> >> Joel, Scott, >> >> >> >> Interesting discussion! See my comments in line below. >> >> >> >> Gerald >> >> >> >> -----Original Message----- >> >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >> >> Behalf >> Of >> >> Joel >> >> M. Halpern >> >> Sent: Thursday, 08 March, 2012 13:17 >> >> To: scott.probasco@nokia.com >> >> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >> >> chris.cheeseman@bt.com >> >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >> >> rqmts-03: >> >> channel reporting >> >> >> >> So why won't the device simply say "I will use all of this?" >> >> [GC] This would defeat the purpose of the acknowledgement message. >> >> After all, that way it needs to do less work with the database. >> >> And >> it >> >> can change frequencies when it wants. >> >> Given that the stated goal of the Ofcom requriement was to be able >> to >> >> analyze interference effects, it seems that this will not actually >> lead >> >> to them getting what they want, even if it does comply with the >> >> regulations. >> >> [GC] You got it. This would be useless for spectrum regulators. >> >> One should realize that, from the spectrum regulator's point of >> >> view, the >> second >> >> and >> >> third messages could be iterated upon to optimize the spectrum use. >> >> Knowing >> >> what channels the systems in an area are using, the spectrum >> regulators >> >> and/or other entities such as those taking care of coexistence >> >> could use the database in near-real-time to iterate on the two last >> >> messages to reduce the range of channels that some systems may use >> >> once they know precisely what channels are being used in the area. >> >> The PAWS protocol would carry >> the >> >> information back and forth but would not be involved in such >> spectrum >> >> use >> >> optimization. >> >> >> >> Yours, >> >> joel >> >> >> >> On 3/8/2012 1:09 PM, scott.probasco@nokia.com wrote: >> >> > Hi Peter, >> >> > >> >> > Answers below. >> >> > >> >> > Kind Regards, >> >> > Scott >> >> > >> >> > On 3/8/12 11:39 AM, "ext Peter Saint-Andre" >> >> wrote: >> >> > >> >> >> Hi Scott, I have two clarifying questions: >> >> >> >> >> >> 1. Does the device know, when it receives the channel response, >> >> which >> >> >> channel it will actually use? >> >> > Scott->This is all new and I am not aware of any existing >> >> implementations. >> >> > I would argue that the device must decide what channel(s) it will >> use >> >> when >> >> > it receives the channel response. >> >> [GC] Agree with Scott but this is only a portion of the >> considerations. >> >> If a >> >> device was to operate on its own, this would be true but a >> >> communication device usually implies at least 2 devices to >> >> communicate. Hence, the choice of the channel to be used will need >> >> to be negotiated between the two devices before a choice can be >> >> made. The chosen channel will belong to the >> set >> >> of >> >> available channels that is common to both devices. Remember that >> some >> >> channels may be available at one device and not at the other >> >> because >> of >> >> their geolocation or other reason. Extending this concept to a star >> >> network topology, the channel that will be selected by this network >> >> will >> have >> >> to >> >> belong to the set of channels that are available to all devices. >> Each >> >> device >> >> will not be able to decide by itself which channel it wants to use. >> >> >> >> This is why in such a star topology, it makes sense that the slave >> >> devices to a base station or access point be represented by the >> >> base station acting as the master on their behalf to query the >> >> database and receive the list of available channels (and/or maximum >> >> EIRP per channel). It is then the responsibility of the base >> >> station to identify the set of available channels that is common >> >> for itself and all its slaves to decide on the >> channel >> >> that >> >> the network will use. As you can see, in this case, there is no >> >> need for each slave to receive its list of available channels. On >> >> its own, it would not know what to do with it. The only thing that >> >> needs to be sent >> from >> >> the >> >> master device to its slaves is the resulting operating channel. >> >> >> >> I a more sophisticated operation, the master device may add one or >> >> a few backup channels extracted from the common set of available >> >> channel >> to >> >> the >> >> message going to its slave so that if a change in channel >> availability >> >> occurs, an instantaneous switch to the next backup channel can be >> made >> >> without any further signaling, thus providing for a channel switch >> that >> >> is >> >> transparent to the user. It is the scheme that has been included in >> the >> >> IEEE >> >> 802.22-2011 Standard. This is why I don't believe that PAWS should >> get >> >> involved in defining this signaling between the base station and >> >> its slaves devices. >> >> >> >> >> >> 2. If the device then uses another channel or a different >> channel, >> >> does >> >> >> it need to report that change to the database? >> >> > Scott->My interpretation of section 3.18 is that the device can >> only >> >> > transmit within the upper& lower frequencies returned in the >> >> > acknowledgment. I do not (quickly) find any reference in the >> >> requirements >> >> > to changing channels. Thus operationally it could be that the >> channel >> >> > request process must be repeated before the device can use a >> >> different >> >> > channel (frequencies). >> >> [GC] If the process involves 2 messages, then, the device and its >> >> associated devices could change channels at will as long as all >> >> these channels belong to the set of available channel. However, if >> >> the third message is added, it would make sense that the master >> >> device reports to the database any channel change that would occur >> >> to the database, otherwise, the status of >> the >> >> spectrum occupation would be wrong at any moment and would be >> useless >> >> for >> >> the purpose of any spectrum usage optimization such as coexistence. >> >> >> >> >> >> Thanks! >> >> >> >> >> >> Peter >> >> >> >> >> >> On 3/8/12 10:17 AM, scott.probasco@nokia.com wrote: >> >> >>> Hi, >> >> >>> >> >> >>> The point from Brian is very relevant: >> >> >>> >> >> >>> Channel request >> >> >>> Channel response >> >> >>> Channel acknowledgement >> >> >>> >> >> >>> What Ofcom does with the information in the acknowledgement >> >> >>> does >> >> not >> >> >>> matter. As the regulator in UK, they write rules that must be >> >> followed >> >> >>> in >> >> >>> order to operate a whitespace radio in the UK. I believe the >> scope >> >> of >> >> >>> the >> >> >>> WG must be focused on a working solution. If this is simple >> channel >> >> >>> request& response in one regulator's domain, PAWS can support >> >> this. If >> >> >>> it >> >> >>> means a channel request, response and acknowledgement in >> >> >>> another regulator's domain, PAWS can support this. As a >> >> >>> participating >> >> member of >> >> >>> the work group, I believe the scope should be basic working >> >> solution, >> >> >>> not >> >> >>> limited to a specific number of messages. >> >> >>> >> >> >>> Kind Regards, >> >> >>> Scott >> >> >>> >> >> >>> >> >> >>> >> >> >>> On 3/8/12 11:11 AM, "ext Zuniga, Juan Carlos" >> >> >>> wrote: >> >> >>> >> >> >>>> Peter, Nancy, >> >> >>>> >> >> >>>> I agree should design a protocol with the best of our current >> >> >>>> knowledge, and that should be accounting for all the known >> >> >>>> regulations at >> >> present >> >> >>>> time. We should not limit the scope with the purpose of >> designing >> >> a >> >> >>>> protocol 'faster'. Our goal is not only to design a WSDB >> protocol. >> >> Our >> >> >>>> goal is to design a WSDB protocol that is USEFUL to the >> community. >> >> >>>> >> >> >>>> The charter does state that >> >> >>>> >> >> >>>> "...the group should also reach out to other potential >> >> >>>> "customers" for a white space database access method and >> consider >> >> input >> >> >>> >from regulatory entities that are involved in the >> >> >>> >specification >> of >> >> the >> >> >>>> rules for secondary use of spectrum in specific radio bands. " >> >> >>>> >> >> >>>> I think that is exactly what we are doing now. >> >> >>>> >> >> >>>> Regarding whether the types of requirements belong to #1 or >> >> >>>> #2, >> I >> >> >>>> believe >> >> >>>> it is more of #1 type, as the information to be exchanged >> >> >>>> would >> be >> >> >>>> known >> >> >>>> after the initial query/response. >> >> >>>> >> >> >>>> If we know it today, I see no reason why we should not work on >> it >> >> in >> >> >>>> the >> >> >>>> first phase of the work. >> >> >>>> >> >> >>>> Regards, >> >> >>>> >> >> >>>> Juan Carlos >> >> >>>> >> >> >>>>> -----Original Message----- >> >> >>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >> >> Behalf >> >> >>>>> Of >> >> >>>>> Peter Saint-Andre >> >> >>>>> Sent: Thursday, March 08, 2012 11:59 AM >> >> >>>>> To: Nancy Bravin >> >> >>>>> Cc: paws@ietf.org; johnny.dixon@bt.com; >> chris.cheeseman@bt.com; >> >> Pete >> >> >>>>> Resnick >> >> >>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- >> >> usecases- >> >> >>>>> rqmts-03: channel reporting >> >> >>>>> >> >> >>>>> Hi Nancy, >> >> >>>>> >> >> >>>>> You are absolutely right that different locales will have >> >> different >> >> >>>>> rules and requirements. We need to understand those, and work >> to >> >> >>>>> address >> >> >>>>> them if possible (although we don't necessarily need to >> address >> >> them >> >> >>>>> all >> >> >>>>> at the same time). I see several kinds of requirements: >> >> >>>>> >> >> >>>>> 1. Some requirements might lead to features beyond the >> >> query/response >> >> >>>>> protocol we've envisioned so far. One example might be real- >> time >> >> >>>>> reporting about the channels that a device is actually using. >> In >> >> my >> >> >>>>> opinion, it would be best to handle those in the next phase >> >> >>>>> of >> >> work, >> >> >>>>> because as far as I can see they are outside the scope of our >> >> charter. >> >> >>>>> >> >> >>>>> 2. Some requirements might be handled through by defining >> >> additional >> >> >>>>> fields that can be included in the query or response. We >> >> definitely >> >> >>>>> planned for that when working on the charter with the IESG: >> >> >>>>> >> >> >>>>> In addition, the particular >> >> >>>>> data exchanged between a device and a database might >> >> >>>>> depend >> on >> >> the >> >> >>>>> ranges of radio spectrum that are to be used, the >> requirements >> >> of >> >> >>>>> the >> >> >>>>> database operators and their governing regulations, and >> other >> >> >>>>> factors. >> >> >>>>> Therefore, the database access method and the >> query/response >> >> data >> >> >>>>> formats that are exchanged using that method need to be >> >> designed >> >> for >> >> >>>>> extensibility rather than being tied to any specific >> spectrum, >> >> >>>>> country, or phy/mac/air interface. >> >> >>>>> >> >> >>>>> It's unclear to me right now if the Ofcom requirement fits >> into >> >> #1 or >> >> >>>>> #2, which is why we're having this discussion. :) >> >> >>>>> >> >> >>>>> Peter >> >> >>>>> >> >> >>>>> On 3/7/12 8:17 PM, Nancy Bravin wrote: >> >> >>>>>> Peter and all, >> >> >>>>>> >> >> >>>>>> I agree that it is important to revisit now, so that in the >> >> future, >> >> >>>>>> it will be easy to align things in their proper place. Every >> >> country >> >> >>>>>> may have different regulations, spectrum, policy and what >> >> >>>>>> responsibility is in the domain of the system, and what >> >> >>>>>> comes >> >> under >> >> >>>>>> the PAWS charter is important. Maybe some separation might >> be >> >> >>>>>> possible, and dividing and clarifying issues now will help >> >> >>>>>> in >> >> the >> >> >>>>>> future. Certainly it seems that the FCC may change some >> rules, >> >> and >> >> >>>>>> we know that Ofcom is not yet finished with their >> regulations. >> >> Canada >> >> >>>>>> has their own, and other countries are working on this as >> well. >> >> Just >> >> >>>>>> a thought...Sharing is a realistic goal...as is off >> loading... >> >> Or you >> >> >>>>>> slim line and every 6 months decide what to incorporate in >> the >> >> >>>>>> protocol based on new information, new ideas, new innovation >> new >> >> >>>>>> regulations and maybe spend more time than you could if >> >> addressed >> >> >>>>>> now. >> >> >>>>>> >> >> >>>>>> That way you leave the door open and outside of referencing >> what >> >> is >> >> >>>>>> known today, by referencing regulations i.e. Ofcom, FCC, >> >> Industry >> >> >>>>>> Canada etc as of XX-XX-XXXX date. Out of scope not something >> we >> >> know >> >> >>>>>> enough about to say at this point, In my opinion. >> >> >>>>>> >> >> >>>>>> My 2 cents.. >> >> >>>>>> >> >> >>>>>> Sincerely, Nancy >> >> >>>>>> >> >> >>>>>> On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote: >> >> >>>>>> >> >> >>>>>>> >> >> >>>>>>> >> >> >>>>>>> As your responsible Area Director (until March 28, when >> >> >>>>>>> Pete Resnick will take over from me), I have reviewed this >> thread. >> >> >>>>>>> >> >> >>>>>>> In my opinion (I am happy to be proven wrong), this new >> >> requirement >> >> >>>>>>> goes beyond what the charter defined as the scope of this >> >> working >> >> >>>>>>> group, which was to enable a device to discover the white >> space >> >> >>>>>>> available to it in its current location. Reporting usage >> back >> >> to >> >> >>>>>>> the database is simply not mentioned in the charter. >> >> >>>>>>> >> >> >>>>>>> Earlier in this thread, Andy Sago wrote: >> >> >>>>>>> >> >> >>>>>>> There's no language I can find in the charter that >> explicitly >> >> puts >> >> >>>>>>> this out of scope. >> >> >>>>>>> >> >> >>>>>>> An IETF charter defines what the working group shall work >> on. >> >> Many >> >> >>>>>>> interesting features could be developed here. However, it >> >> >>>>>>> is >> >> not >> >> >>>>>>> the job of the charter to mention explicitly that each of >> those >> >> >>>>>>> interesting features is out of scope. >> >> >>>>>>> >> >> >>>>>>> The charter does say: >> >> >>>>>>> >> >> >>>>>>> Once the device learns of the available white space (e.g., >> in a >> >> TV >> >> >>>>>>> white space implementation, the list of available channels >> at >> >> that >> >> >>>>>>> location), it can then select one of the bands from the >> >> >>>>>>> list >> >> and >> >> >>>>>>> begin to transmit and receive on the selected band. >> >> >>>>>>> >> >> >>>>>>> This text might have assumed that no further communication >> or >> >> >>>>>>> authorization was required in order to select one of the >> bands >> >> from >> >> >>>>>>> the list and then transmit/receive. Perhaps that assumption >> was >> >> >>>>>>> mistaken. If so, it would be good to have a discussion >> >> >>>>>>> about >> >> that, >> >> >>>>>>> so we can determine if we need to revisit the assumptions >> >> >>>>>>> we >> >> made >> >> >>>>>>> early on. If in fact we made some faulty or limited >> >> assumptions, >> >> >>>>>>> then let's get that out in the open. >> >> >>>>>>> >> >> >>>>>>> Peter >> >> >>>>>>> >> >> >>>>>>> On 3/7/12 9:40 AM, Rosen, Brian wrote: >> >> >>>>>>>> I'd also suggest that >> our >> >> >>>>>>>> charter limitation is really support for sharing of >> whitespace >> >> by >> >> >>>>>>>> whitespace devices. Reporting what you use is not >> >> >>>>>>>> sharing, >> >> it's >> >> >>>>>>>> just data gathering. >> >> >>>>>>>> >> >> >>>>>>>> The point of excluding sharing was to eliminate the >> >> complexities >> >> >>>>>>>> of what constituted fairness, and what kinds of >> communication >> >> >>>>>>>> might be needed between databases, where more than one >> could >> >> >>>>>>>> supply available whitespace in a band. This doesn't have >> any >> >> of >> >> >>>>>>>> those issues, As long as it's just sending information, I >> >> don't >> >> >>>>>>>> have a problem. Once the database is supposed to do >> anything >> >> >>>>>>>> with it that involves changing what spectrum it reports, >> then >> >> I >> >> >>>>>>>> think we cross the line. >> >> >>>>>>>> >> >> >>>>>>>> Brian >> >> >>>>>>>> >> >> >>>>>>>> On Mar 6, 2012, at 12:28 PM, >> >> >>>>>>>> wrote: >> >> >>>>>>>> >> >> >>>>>>>>> Joel >> >> >>>>>>>>> >> >> >>>>>>>>> Indeed, the regulator has not described the process or >> >> provided >> >> >>>>>>>>> a flow diagram, so there may be some wrinkles, but we >> >> >>>>>>>>> need >> to >> >> >>>>>>>>> provide for their intent. To answer your question, the >> >> channels >> >> >>>>>>>>> that the master will use are sent in a separate message >> >> >>>>>>>>> (described in P.12 ter), that occurs after the master >> >> receives >> >> >>>>>>>>> the response to its channel request, but before the >> >> >>>>>>>>> master >> >> can >> >> >>>>>>>>> transmit. At this point, it knows what channels are >> >> available, >> >> >>>>>>>>> and which one it will use. As far as the slaves are >> >> concerned, >> >> >>>>>>>>> as they associate, the master will need to gather their >> >> details >> >> >>>>>>>>> and send further channel usage messages to the database >> >> >>>>>>>>> on their behalf. >> >> >>>>>>>>> >> >> >>>>>>>>> Regards >> >> >>>>>>>>> >> >> >>>>>>>>> Andy >> >> >>>>>>>>> >> >> >>>>>>>>> -----Original Message----- From: paws-bounces@ietf.org >> >> >>>>>>>>> [mailto:paws-bounces@ietf.org] On Behalf Of Joel M. >> Halpern >> >> >>>>>>>>> Sent: 06 March 2012 17:05 To: scott.probasco@nokia.com >Cc: >> >> >>>>>>>>> paws@ietf.org; Cheeseman,CJ,Chris,COD R; >> Dixon,JS,Johnny,COD >> >> R >> >> >>>>>>>>> Subject: Re: [paws] WGLC for >> >> >>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel >> >> >>>>>>>>> reporting >> >> >>>>>>>>> >> >> >>>>>>>>> Ahh. I think I see where the request and my >> >> >>>>>>>>> understanding divurge. If the idea here is that the >> >> >>>>>>>>> master must provide, >> in >> >> >>>>>>>>> the request, an indication of what channels it expects to >> >> use, >> >> >>>>>>>>> I can at least understand that. I will return to >> technical >> >> >>>>>>>>> concerns in a moment. >> >> >>>>>>>>> >> >> >>>>>>>>> However, when you say "provide channel usage information, >> in >> >> >>>>>>>>> order to evaluate interference", what that says to me is >> >> >>>>>>>>> providing, during operation, information as to what >> channels >> >> >>>>>>>>> are being used, and at what power levels. That is what >> would >> >> >>>>>>>>> be needed to analyze actual interference effects. And >> >> >>>>>>>>> that >> is >> >> >>>>>>>>> out of scope as I understand our scope. >> >> >>>>>>>>> >> >> >>>>>>>>> I do see a technical difficulty with having the master >> >> provide, >> >> >>>>>>>>> as part of either registering or requesting spectrum >> >> >>>>>>>>> information, what channels it intends to use. It doesn;t >> >> know >> >> >>>>>>>>> what channels it intends to use. It intends to use some >> >> number >> >> >>>>>>>>> of available channels. It will figure out which ones >> >> >>>>>>>>> when >> it >> >> >>>>>>>>> is told what is available. How can it send that >> information >> >> in >> >> >>>>>>>>> the request? >> >> >>>>>>>>> >> >> >>>>>>>>> Yours, Joel >> >> >>>>>>>>> >> >> >>>>>>>>> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: >> >> >>>>>>>>>> Hi, >> >> >>>>>>>>>> >> >> >>>>>>>>>> There is a similarity here with device ID. In context of >> >> PAWS >> >> >>>>>>>>>> we are not concerned with why a device ID is required by >> a >> >> >>>>>>>>>> regulator, we accept it is a requirement from a >> >> >>>>>>>>>> regulator >> >> and >> >> >>>>>>>>>> include it to the protocol. Ofcom identifies in 3.18& >> 3.19 >> >> >>>>>>>>>> that channel usage information is required and thus we >> need >> >> >>>>>>>>>> to include this information. Since the master must >> provide >> >> >>>>>>>>>> this information prior to transmitting, PAWS will not >> >> >>>>>>>>>> function in the UK without this information and thus I >> >> >>>>>>>>>> believe channel usage information is integral to the >> channel >> >> >>>>>>>>>> request& response messaging. >> >> >>>>>>>>>> >> >> >>>>>>>>>> Kind Regards, Scott >> >> >>>>>>>>>> >> >> >>>>>>>>>> >> >> >>>>>>>>>> On 3/6/12 10:30 AM, "ext Joel M. >> >> >>>>>>>>>> Halpern" wrote: >> >> >>>>>>>>>> >> >> >>>>>>>>>>> I would draw a distinction. Ofcom regulations about >> >> >>>>>>>>>>> whitespace requests are very much relevant. Ofcom >> >> >>>>>>>>>>> regulations about notification of dynamic behavior >> (which >> >> >>>>>>>>>>> spectrum is being used) are not in scope as I >> >> >>>>>>>>>>> understand the earlier discussions, particularly the >> >> >>>>>>>>>>> chartering discussions. >> >> >>>>>>>>>>> >> >> >>>>>>>>>>> Yours, Joel >> >> >>>>>>>>>>> >> >> >>>>>>>>>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: >> >> >>>>>>>>>>>> >> >> >>>>>>>>>>>> The ofcom requirements are very much relevant to the >> >> >>>>>>>>>>>> scope of the PAWS WG. The only other regulatory >> >> >>>>>>>>>>>> requirements that we have today is the FCC. Ofcom >> >> >>>>>>>>>>>> requirements are a good addition to the set. >> >> >>>>>>>>>>>> >> >> >>>>>>>>>>>> -Raj >> >> >>>>>>>>>>>> >> >> >>>>>>>>>>>> On 3/6/12 10:03 AM, "ext >> >> >>>>>>>>>>>> andy.sago@bt.com" wrote: >> >> >>>>>>>>>>>> >> >> >>>>>>>>>>>>> Hi Joel >> >> >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> There's no language I can find in the charter that >> >> >>>>>>>>>>>>> explicitly puts this out of scope. On the other hand, >> >> >>>>>>>>>>>>> the charter says that the group will "consider input >> >> >>>>>>>>>>>>> from regulatory entities", and this is one of the >> >> >>>>>>>>>>>>> requirements from Ofcom that they have just >published. >> >> >>>>>>>>>>>>> The protocol will be worthless for the UK if it omits >> >> >>>>>>>>>>>>> some requirements. >> >> >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> Regards >> >> >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> Andy >> >> >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> -----Original Message----- From: Joel M. Halpern >> >> >>>>>>>>>>>>> [mailto:jmh@joelhalpern.com] Sent: 06 March 2012 >> >> >>>>>>>>>>>>> 15:53 >> >> >>>>>>>>>>>>> To: Sago,AJ,Andy,COD R Cc: paws@ietf.org; >> >> >>>>>>>>>>>>> Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for >> >> >>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: >> channel >> >> >>>>>>>>>>>>> reporting >> >> >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> As I understand, the information you are asking for >> >> >>>>>>>>>>>>> is explicitly out of scope for the working group. >> >> >>>>>>>>>>>>> Yours, Joel >> >> >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >> >> >>>>>>>>>>>>>> All >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Comparing the draft with the Ofcom requirements at >> >> >>>>>>>>>>>>>> http://www.cept.org/Documents/se- >> >> >>>>> 43/4161/SE43(12)Info03_Draft-UK-r >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> >>>>> egul >> >> >>>>>>>>>>>>>> atory-requirements-for-white-space-devices-in-the- >> UHF- >> >> TV- >> >> >>>>> band, >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> >>>>> I believe the WG draft is deficient in the area of reporting >> >> >>>>>>>>>>>>>> frequencies and powers actually used by masters and >> >> >>>>>>>>>>>>>> slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom >> >> >>>>>>>>>>>>>> intends to collect this data to assesses the impact >> >> >>>>>>>>>>>>>> of aggregate interference into other services. It >> >> >>>>>>>>>>>>>> would also provide usage information (frequency in >> >> >>>>>>>>>>>>>> use) that would inform the operation of a kill >> >> >>>>>>>>>>>>>> switch capability. I suggest this deficiency can be >> >> >>>>>>>>>>>>>> remedied with the following changes: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> New P requirements (probably best placed following >> >> >>>>>>>>>>>>>> P.12): >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> P.12bis: The protocol MUST support a channel usage >> >> >>>>>>>>>>>>>> message from the slave device to the master device. >> >> >>>>>>>>>>>>>> The channel usage message MUST include parameters as >> >> >>>>>>>>>>>>>> required by local regulatory requirement. These >> >> >>>>>>>>>>>>>> parameters MAY include device ID, manufacturer's >> >> >>>>>>>>>>>>>> serial number, channel usage and power level >> >> >>>>>>>>>>>>>> information. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> P.12ter: The protocol MUST support a channel usage >> >> >>>>>>>>>>>>>> message from the master device to the database. The >> >> >>>>>>>>>>>>>> channel usage message MUST include parameters as >> >> >>>>>>>>>>>>>> required by local regulatory requirement for the >> >> >>>>>>>>>>>>>> master and its associated slaves. These parameters >> >> >>>>>>>>>>>>>> MAY include device ID, manufacturer's serial number, >> >> >>>>>>>>>>>>>> channel usage and power level information. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> P.12qua: The protocol MUST support a channel usage >> >> >>>>>>>>>>>>>> message acknowledgement. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> New O requirements (probably best placed following >> >> >>>>>>>>>>>>>> O13): >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> O.13bis: According to local regulatory policy, >> >> >>>>>>>>>>>>>> after connecting to a master device's radio network >> >> >>>>>>>>>>>>>> a slave device MAY inform the master device of the >> >> >>>>>>>>>>>>>> actual channel usage. The slave MUST include >> >> >>>>>>>>>>>>>> parameters required by local regulatory policy, e.g. >> >> >>>>>>>>>>>>>> device ID, manufacturer's serial number, channel >> >> >>>>>>>>>>>>>> usage and power level information. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> O.13ter: According to local regulatory policy, a >> >> >>>>>>>>>>>>>> master device MAY inform the database of the actual >> >> >>>>>>>>>>>>>> channel usage of the master and its slaves. The >> >> >>>>>>>>>>>>>> master MUST include parameters required by local >> >> >>>>>>>>>>>>>> regulatory policy, e.g. device ID, manufacturer's >> >> >>>>>>>>>>>>>> serial number, channel usage and power level >> >> >>>>>>>>>>>>>> information of the master and its slaves. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> New steps could be introduced into one or more use >> >> >>>>>>>>>>>>>> cases to cover these Ofcom requirements, e.g. new >> >> >>>>>>>>>>>>>> steps 6bis and 9bis in the hotspot use case at >> >> >>>>>>>>>>>>>> 4.2.1: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 6bis. Prior to initiating transmission, if required >> >> >>>>>>>>>>>>>> by local regulation, the master/AP informs the >> >> >>>>>>>>>>>>>> database of the channel and power level it has >> >> >>>>>>>>>>>>>> chosen. This is repeated for each slave that >> >> >>>>>>>>>>>>>> associated with the master. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 9bis. Prior to initiating transmission, if required >> >> >>>>>>>>>>>>>> by local regulation, the slave informs the master/AP >> >> >>>>>>>>>>>>>> of the channel and power level it has chosen, and >> >> >>>>>>>>>>>>>> the master/AP relays this information to the >database. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> - end of new text - >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> For information, for those not accessing the url in >> >> >>>>>>>>>>>>>> the first paragraph of this email, the full Ofcom >> >> >>>>>>>>>>>>>> requirements leading to this new PAWS text are as >> >> >>>>>>>>>>>>>> follows: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 3.18 After receiving instructions from a WSDB in >> >> >>>>>>>>>>>>>> relation to the maximum permitted EIRPs over the DTT >> >> >>>>>>>>>>>>>> channels, and prior to initiating transmissions >> >> >>>>>>>>>>>>>> within the UHF TV band, a master WSD must >> >> >>>>>>>>>>>>>> communicate to the WSDB the following information: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 3.18.1 The lower and upper frequency boundaries^13 >> >> >>>>>>>>>>>>>> of the in-block emissions of the master WSD, and >> >> >>>>>>>>>>>>>> those of the in-block emissions of its associated >> >> >>>>>>>>>>>>>> slaves. A lower frequency will be specified as (470 >> >> >>>>>>>>>>>>>> + 8k + >> >> >>>>>>>>>>>>>> 0.2n) MHz, with the corresponding upper frequency >> >> >>>>>>>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3?4 k >3?4 >> >> >>>>>>>>>>>>>> 39, 0 3?4 n 3?4 39, 1 3?4 m 3?4 40, and n< m. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 3.18.2 The maximum in-block EIRP spectral densities >> >> >>>>>>>>>>>>>> (in dBm/(0.2 MHz)) that the master WSD, and its >> >> >>>>>>>>>>>>>> associated slaves, actually radiate between each >> >> >>>>>>>>>>>>>> reported lower frequency boundary and its >> >> >>>>>>>>>>>>>> corresponding upper frequency boundary. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Footnote 13 states: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> The use of upper and lower frequency boundaries >> >> >>>>>>>>>>>>>> (defined over a 200 kHz raster) allows a WSDB to >> >> >>>>>>>>>>>>>> collect more granular information with regards to >> >> >>>>>>>>>>>>>> the usage of the frequency resource by narrowband >> >> >>>>>>>>>>>>>> WSD technologies. The upper and lower frequencies of >> >> >>>>>>>>>>>>>> a boundary pair do not straddle a DTT channel >boundary. >> >> >>>>>>>>>>>>>> Note that a WSD may transmit over multiple, >> >> >>>>>>>>>>>>>> non-contiguous, whole DTT channels or fractions of >> >> >>>>>>>>>>>>>> DTT channels. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 3.19 A master WSD must be able to receive the >> >> >>>>>>>>>>>>>> following information^14 from a WSDB: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in the >> >> >>>>>>>>>>>>>> context of 3.18, that the reported information on >> >> >>>>>>>>>>>>>> the DTT channels and EIRP spectral densities >> >> >>>>>>>>>>>>>> actually used by the master and slave WSDs were >> >> >>>>>>>>>>>>>> received successfully by the WSDB^18 ]. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Footnote 14 states: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 14 While the communication of some of this >> >> >>>>>>>>>>>>>> information from a WSDB to a master WSD is optional, >> >> >>>>>>>>>>>>>> master WSDs must be able to receive and interpret >> >> >>>>>>>>>>>>>> these. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Footnote 18 states: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 18 This forms part of a handshake protocol and may >> >> >>>>>>>>>>>>>> be an area where industry could harmonise without >> >> >>>>>>>>>>>>>> the need for an explicit requirement in the >regulations. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Regards >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Andy >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> *From:*paws-bounces@ietf.org >> >> >>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] *On Behalf Of >> >> >>>>>>>>>>>>>> *Gabor.Bajko@nokia.com *Sent:* 05 March 2012 19:46 >> >> >>>>>>>>>>>>>> *To:* paws@ietf.org *Subject:* [paws] WGLC for >> >> >>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> The authors of the use cases and requirements draft >> >> >>>>>>>>>>>>>> have just posted a new version of the draft and >> >> >>>>>>>>>>>>>> indicated that there are no unresolved >> >> >>>>>>>>>>>>>> comments/issues they are aware of. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Therefore, I'd like to initiate a WG Last Call for >> >> >>>>>>>>>>>>>> comments on >> >> >>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-paws- >> >> problem- >> >> >>>>> stmt-u >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> >>>>> seca >> >> >>>>>>>>>>>>>> ses-rqmts-03.txt >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Please review the draft and send your comments to >> >> >>>>>>>>>>>>>> the list by March 20th, 2012. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> If you review the draft and have no comments, send a >> >> >>>>>>>>>>>>>> note to the list that the draft is good as it is, we >> >> >>>>>>>>>>>>>> need these notes as much as we need the actual >> >> >>>>>>>>>>>>>> comments. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Thanks, Gabor >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> > >> >> > _______________________________________________ >> >> > paws mailing list >> >> > paws@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/paws >> >> > >> >> _______________________________________________ >> >> paws mailing list >> >> paws@ietf.org >> >> https://www.ietf.org/mailman/listinfo/paws >> >> >> >> _______________________________________________ >> >> paws mailing list >> >> paws@ietf.org >> >> https://www.ietf.org/mailman/listinfo/paws >> >_______________________________________________ >> >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 > >________________________________ > >************************************************************************ >****************************************** >For more information visit www.ofcom.org.uk > >This email (and any attachments) is confidential and intended for the >use of the addressee only. > >If you have received this email in error please notify the originator of >the message and delete it from your system. > >This email has been scanned for viruses. However, you open any >attachments at your own risk. > >Any views expressed in this message are those of the individual sender >and do not represent the views or opinions of Ofcom unless expressly >stated otherwise. >************************************************************************ >****************************************** >_______________________________________________ >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 jstine@mitre.org Fri Mar 9 05:14:09 2012 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 DFB5221F85D8 for ; Fri, 9 Mar 2012 05:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.338 X-Spam-Level: X-Spam-Status: No, score=-6.338 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 PRcIBt3Z4m3J for ; Fri, 9 Mar 2012 05:14:09 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6A34421F85B6 for ; Fri, 9 Mar 2012 05:14:09 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 50C2621B0281 for ; Fri, 9 Mar 2012 08:14:08 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 3B6A821B026D for ; Fri, 9 Mar 2012 08:14:08 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.106]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.01.0339.001; Fri, 9 Mar 2012 08:14:08 -0500 From: "Stine, John A." To: "paws@ietf.org" Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting Thread-Index: AQHM/U+Hg2IR71vGEUu+ZfwSfHzAyZZh63NQ Date: Fri, 9 Mar 2012 13:14:07 +0000 Message-ID: <2782C93FD2244441893673F3F91281921302D1@IMCMBX01.MITRE.ORG> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 13:14:10 -0000 I just read this thread and had to jump in and emphasize the motivation for= supporting the modularity of the data structures. There will be as many d= ata and messaging requirements as there are regulatory domains, device stan= dards, and maybe even database administrators. If PAWS were to focus on pr= oviding a messaging capability rather than specifying which messages must b= e used in a transaction it will be much easier. When a device contacts a d= atabase it would learn or confirm which regulatory domain it is in, what me= ssaging is required, and what data requirements are necessary. The basics = of a device having to contact a DB and its use being contingent on a list f= rom the DB will be there but the specifics about the negotiation to get tha= t approval and to keep it can be different. Seeking this sort of loose cou= pling for PAWS will make this protocol much more versatile over time. John From JuanCarlos.Zuniga@InterDigital.com Fri Mar 9 06:41:07 2012 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 0061321F8629 for ; Fri, 9 Mar 2012 06:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[AWL=-0.530, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, 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 oxae0CSaCwoZ for ; Fri, 9 Mar 2012 06:41:04 -0800 (PST) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1947421F861D for ; Fri, 9 Mar 2012 06:41:04 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 09:41:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Mar 2012 09:41:01 -0500 Message-ID: In-Reply-To: <2D1F0F0C-F3B9-43ED-8195-0962DF863AC8@neustar.biz> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [paws] WGLC fordraft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting Thread-Index: Acz+ACskO8SUp+IDQpSvKz7avSwIagAAmdqA References: , <7BAC95F5A7E67643AAFB2C31BEE662D0157A034B37@SC-VEXCH2.marvell.com> <2D1F0F0C-F3B9-43ED-8195-0962DF863AC8@neustar.biz> From: "Zuniga, Juan Carlos" To: "Rosen, Brian" X-OriginalArrivalTime: 09 Mar 2012 14:41:03.0240 (UTC) FILETIME=[A704C880:01CCFE02] Cc: paws@ietf.org Subject: Re: [paws] WGLC fordraft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 14:41:07 -0000 Brian, The charter does state the following: "In order to ensure that it takes into account a broad range of possible use cases and requirements, the group should also reach out to other potential "customers" for a white space database access method and consider input from regulatory entities that are involved in the specification of the rules for secondary use of spectrum in specific radio bands." Not taking into account these Ofcom and Industry Canada inputs, especially at this stage when solutions are not being discussed yet, would be a mistake. Besides, I don't see any statement in the charter that the protocol should be a "two-way handshake" query/response only. This belongs to the solution part of the work, not to the scope or to the requirements, which is what we are discussing now. We are in good time to correct the charter, if need be, and produce a meaningful protocol to the industry.=20 JC > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: Friday, March 09, 2012 9:23 AM > To: Paul Lambert > Cc: Das, Subir; Siew Yoon Tan; Zuniga, Juan Carlos; > Basavaraj.Patil@nokia.com; gerald.chouinard@sympatico.ca; > jmh@joelhalpern.com; scott.probasco@nokia.com; paws@ietf.org; > presnick@qualcomm.com; Reza Karimi; johnny.dixon@bt.com; > chris.cheeseman@bt.com > Subject: Re: [paws] WGLC fordraft-ietf-paws-problem-stmt-usecases- > rqmts-03:channel reporting >=20 > > We are limited by our charter. As you can see by the discussion, even > a minor extension to report channels used in an ack is controversial. > Adding a whole new transaction would clearly, in my opinion, be beyond > our charter. Charter limitations are good, if frustrating. If we feel > we made an error in the original charter, we can ask that it be > changed, but it's best to try to work within the charter, get that > done, and then expand the scope of the work. >=20 > Right at the moment, we're trying to accommodate the regulatory > requirements of the UK within our initial charter. As such, I would > like to see the simplest way to do that and stay within the charter. > Any further work could be considered later when we accomplish our > initial goals. >=20 > Brian >=20 > On Mar 8, 2012, at 9:15 PM, Paul Lambert wrote: >=20 > > > > > > > > > > > >> I have a question here. Is it really an acknowledgement or we would > like > >> to see a kind of notification message that includes channel, and > other > >> parameters? > > > > What if it's multiple channels? What happens if the device adapts > and changes between modulation technique or bandwidth? Does every > change over the air need to be indicated to the GDB? > > > > This Channel acknowledgement does not seem useful and would limit > real world behaviors (like channel and modulation adaptation). > > > > If viewed as a potential regulatory requirement - does this imply we > need to parameterize the protocol to have different behaviors in > different regions? > > > > Paul > > > > > > > >> > >> Regards, > >> _Subir > >> > >> -----Original Message----- > >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf > Of > >> Siew Yoon Tan > >> Sent: Thursday, March 08, 2012 4:06 PM > >> To: Zuniga, Juan Carlos; Basavaraj.Patil@nokia.com; > >> gerald.chouinard@sympatico.ca; jmh@joelhalpern.com; > >> scott.probasco@nokia.com > >> Cc: paws@ietf.org; presnick@qualcomm.com; Reza Karimi; > >> johnny.dixon@bt.com; chris.cheeseman@bt.com > >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- > >> rqmts-03:channel reporting > >> > >> Dear All, > >> > >> Regarding Ofcom's requirement to have a return channel as part of > the > >> protocol between the WSD and WSDB, I would like to confirm to > following > >> sequence of messaging > >> > >> Channel request > >> Channel response > >> Channel acknowledgement > >> > >> which was raised in an earlier email to this list. > >> > >> Our view is that it would be beneficial to define the protocol > between > >> WSD and WSDB that supports this requirement even though how the > >> information could be used is still subject to discussion in the UK. > >> > >> > >> Best regards, > >> > >> Siew Yoon > >> > >> > >> ________________________________________ > >> From: paws-bounces@ietf.org [paws-bounces@ietf.org] on behalf of > Zuniga, > >> Juan Carlos [JuanCarlos.Zuniga@InterDigital.com] > >> Sent: 08 March 2012 20:41 > >> To: Basavaraj.Patil@nokia.com; gerald.chouinard@sympatico.ca; > >> jmh@joelhalpern.com; scott.probasco@nokia.com > >> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; > >> chris.cheeseman@bt.com > >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- > usecases- > >> rqmts-03:channel reporting > >> > >> Hi Raj, > >> > >> I was reusing the language used from Gerald (which I know is > familiar to > >> people working on IEEE 802 WS groups): > >> > >>>> [GC] You got it. This would be useless for spectrum regulators. > One > >>>> should realize that, from the spectrum regulator's point of view, > the > >>>> second and third messages could be iterated upon to optimize the > >>>> spectrum use. > >>>> Knowing > >>>> what channels the systems in an area are using, the spectrum > >>>> regulators and/or other entities such as those taking care of > >>>> coexistence could use the database in near-real-time to iterate on > >>>> the two last messages to reduce the range of channels that some > >>>> systems may use once they know precisely what channels are being > used > >>>> in the area. The PAWS protocol would carry the information back > and > >>>> forth but would not be involved in such spectrum use optimization. > >> > >> Having said that, I have no issue sticking to the WSDB terminology. > I > >> like keeping things simple :) > >> > >> JC > >> > >>> -----Original Message----- > >>> From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] > >>> Sent: Thursday, March 08, 2012 3:33 PM > >>> To: Zuniga, Juan Carlos; gerald.chouinard@sympatico.ca; > >>> jmh@joelhalpern.com; scott.probasco@nokia.com > >>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; > >>> chris.cheeseman@bt.com > >>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- > >>> rqmts-03:channel reporting > >>> > >>> > >>> Hi JC, > >>> > >>> Where/why did the coexistence manager come into the picture? Your > >>> comment about "communicating back to the WSDB/coexistence manager" > may > >>> result in further misunderstanding. If we simply stick to to WSDB I > >>> think we are okay. > >>> > >>> -Raj > >>> > >>> On 3/8/12 2:25 PM, "ext Zuniga, Juan Carlos" > >>> wrote: > >>> > >>>> So, from Gerald and Andy's comments, it seems like from the point > of > >>> view > >>>> of (at least) two regulatory entities it is important for the > >>>> protocol > >>> to > >>>> allow communicating back to the WSDB/coexistence manager the > actual > >>>> channel usage after the first query is made. > >>>> > >>>> This is to me a very clear requirement. > >>>> > >>>> The actual messages/IEs that would carry this information should > be > >>>> discussed as part of the solution document, and not the > requirements. > >>>> > >>>> JC > >>>> > >>>>> -----Original Message----- > >>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On > >>>>> Behalf > >>> Of > >>>>> Gerald Chouinard > >>>>> Sent: Thursday, March 08, 2012 1:59 PM > >>>>> To: 'Joel M. Halpern'; scott.probasco@nokia.com > >>>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; > >>>>> chris.cheeseman@bt.com > >>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- > usecases- > >>>>> rqmts-03:channel reporting > >>>>> > >>>>> Joel, Scott, > >>>>> > >>>>> Interesting discussion! See my comments in line below. > >>>>> > >>>>> Gerald > >>>>> > >>>>> -----Original Message----- > >>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On > >>>>> Behalf > >>> Of > >>>>> Joel > >>>>> M. Halpern > >>>>> Sent: Thursday, 08 March, 2012 13:17 > >>>>> To: scott.probasco@nokia.com > >>>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; > >>>>> chris.cheeseman@bt.com > >>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- > usecases- > >>>>> rqmts-03: > >>>>> channel reporting > >>>>> > >>>>> So why won't the device simply say "I will use all of this?" > >>>>> [GC] This would defeat the purpose of the acknowledgement > message. > >>>>> After all, that way it needs to do less work with the database. > >>>>> And > >>> it > >>>>> can change frequencies when it wants. > >>>>> Given that the stated goal of the Ofcom requriement was to be > able > >>> to > >>>>> analyze interference effects, it seems that this will not > actually > >>> lead > >>>>> to them getting what they want, even if it does comply with the > >>>>> regulations. > >>>>> [GC] You got it. This would be useless for spectrum regulators. > >>>>> One should realize that, from the spectrum regulator's point of > >>>>> view, the > >>> second > >>>>> and > >>>>> third messages could be iterated upon to optimize the spectrum > use. > >>>>> Knowing > >>>>> what channels the systems in an area are using, the spectrum > >>> regulators > >>>>> and/or other entities such as those taking care of coexistence > >>>>> could use the database in near-real-time to iterate on the two > last > >>>>> messages to reduce the range of channels that some systems may > use > >>>>> once they know precisely what channels are being used in the > area. > >>>>> The PAWS protocol would carry > >>> the > >>>>> information back and forth but would not be involved in such > >>> spectrum > >>>>> use > >>>>> optimization. > >>>>> > >>>>> Yours, > >>>>> joel > >>>>> > >>>>> On 3/8/2012 1:09 PM, scott.probasco@nokia.com wrote: > >>>>>> Hi Peter, > >>>>>> > >>>>>> Answers below. > >>>>>> > >>>>>> Kind Regards, > >>>>>> Scott > >>>>>> > >>>>>> On 3/8/12 11:39 AM, "ext Peter Saint-Andre" > >>>>> wrote: > >>>>>> > >>>>>>> Hi Scott, I have two clarifying questions: > >>>>>>> > >>>>>>> 1. Does the device know, when it receives the channel response, > >>>>> which > >>>>>>> channel it will actually use? > >>>>>> Scott->This is all new and I am not aware of any existing > >>>>> implementations. > >>>>>> I would argue that the device must decide what channel(s) it > will > >>> use > >>>>> when > >>>>>> it receives the channel response. > >>>>> [GC] Agree with Scott but this is only a portion of the > >>> considerations. > >>>>> If a > >>>>> device was to operate on its own, this would be true but a > >>>>> communication device usually implies at least 2 devices to > >>>>> communicate. Hence, the choice of the channel to be used will > need > >>>>> to be negotiated between the two devices before a choice can be > >>>>> made. The chosen channel will belong to the > >>> set > >>>>> of > >>>>> available channels that is common to both devices. Remember that > >>> some > >>>>> channels may be available at one device and not at the other > >>>>> because > >>> of > >>>>> their geolocation or other reason. Extending this concept to a > star > >>>>> network topology, the channel that will be selected by this > network > >>>>> will > >>> have > >>>>> to > >>>>> belong to the set of channels that are available to all devices. > >>> Each > >>>>> device > >>>>> will not be able to decide by itself which channel it wants to > use. > >>>>> > >>>>> This is why in such a star topology, it makes sense that the > slave > >>>>> devices to a base station or access point be represented by the > >>>>> base station acting as the master on their behalf to query the > >>>>> database and receive the list of available channels (and/or > maximum > >>>>> EIRP per channel). It is then the responsibility of the base > >>>>> station to identify the set of available channels that is common > >>>>> for itself and all its slaves to decide on the > >>> channel > >>>>> that > >>>>> the network will use. As you can see, in this case, there is no > >>>>> need for each slave to receive its list of available channels. On > >>>>> its own, it would not know what to do with it. The only thing > that > >>>>> needs to be sent > >>> from > >>>>> the > >>>>> master device to its slaves is the resulting operating channel. > >>>>> > >>>>> I a more sophisticated operation, the master device may add one > or > >>>>> a few backup channels extracted from the common set of available > >>>>> channel > >>> to > >>>>> the > >>>>> message going to its slave so that if a change in channel > >>> availability > >>>>> occurs, an instantaneous switch to the next backup channel can be > >>> made > >>>>> without any further signaling, thus providing for a channel > switch > >>> that > >>>>> is > >>>>> transparent to the user. It is the scheme that has been included > in > >>> the > >>>>> IEEE > >>>>> 802.22-2011 Standard. This is why I don't believe that PAWS > should > >>> get > >>>>> involved in defining this signaling between the base station and > >>>>> its slaves devices. > >>>>>>> > >>>>>>> 2. If the device then uses another channel or a different > >>> channel, > >>>>> does > >>>>>>> it need to report that change to the database? > >>>>>> Scott->My interpretation of section 3.18 is that the device can > >>> only > >>>>>> transmit within the upper& lower frequencies returned in the > >>>>>> acknowledgment. I do not (quickly) find any reference in the > >>>>> requirements > >>>>>> to changing channels. Thus operationally it could be that the > >>> channel > >>>>>> request process must be repeated before the device can use a > >>>>> different > >>>>>> channel (frequencies). > >>>>> [GC] If the process involves 2 messages, then, the device and its > >>>>> associated devices could change channels at will as long as all > >>>>> these channels belong to the set of available channel. However, > if > >>>>> the third message is added, it would make sense that the master > >>>>> device reports to the database any channel change that would > occur > >>>>> to the database, otherwise, the status of > >>> the > >>>>> spectrum occupation would be wrong at any moment and would be > >>> useless > >>>>> for > >>>>> the purpose of any spectrum usage optimization such as > coexistence. > >>>>>>> > >>>>>>> Thanks! > >>>>>>> > >>>>>>> Peter > >>>>>>> > >>>>>>> On 3/8/12 10:17 AM, scott.probasco@nokia.com wrote: > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> The point from Brian is very relevant: > >>>>>>>> > >>>>>>>> Channel request > >>>>>>>> Channel response > >>>>>>>> Channel acknowledgement > >>>>>>>> > >>>>>>>> What Ofcom does with the information in the acknowledgement > >>>>>>>> does > >>>>> not > >>>>>>>> matter. As the regulator in UK, they write rules that must be > >>>>> followed > >>>>>>>> in > >>>>>>>> order to operate a whitespace radio in the UK. I believe the > >>> scope > >>>>> of > >>>>>>>> the > >>>>>>>> WG must be focused on a working solution. If this is simple > >>> channel > >>>>>>>> request& response in one regulator's domain, PAWS can support > >>>>> this. If > >>>>>>>> it > >>>>>>>> means a channel request, response and acknowledgement in > >>>>>>>> another regulator's domain, PAWS can support this. As a > >>>>>>>> participating > >>>>> member of > >>>>>>>> the work group, I believe the scope should be basic working > >>>>> solution, > >>>>>>>> not > >>>>>>>> limited to a specific number of messages. > >>>>>>>> > >>>>>>>> Kind Regards, > >>>>>>>> Scott > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On 3/8/12 11:11 AM, "ext Zuniga, Juan Carlos" > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> Peter, Nancy, > >>>>>>>>> > >>>>>>>>> I agree should design a protocol with the best of our current > >>>>>>>>> knowledge, and that should be accounting for all the known > >>>>>>>>> regulations at > >>>>> present > >>>>>>>>> time. We should not limit the scope with the purpose of > >>> designing > >>>>> a > >>>>>>>>> protocol 'faster'. Our goal is not only to design a WSDB > >>> protocol. > >>>>> Our > >>>>>>>>> goal is to design a WSDB protocol that is USEFUL to the > >>> community. > >>>>>>>>> > >>>>>>>>> The charter does state that > >>>>>>>>> > >>>>>>>>> "...the group should also reach out to other potential > >>>>>>>>> "customers" for a white space database access method and > >>> consider > >>>>> input > >>>>>>>>> from regulatory entities that are involved in the > >>>>>>>>> specification > >>> of > >>>>> the > >>>>>>>>> rules for secondary use of spectrum in specific radio bands. > " > >>>>>>>>> > >>>>>>>>> I think that is exactly what we are doing now. > >>>>>>>>> > >>>>>>>>> Regarding whether the types of requirements belong to #1 or > >>>>>>>>> #2, > >>> I > >>>>>>>>> believe > >>>>>>>>> it is more of #1 type, as the information to be exchanged > >>>>>>>>> would > >>> be > >>>>>>>>> known > >>>>>>>>> after the initial query/response. > >>>>>>>>> > >>>>>>>>> If we know it today, I see no reason why we should not work > on > >>> it > >>>>> in > >>>>>>>>> the > >>>>>>>>> first phase of the work. > >>>>>>>>> > >>>>>>>>> Regards, > >>>>>>>>> > >>>>>>>>> Juan Carlos > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] > On > >>>>> Behalf > >>>>>>>>>> Of > >>>>>>>>>> Peter Saint-Andre > >>>>>>>>>> Sent: Thursday, March 08, 2012 11:59 AM > >>>>>>>>>> To: Nancy Bravin > >>>>>>>>>> Cc: paws@ietf.org; johnny.dixon@bt.com; > >>> chris.cheeseman@bt.com; > >>>>> Pete > >>>>>>>>>> Resnick > >>>>>>>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- > >>>>> usecases- > >>>>>>>>>> rqmts-03: channel reporting > >>>>>>>>>> > >>>>>>>>>> Hi Nancy, > >>>>>>>>>> > >>>>>>>>>> You are absolutely right that different locales will have > >>>>> different > >>>>>>>>>> rules and requirements. We need to understand those, and > work > >>> to > >>>>>>>>>> address > >>>>>>>>>> them if possible (although we don't necessarily need to > >>> address > >>>>> them > >>>>>>>>>> all > >>>>>>>>>> at the same time). I see several kinds of requirements: > >>>>>>>>>> > >>>>>>>>>> 1. Some requirements might lead to features beyond the > >>>>> query/response > >>>>>>>>>> protocol we've envisioned so far. One example might be real- > >>> time > >>>>>>>>>> reporting about the channels that a device is actually > using. > >>> In > >>>>> my > >>>>>>>>>> opinion, it would be best to handle those in the next phase > >>>>>>>>>> of > >>>>> work, > >>>>>>>>>> because as far as I can see they are outside the scope of > our > >>>>> charter. > >>>>>>>>>> > >>>>>>>>>> 2. Some requirements might be handled through by defining > >>>>> additional > >>>>>>>>>> fields that can be included in the query or response. We > >>>>> definitely > >>>>>>>>>> planned for that when working on the charter with the IESG: > >>>>>>>>>> > >>>>>>>>>> In addition, the particular > >>>>>>>>>> data exchanged between a device and a database might > >>>>>>>>>> depend > >>> on > >>>>> the > >>>>>>>>>> ranges of radio spectrum that are to be used, the > >>> requirements > >>>>> of > >>>>>>>>>> the > >>>>>>>>>> database operators and their governing regulations, and > >>> other > >>>>>>>>>> factors. > >>>>>>>>>> Therefore, the database access method and the > >>> query/response > >>>>> data > >>>>>>>>>> formats that are exchanged using that method need to be > >>>>> designed > >>>>> for > >>>>>>>>>> extensibility rather than being tied to any specific > >>> spectrum, > >>>>>>>>>> country, or phy/mac/air interface. > >>>>>>>>>> > >>>>>>>>>> It's unclear to me right now if the Ofcom requirement fits > >>> into > >>>>> #1 or > >>>>>>>>>> #2, which is why we're having this discussion. :) > >>>>>>>>>> > >>>>>>>>>> Peter > >>>>>>>>>> > >>>>>>>>>> On 3/7/12 8:17 PM, Nancy Bravin wrote: > >>>>>>>>>>> Peter and all, > >>>>>>>>>>> > >>>>>>>>>>> I agree that it is important to revisit now, so that in the > >>>>> future, > >>>>>>>>>>> it will be easy to align things in their proper place. > Every > >>>>> country > >>>>>>>>>>> may have different regulations, spectrum, policy and what > >>>>>>>>>>> responsibility is in the domain of the system, and what > >>>>>>>>>>> comes > >>>>> under > >>>>>>>>>>> the PAWS charter is important. Maybe some separation might > >>> be > >>>>>>>>>>> possible, and dividing and clarifying issues now will help > >>>>>>>>>>> in > >>>>> the > >>>>>>>>>>> future. Certainly it seems that the FCC may change some > >>> rules, > >>>>> and > >>>>>>>>>>> we know that Ofcom is not yet finished with their > >>> regulations. > >>>>> Canada > >>>>>>>>>>> has their own, and other countries are working on this as > >>> well. > >>>>> Just > >>>>>>>>>>> a thought...Sharing is a realistic goal...as is off > >>> loading... > >>>>> Or you > >>>>>>>>>>> slim line and every 6 months decide what to incorporate in > >>> the > >>>>>>>>>>> protocol based on new information, new ideas, new > innovation > >>> new > >>>>>>>>>>> regulations and maybe spend more time than you could if > >>>>> addressed > >>>>>>>>>>> now. > >>>>>>>>>>> > >>>>>>>>>>> That way you leave the door open and outside of referencing > >>> what > >>>>> is > >>>>>>>>>>> known today, by referencing regulations i.e. Ofcom, FCC, > >>>>> Industry > >>>>>>>>>>> Canada etc as of XX-XX-XXXX date. Out of scope not > something > >>> we > >>>>> know > >>>>>>>>>>> enough about to say at this point, In my opinion. > >>>>>>>>>>> > >>>>>>>>>>> My 2 cents.. > >>>>>>>>>>> > >>>>>>>>>>> Sincerely, Nancy > >>>>>>>>>>> > >>>>>>>>>>> On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote: > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> As your responsible Area Director (until March 28, when > >>>>>>>>>>>> Pete Resnick will take over from me), I have reviewed this > >>> thread. > >>>>>>>>>>>> > >>>>>>>>>>>> In my opinion (I am happy to be proven wrong), this new > >>>>> requirement > >>>>>>>>>>>> goes beyond what the charter defined as the scope of this > >>>>> working > >>>>>>>>>>>> group, which was to enable a device to discover the white > >>> space > >>>>>>>>>>>> available to it in its current location. Reporting usage > >>> back > >>>>> to > >>>>>>>>>>>> the database is simply not mentioned in the charter. > >>>>>>>>>>>> > >>>>>>>>>>>> Earlier in this thread, Andy Sago wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> There's no language I can find in the charter that > >>> explicitly > >>>>> puts > >>>>>>>>>>>> this out of scope. > >>>>>>>>>>>> > >>>>>>>>>>>> An IETF charter defines what the working group shall work > >>> on. > >>>>> Many > >>>>>>>>>>>> interesting features could be developed here. However, it > >>>>>>>>>>>> is > >>>>> not > >>>>>>>>>>>> the job of the charter to mention explicitly that each of > >>> those > >>>>>>>>>>>> interesting features is out of scope. > >>>>>>>>>>>> > >>>>>>>>>>>> The charter does say: > >>>>>>>>>>>> > >>>>>>>>>>>> Once the device learns of the available white space (e.g., > >>> in a > >>>>> TV > >>>>>>>>>>>> white space implementation, the list of available channels > >>> at > >>>>> that > >>>>>>>>>>>> location), it can then select one of the bands from the > >>>>>>>>>>>> list > >>>>> and > >>>>>>>>>>>> begin to transmit and receive on the selected band. > >>>>>>>>>>>> > >>>>>>>>>>>> This text might have assumed that no further communication > >>> or > >>>>>>>>>>>> authorization was required in order to select one of the > >>> bands > >>>>> from > >>>>>>>>>>>> the list and then transmit/receive. Perhaps that > assumption > >>> was > >>>>>>>>>>>> mistaken. If so, it would be good to have a discussion > >>>>>>>>>>>> about > >>>>> that, > >>>>>>>>>>>> so we can determine if we need to revisit the assumptions > >>>>>>>>>>>> we > >>>>> made > >>>>>>>>>>>> early on. If in fact we made some faulty or limited > >>>>> assumptions, > >>>>>>>>>>>> then let's get that out in the open. > >>>>>>>>>>>> > >>>>>>>>>>>> Peter > >>>>>>>>>>>> > >>>>>>>>>>>> On 3/7/12 9:40 AM, Rosen, Brian wrote: > >>>>>>>>>>>>> I'd also suggest that > >>> our > >>>>>>>>>>>>> charter limitation is really support for sharing of > >>> whitespace > >>>>> by > >>>>>>>>>>>>> whitespace devices. Reporting what you use is not > >>>>>>>>>>>>> sharing, > >>>>> it's > >>>>>>>>>>>>> just data gathering. > >>>>>>>>>>>>> > >>>>>>>>>>>>> The point of excluding sharing was to eliminate the > >>>>> complexities > >>>>>>>>>>>>> of what constituted fairness, and what kinds of > >>> communication > >>>>>>>>>>>>> might be needed between databases, where more than one > >>> could > >>>>>>>>>>>>> supply available whitespace in a band. This doesn't have > >>> any > >>>>> of > >>>>>>>>>>>>> those issues, As long as it's just sending information, I > >>>>> don't > >>>>>>>>>>>>> have a problem. Once the database is supposed to do > >>> anything > >>>>>>>>>>>>> with it that involves changing what spectrum it reports, > >>> then > >>>>> I > >>>>>>>>>>>>> think we cross the line. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Brian > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Mar 6, 2012, at 12:28 PM, > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Joel > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Indeed, the regulator has not described the process or > >>>>> provided > >>>>>>>>>>>>>> a flow diagram, so there may be some wrinkles, but we > >>>>>>>>>>>>>> need > >>> to > >>>>>>>>>>>>>> provide for their intent. To answer your question, the > >>>>> channels > >>>>>>>>>>>>>> that the master will use are sent in a separate message > >>>>>>>>>>>>>> (described in P.12 ter), that occurs after the master > >>>>> receives > >>>>>>>>>>>>>> the response to its channel request, but before the > >>>>>>>>>>>>>> master > >>>>> can > >>>>>>>>>>>>>> transmit. At this point, it knows what channels are > >>>>> available, > >>>>>>>>>>>>>> and which one it will use. As far as the slaves are > >>>>> concerned, > >>>>>>>>>>>>>> as they associate, the master will need to gather their > >>>>> details > >>>>>>>>>>>>>> and send further channel usage messages to the database > >>>>>>>>>>>>>> on their behalf. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Regards > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Andy > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> -----Original Message----- From: paws-bounces@ietf.org > >>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] On Behalf Of Joel M. > >>> Halpern > >>>>>>>>>>>>>> Sent: 06 March 2012 17:05 To: scott.probasco@nokia.com > >> Cc: > >>>>>>>>>>>>>> paws@ietf.org; Cheeseman,CJ,Chris,COD R; > >>> Dixon,JS,Johnny,COD > >>>>> R > >>>>>>>>>>>>>> Subject: Re: [paws] WGLC for > >>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel > >>>>>>>>>>>>>> reporting > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Ahh. I think I see where the request and my > >>>>>>>>>>>>>> understanding divurge. If the idea here is that the > >>>>>>>>>>>>>> master must provide, > >>> in > >>>>>>>>>>>>>> the request, an indication of what channels it expects > to > >>>>> use, > >>>>>>>>>>>>>> I can at least understand that. I will return to > >>> technical > >>>>>>>>>>>>>> concerns in a moment. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> However, when you say "provide channel usage > information, > >>> in > >>>>>>>>>>>>>> order to evaluate interference", what that says to me is > >>>>>>>>>>>>>> providing, during operation, information as to what > >>> channels > >>>>>>>>>>>>>> are being used, and at what power levels. That is what > >>> would > >>>>>>>>>>>>>> be needed to analyze actual interference effects. And > >>>>>>>>>>>>>> that > >>> is > >>>>>>>>>>>>>> out of scope as I understand our scope. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I do see a technical difficulty with having the master > >>>>> provide, > >>>>>>>>>>>>>> as part of either registering or requesting spectrum > >>>>>>>>>>>>>> information, what channels it intends to use. It > doesn;t > >>>>> know > >>>>>>>>>>>>>> what channels it intends to use. It intends to use some > >>>>> number > >>>>>>>>>>>>>> of available channels. It will figure out which ones > >>>>>>>>>>>>>> when > >>> it > >>>>>>>>>>>>>> is told what is available. How can it send that > >>> information > >>>>> in > >>>>>>>>>>>>>> the request? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Yours, Joel > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: > >>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> There is a similarity here with device ID. In context > of > >>>>> PAWS > >>>>>>>>>>>>>>> we are not concerned with why a device ID is required > by > >>> a > >>>>>>>>>>>>>>> regulator, we accept it is a requirement from a > >>>>>>>>>>>>>>> regulator > >>>>> and > >>>>>>>>>>>>>>> include it to the protocol. Ofcom identifies in 3.18& > >>> 3.19 > >>>>>>>>>>>>>>> that channel usage information is required and thus we > >>> need > >>>>>>>>>>>>>>> to include this information. Since the master must > >>> provide > >>>>>>>>>>>>>>> this information prior to transmitting, PAWS will not > >>>>>>>>>>>>>>> function in the UK without this information and thus I > >>>>>>>>>>>>>>> believe channel usage information is integral to the > >>> channel > >>>>>>>>>>>>>>> request& response messaging. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Kind Regards, Scott > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On 3/6/12 10:30 AM, "ext Joel M. > >>>>>>>>>>>>>>> Halpern" wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> I would draw a distinction. Ofcom regulations about > >>>>>>>>>>>>>>>> whitespace requests are very much relevant. Ofcom > >>>>>>>>>>>>>>>> regulations about notification of dynamic behavior > >>> (which > >>>>>>>>>>>>>>>> spectrum is being used) are not in scope as I > >>>>>>>>>>>>>>>> understand the earlier discussions, particularly the > >>>>>>>>>>>>>>>> chartering discussions. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Yours, Joel > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> The ofcom requirements are very much relevant to the > >>>>>>>>>>>>>>>>> scope of the PAWS WG. The only other regulatory > >>>>>>>>>>>>>>>>> requirements that we have today is the FCC. Ofcom > >>>>>>>>>>>>>>>>> requirements are a good addition to the set. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> -Raj > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> On 3/6/12 10:03 AM, "ext > >>>>>>>>>>>>>>>>> andy.sago@bt.com" wrote: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Hi Joel > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> There's no language I can find in the charter that > >>>>>>>>>>>>>>>>>> explicitly puts this out of scope. On the other > hand, > >>>>>>>>>>>>>>>>>> the charter says that the group will "consider input > >>>>>>>>>>>>>>>>>> from regulatory entities", and this is one of the > >>>>>>>>>>>>>>>>>> requirements from Ofcom that they have just > >> published. > >>>>>>>>>>>>>>>>>> The protocol will be worthless for the UK if it > omits > >>>>>>>>>>>>>>>>>> some requirements. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Regards > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Andy > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> -----Original Message----- From: Joel M. Halpern > >>>>>>>>>>>>>>>>>> [mailto:jmh@joelhalpern.com] Sent: 06 March 2012 > >>>>>>>>>>>>>>>>>> 15:53 > >>>>>>>>>>>>>>>>>> To: Sago,AJ,Andy,COD R Cc: paws@ietf.org; > >>>>>>>>>>>>>>>>>> Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for > >>>>>>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: > >>> channel > >>>>>>>>>>>>>>>>>> reporting > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> As I understand, the information you are asking for > >>>>>>>>>>>>>>>>>> is explicitly out of scope for the working group. > >>>>>>>>>>>>>>>>>> Yours, Joel > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: > >>>>>>>>>>>>>>>>>>> All > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Comparing the draft with the Ofcom requirements at > >>>>>>>>>>>>>>>>>>> http://www.cept.org/Documents/se- > >>>>>>>>>> 43/4161/SE43(12)Info03_Draft-UK-r > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>> egul > >>>>>>>>>>>>>>>>>>> atory-requirements-for-white-space-devices-in-the- > >>> UHF- > >>>>> TV- > >>>>>>>>>> band, > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>> I believe the WG draft is deficient in the area of reporting > >>>>>>>>>>>>>>>>>>> frequencies and powers actually used by masters and > >>>>>>>>>>>>>>>>>>> slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom > >>>>>>>>>>>>>>>>>>> intends to collect this data to assesses the impact > >>>>>>>>>>>>>>>>>>> of aggregate interference into other services. It > >>>>>>>>>>>>>>>>>>> would also provide usage information (frequency in > >>>>>>>>>>>>>>>>>>> use) that would inform the operation of a kill > >>>>>>>>>>>>>>>>>>> switch capability. I suggest this deficiency can be > >>>>>>>>>>>>>>>>>>> remedied with the following changes: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> New P requirements (probably best placed following > >>>>>>>>>>>>>>>>>>> P.12): > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> P.12bis: The protocol MUST support a channel usage > >>>>>>>>>>>>>>>>>>> message from the slave device to the master device. > >>>>>>>>>>>>>>>>>>> The channel usage message MUST include parameters > as > >>>>>>>>>>>>>>>>>>> required by local regulatory requirement. These > >>>>>>>>>>>>>>>>>>> parameters MAY include device ID, manufacturer's > >>>>>>>>>>>>>>>>>>> serial number, channel usage and power level > >>>>>>>>>>>>>>>>>>> information. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> P.12ter: The protocol MUST support a channel usage > >>>>>>>>>>>>>>>>>>> message from the master device to the database. > The > >>>>>>>>>>>>>>>>>>> channel usage message MUST include parameters as > >>>>>>>>>>>>>>>>>>> required by local regulatory requirement for the > >>>>>>>>>>>>>>>>>>> master and its associated slaves. These parameters > >>>>>>>>>>>>>>>>>>> MAY include device ID, manufacturer's serial > number, > >>>>>>>>>>>>>>>>>>> channel usage and power level information. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> P.12qua: The protocol MUST support a channel usage > >>>>>>>>>>>>>>>>>>> message acknowledgement. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> New O requirements (probably best placed following > >>>>>>>>>>>>>>>>>>> O13): > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> O.13bis: According to local regulatory policy, > >>>>>>>>>>>>>>>>>>> after connecting to a master device's radio network > >>>>>>>>>>>>>>>>>>> a slave device MAY inform the master device of the > >>>>>>>>>>>>>>>>>>> actual channel usage. The slave MUST include > >>>>>>>>>>>>>>>>>>> parameters required by local regulatory policy, > e.g. > >>>>>>>>>>>>>>>>>>> device ID, manufacturer's serial number, channel > >>>>>>>>>>>>>>>>>>> usage and power level information. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> O.13ter: According to local regulatory policy, a > >>>>>>>>>>>>>>>>>>> master device MAY inform the database of the actual > >>>>>>>>>>>>>>>>>>> channel usage of the master and its slaves. The > >>>>>>>>>>>>>>>>>>> master MUST include parameters required by local > >>>>>>>>>>>>>>>>>>> regulatory policy, e.g. device ID, manufacturer's > >>>>>>>>>>>>>>>>>>> serial number, channel usage and power level > >>>>>>>>>>>>>>>>>>> information of the master and its slaves. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> New steps could be introduced into one or more use > >>>>>>>>>>>>>>>>>>> cases to cover these Ofcom requirements, e.g. new > >>>>>>>>>>>>>>>>>>> steps 6bis and 9bis in the hotspot use case at > >>>>>>>>>>>>>>>>>>> 4.2.1: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> 6bis. Prior to initiating transmission, if required > >>>>>>>>>>>>>>>>>>> by local regulation, the master/AP informs the > >>>>>>>>>>>>>>>>>>> database of the channel and power level it has > >>>>>>>>>>>>>>>>>>> chosen. This is repeated for each slave that > >>>>>>>>>>>>>>>>>>> associated with the master. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> 9bis. Prior to initiating transmission, if required > >>>>>>>>>>>>>>>>>>> by local regulation, the slave informs the > master/AP > >>>>>>>>>>>>>>>>>>> of the channel and power level it has chosen, and > >>>>>>>>>>>>>>>>>>> the master/AP relays this information to the > >> database. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> - end of new text - > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> For information, for those not accessing the url in > >>>>>>>>>>>>>>>>>>> the first paragraph of this email, the full Ofcom > >>>>>>>>>>>>>>>>>>> requirements leading to this new PAWS text are as > >>>>>>>>>>>>>>>>>>> follows: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> 3.18 After receiving instructions from a WSDB in > >>>>>>>>>>>>>>>>>>> relation to the maximum permitted EIRPs over the > DTT > >>>>>>>>>>>>>>>>>>> channels, and prior to initiating transmissions > >>>>>>>>>>>>>>>>>>> within the UHF TV band, a master WSD must > >>>>>>>>>>>>>>>>>>> communicate to the WSDB the following information: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> 3.18.1 The lower and upper frequency boundaries^13 > >>>>>>>>>>>>>>>>>>> of the in-block emissions of the master WSD, and > >>>>>>>>>>>>>>>>>>> those of the in-block emissions of its associated > >>>>>>>>>>>>>>>>>>> slaves. A lower frequency will be specified as (470 > >>>>>>>>>>>>>>>>>>> + 8k + > >>>>>>>>>>>>>>>>>>> 0.2n) MHz, with the corresponding upper frequency > >>>>>>>>>>>>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3?4 k > >> 3?4 > >>>>>>>>>>>>>>>>>>> 39, 0 3?4 n 3?4 39, 1 3?4 m 3?4 40, and n< m. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> 3.18.2 The maximum in-block EIRP spectral densities > >>>>>>>>>>>>>>>>>>> (in dBm/(0.2 MHz)) that the master WSD, and its > >>>>>>>>>>>>>>>>>>> associated slaves, actually radiate between each > >>>>>>>>>>>>>>>>>>> reported lower frequency boundary and its > >>>>>>>>>>>>>>>>>>> corresponding upper frequency boundary. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Footnote 13 states: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> The use of upper and lower frequency boundaries > >>>>>>>>>>>>>>>>>>> (defined over a 200 kHz raster) allows a WSDB to > >>>>>>>>>>>>>>>>>>> collect more granular information with regards to > >>>>>>>>>>>>>>>>>>> the usage of the frequency resource by narrowband > >>>>>>>>>>>>>>>>>>> WSD technologies. The upper and lower frequencies > of > >>>>>>>>>>>>>>>>>>> a boundary pair do not straddle a DTT channel > >> boundary. > >>>>>>>>>>>>>>>>>>> Note that a WSD may transmit over multiple, > >>>>>>>>>>>>>>>>>>> non-contiguous, whole DTT channels or fractions of > >>>>>>>>>>>>>>>>>>> DTT channels. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> 3.19 A master WSD must be able to receive the > >>>>>>>>>>>>>>>>>>> following information^14 from a WSDB: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in > the > >>>>>>>>>>>>>>>>>>> context of 3.18, that the reported information on > >>>>>>>>>>>>>>>>>>> the DTT channels and EIRP spectral densities > >>>>>>>>>>>>>>>>>>> actually used by the master and slave WSDs were > >>>>>>>>>>>>>>>>>>> received successfully by the WSDB^18 ]. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Footnote 14 states: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> 14 While the communication of some of this > >>>>>>>>>>>>>>>>>>> information from a WSDB to a master WSD is > optional, > >>>>>>>>>>>>>>>>>>> master WSDs must be able to receive and interpret > >>>>>>>>>>>>>>>>>>> these. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Footnote 18 states: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> 18 This forms part of a handshake protocol and may > >>>>>>>>>>>>>>>>>>> be an area where industry could harmonise without > >>>>>>>>>>>>>>>>>>> the need for an explicit requirement in the > >> regulations. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Regards > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Andy > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> *From:*paws-bounces@ietf.org > >>>>>>>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] *On Behalf Of > >>>>>>>>>>>>>>>>>>> *Gabor.Bajko@nokia.com *Sent:* 05 March 2012 19:46 > >>>>>>>>>>>>>>>>>>> *To:* paws@ietf.org *Subject:* [paws] WGLC for > >>>>>>>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> The authors of the use cases and requirements draft > >>>>>>>>>>>>>>>>>>> have just posted a new version of the draft and > >>>>>>>>>>>>>>>>>>> indicated that there are no unresolved > >>>>>>>>>>>>>>>>>>> comments/issues they are aware of. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Therefore, I'd like to initiate a WG Last Call for > >>>>>>>>>>>>>>>>>>> comments on > >>>>>>>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf- > paws- > >>>>> problem- > >>>>>>>>>> stmt-u > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>> seca > >>>>>>>>>>>>>>>>>>> ses-rqmts-03.txt > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Please review the draft and send your comments to > >>>>>>>>>>>>>>>>>>> the list by March 20th, 2012. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> If you review the draft and have no comments, send > a > >>>>>>>>>>>>>>>>>>> note to the list that the draft is good as it is, > we > >>>>>>>>>>>>>>>>>>> need these notes as much as we need the actual > >>>>>>>>>>>>>>>>>>> comments. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Thanks, Gabor > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> paws mailing list > >>>>>> paws@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/paws > >>>>>> > >>>>> _______________________________________________ > >>>>> paws mailing list > >>>>> paws@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/paws > >>>>> > >>>>> _______________________________________________ > >>>>> paws mailing list > >>>>> paws@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/paws > >>>> _______________________________________________ > >>>> 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 > >> > >> ________________________________ > >> > >> > *********************************************************************** > * > >> ****************************************** > >> For more information visit www.ofcom.org.uk > >> > >> This email (and any attachments) is confidential and intended for > the > >> use of the addressee only. > >> > >> If you have received this email in error please notify the > originator of > >> the message and delete it from your system. > >> > >> This email has been scanned for viruses. However, you open any > >> attachments at your own risk. > >> > >> Any views expressed in this message are those of the individual > sender > >> and do not represent the views or opinions of Ofcom unless expressly > >> stated otherwise. > >> > *********************************************************************** > * > >> ****************************************** > >> _______________________________________________ > >> paws mailing list > >> paws@ietf.org > >> https://www.ietf.org/mailman/listinfo/paws > >> _______________________________________________ > >> paws mailing list > >> paws@ietf.org > >> https://www.ietf.org/mailman/listinfo/paws > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > https://www.ietf.org/mailman/listinfo/paws From gerald.chouinard@sympatico.ca Fri Mar 9 06:58:55 2012 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 0906E21F852A for ; Fri, 9 Mar 2012 06:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, MSGID_FROM_MTA_HEADER=0.803, 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 2EvrOaL-k-cv for ; Fri, 9 Mar 2012 06:58:52 -0800 (PST) Received: from blu0-omc3-s5.blu0.hotmail.com (blu0-omc3-s5.blu0.hotmail.com [65.55.116.80]) by ietfa.amsl.com (Postfix) with ESMTP id AC30421F84EF for ; Fri, 9 Mar 2012 06:58:47 -0800 (PST) Received: from BLU0-SMTP62 ([65.55.116.74]) by blu0-omc3-s5.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 06:58:47 -0800 X-Originating-IP: [174.95.184.56] X-Originating-Email: [gerald.chouinard@sympatico.ca] Message-ID: Received: from Gerald2 ([174.95.184.56]) by BLU0-SMTP62.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 06:58:45 -0800 From: Gerald Chouinard To: "'Rosen, Brian'" , "'Paul Lambert'" References: , <7BAC95F5A7E67643AAFB2C31BEE662D0157A034B37@SC-VEXCH2.marvell.com> <2D1F0F0C-F3B9-43ED-8195-0962DF863AC8@neustar.biz> Date: Fri, 9 Mar 2012 09:58:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <2D1F0F0C-F3B9-43ED-8195-0962DF863AC8@neustar.biz> Thread-Index: Acz+ACskO8SUp+IDQpSvKz7avSwIagAAV9gg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 09 Mar 2012 14:58:46.0046 (UTC) FILETIME=[20801BE0:01CCFE05] Cc: paws@ietf.org Subject: Re: [paws] WGLC fordraft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 14:58:55 -0000 Brian, Agreed. This acknowledgement should be kept to its simplest form. My guess is that confirming back to the WSDB the channel(s) that is(are) being used by the device and the maximum EIRP that will be used (per channel) should be sufficient for the purpose of interference considerations. The current trend in modern digital communication is to increase the efficiency of the modulation used by a system to its maximum. Intrinsically, this brings the modulated signal close to be noise-like. As a result, for most cases, an interfering signal is seen by other systems as an apparent increase in the noise level. Within certain limits, independent of the actual modulation used, the interfering signal will be seen as noise (e.g., C/I becomes C/N). Under this assumption, there is no need to specify the actual modulation used but rather only the EIRP generated in each channel. This has been proven, for example, for the ATSC-DTV signal which will be affected by any other signals wider than 100 kHz bandwidth as if this was a noise contribution (CRC: ATSC-DTV subjective tests). Only in the case where the interfering signal is narrower than 100 kHz and located in the vicinity of the pilot carrier will the signal be more aggressive than noise. This is likely to be even more the case for DVB-T where there is not pilot carrier to be affected. This kind of assessment has most likely been carried out somewhere in Europe. Unless a modulation with poor spectrum efficiency is used in White Space, all these systems should be seen by other systems as noise-like. If one can assume that all modulation types would need to be approved by local regulators in their territory, one could think that modulations with poor spectrum efficiency would be rejected and then, the simple rule of maximum EIRP per TV channel would be sufficient, leaving the need for only the acknowledgement message carrying the channel(s) occupied and the maximum EIRP per channel. It would be very useful for PAWS that OFCOM clarifies their requirements for the acknowledgement message in the light of what I described above. Gerald -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: Friday, 09 March, 2012 09:23 To: Paul Lambert Cc: Das, Subir; Siew Yoon Tan; Zuniga, Juan Carlos; Basavaraj.Patil@nokia.com; gerald.chouinard@sympatico.ca; jmh@joelhalpern.com; scott.probasco@nokia.com; paws@ietf.org; presnick@qualcomm.com; Reza Karimi; johnny.dixon@bt.com; chris.cheeseman@bt.com Subject: Re: [paws] WGLC fordraft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting We are limited by our charter. As you can see by the discussion, even a minor extension to report channels used in an ack is controversial. Adding a whole new transaction would clearly, in my opinion, be beyond our charter. Charter limitations are good, if frustrating. If we feel we made an error in the original charter, we can ask that it be changed, but it's best to try to work within the charter, get that done, and then expand the scope of the work. Right at the moment, we're trying to accommodate the regulatory requirements of the UK within our initial charter. As such, I would like to see the simplest way to do that and stay within the charter. Any further work could be considered later when we accomplish our initial goals. Brian On Mar 8, 2012, at 9:15 PM, Paul Lambert wrote: > > > > > >> I have a question here. Is it really an acknowledgement or we would like >> to see a kind of notification message that includes channel, and other >> parameters? > > What if it's multiple channels? What happens if the device adapts and changes between modulation technique or bandwidth? Does every change over the air need to be indicated to the GDB? > > This Channel acknowledgement does not seem useful and would limit real world behaviors (like channel and modulation adaptation). > > If viewed as a potential regulatory requirement - does this imply we need to parameterize the protocol to have different behaviors in different regions? > > Paul > > > >> >> Regards, >> _Subir >> >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >> Siew Yoon Tan >> Sent: Thursday, March 08, 2012 4:06 PM >> To: Zuniga, Juan Carlos; Basavaraj.Patil@nokia.com; >> gerald.chouinard@sympatico.ca; jmh@joelhalpern.com; >> scott.probasco@nokia.com >> Cc: paws@ietf.org; presnick@qualcomm.com; Reza Karimi; >> johnny.dixon@bt.com; chris.cheeseman@bt.com >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >> rqmts-03:channel reporting >> >> Dear All, >> >> Regarding Ofcom's requirement to have a return channel as part of the >> protocol between the WSD and WSDB, I would like to confirm to following >> sequence of messaging >> >> Channel request >> Channel response >> Channel acknowledgement >> >> which was raised in an earlier email to this list. >> >> Our view is that it would be beneficial to define the protocol between >> WSD and WSDB that supports this requirement even though how the >> information could be used is still subject to discussion in the UK. >> >> >> Best regards, >> >> Siew Yoon >> >> >> ________________________________________ >> From: paws-bounces@ietf.org [paws-bounces@ietf.org] on behalf of Zuniga, >> Juan Carlos [JuanCarlos.Zuniga@InterDigital.com] >> Sent: 08 March 2012 20:41 >> To: Basavaraj.Patil@nokia.com; gerald.chouinard@sympatico.ca; >> jmh@joelhalpern.com; scott.probasco@nokia.com >> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >> chris.cheeseman@bt.com >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >> rqmts-03:channel reporting >> >> Hi Raj, >> >> I was reusing the language used from Gerald (which I know is familiar to >> people working on IEEE 802 WS groups): >> >>>> [GC] You got it. This would be useless for spectrum regulators. One >>>> should realize that, from the spectrum regulator's point of view, the >>>> second and third messages could be iterated upon to optimize the >>>> spectrum use. >>>> Knowing >>>> what channels the systems in an area are using, the spectrum >>>> regulators and/or other entities such as those taking care of >>>> coexistence could use the database in near-real-time to iterate on >>>> the two last messages to reduce the range of channels that some >>>> systems may use once they know precisely what channels are being used >>>> in the area. The PAWS protocol would carry the information back and >>>> forth but would not be involved in such spectrum use optimization. >> >> Having said that, I have no issue sticking to the WSDB terminology. I >> like keeping things simple :) >> >> JC >> >>> -----Original Message----- >>> From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] >>> Sent: Thursday, March 08, 2012 3:33 PM >>> To: Zuniga, Juan Carlos; gerald.chouinard@sympatico.ca; >>> jmh@joelhalpern.com; scott.probasco@nokia.com >>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>> chris.cheeseman@bt.com >>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >>> rqmts-03:channel reporting >>> >>> >>> Hi JC, >>> >>> Where/why did the coexistence manager come into the picture? Your >>> comment about "communicating back to the WSDB/coexistence manager" may >>> result in further misunderstanding. If we simply stick to to WSDB I >>> think we are okay. >>> >>> -Raj >>> >>> On 3/8/12 2:25 PM, "ext Zuniga, Juan Carlos" >>> wrote: >>> >>>> So, from Gerald and Andy's comments, it seems like from the point of >>> view >>>> of (at least) two regulatory entities it is important for the >>>> protocol >>> to >>>> allow communicating back to the WSDB/coexistence manager the actual >>>> channel usage after the first query is made. >>>> >>>> This is to me a very clear requirement. >>>> >>>> The actual messages/IEs that would carry this information should be >>>> discussed as part of the solution document, and not the requirements. >>>> >>>> JC >>>> >>>>> -----Original Message----- >>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >>>>> Behalf >>> Of >>>>> Gerald Chouinard >>>>> Sent: Thursday, March 08, 2012 1:59 PM >>>>> To: 'Joel M. Halpern'; scott.probasco@nokia.com >>>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>>>> chris.cheeseman@bt.com >>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >>>>> rqmts-03:channel reporting >>>>> >>>>> Joel, Scott, >>>>> >>>>> Interesting discussion! See my comments in line below. >>>>> >>>>> Gerald >>>>> >>>>> -----Original Message----- >>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >>>>> Behalf >>> Of >>>>> Joel >>>>> M. Halpern >>>>> Sent: Thursday, 08 March, 2012 13:17 >>>>> To: scott.probasco@nokia.com >>>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>>>> chris.cheeseman@bt.com >>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >>>>> rqmts-03: >>>>> channel reporting >>>>> >>>>> So why won't the device simply say "I will use all of this?" >>>>> [GC] This would defeat the purpose of the acknowledgement message. >>>>> After all, that way it needs to do less work with the database. >>>>> And >>> it >>>>> can change frequencies when it wants. >>>>> Given that the stated goal of the Ofcom requriement was to be able >>> to >>>>> analyze interference effects, it seems that this will not actually >>> lead >>>>> to them getting what they want, even if it does comply with the >>>>> regulations. >>>>> [GC] You got it. This would be useless for spectrum regulators. >>>>> One should realize that, from the spectrum regulator's point of >>>>> view, the >>> second >>>>> and >>>>> third messages could be iterated upon to optimize the spectrum use. >>>>> Knowing >>>>> what channels the systems in an area are using, the spectrum >>> regulators >>>>> and/or other entities such as those taking care of coexistence >>>>> could use the database in near-real-time to iterate on the two last >>>>> messages to reduce the range of channels that some systems may use >>>>> once they know precisely what channels are being used in the area. >>>>> The PAWS protocol would carry >>> the >>>>> information back and forth but would not be involved in such >>> spectrum >>>>> use >>>>> optimization. >>>>> >>>>> Yours, >>>>> joel >>>>> >>>>> On 3/8/2012 1:09 PM, scott.probasco@nokia.com wrote: >>>>>> Hi Peter, >>>>>> >>>>>> Answers below. >>>>>> >>>>>> Kind Regards, >>>>>> Scott >>>>>> >>>>>> On 3/8/12 11:39 AM, "ext Peter Saint-Andre" >>>>> wrote: >>>>>> >>>>>>> Hi Scott, I have two clarifying questions: >>>>>>> >>>>>>> 1. Does the device know, when it receives the channel response, >>>>> which >>>>>>> channel it will actually use? >>>>>> Scott->This is all new and I am not aware of any existing >>>>> implementations. >>>>>> I would argue that the device must decide what channel(s) it will >>> use >>>>> when >>>>>> it receives the channel response. >>>>> [GC] Agree with Scott but this is only a portion of the >>> considerations. >>>>> If a >>>>> device was to operate on its own, this would be true but a >>>>> communication device usually implies at least 2 devices to >>>>> communicate. Hence, the choice of the channel to be used will need >>>>> to be negotiated between the two devices before a choice can be >>>>> made. The chosen channel will belong to the >>> set >>>>> of >>>>> available channels that is common to both devices. Remember that >>> some >>>>> channels may be available at one device and not at the other >>>>> because >>> of >>>>> their geolocation or other reason. Extending this concept to a star >>>>> network topology, the channel that will be selected by this network >>>>> will >>> have >>>>> to >>>>> belong to the set of channels that are available to all devices. >>> Each >>>>> device >>>>> will not be able to decide by itself which channel it wants to use. >>>>> >>>>> This is why in such a star topology, it makes sense that the slave >>>>> devices to a base station or access point be represented by the >>>>> base station acting as the master on their behalf to query the >>>>> database and receive the list of available channels (and/or maximum >>>>> EIRP per channel). It is then the responsibility of the base >>>>> station to identify the set of available channels that is common >>>>> for itself and all its slaves to decide on the >>> channel >>>>> that >>>>> the network will use. As you can see, in this case, there is no >>>>> need for each slave to receive its list of available channels. On >>>>> its own, it would not know what to do with it. The only thing that >>>>> needs to be sent >>> from >>>>> the >>>>> master device to its slaves is the resulting operating channel. >>>>> >>>>> I a more sophisticated operation, the master device may add one or >>>>> a few backup channels extracted from the common set of available >>>>> channel >>> to >>>>> the >>>>> message going to its slave so that if a change in channel >>> availability >>>>> occurs, an instantaneous switch to the next backup channel can be >>> made >>>>> without any further signaling, thus providing for a channel switch >>> that >>>>> is >>>>> transparent to the user. It is the scheme that has been included in >>> the >>>>> IEEE >>>>> 802.22-2011 Standard. This is why I don't believe that PAWS should >>> get >>>>> involved in defining this signaling between the base station and >>>>> its slaves devices. >>>>>>> >>>>>>> 2. If the device then uses another channel or a different >>> channel, >>>>> does >>>>>>> it need to report that change to the database? >>>>>> Scott->My interpretation of section 3.18 is that the device can >>> only >>>>>> transmit within the upper& lower frequencies returned in the >>>>>> acknowledgment. I do not (quickly) find any reference in the >>>>> requirements >>>>>> to changing channels. Thus operationally it could be that the >>> channel >>>>>> request process must be repeated before the device can use a >>>>> different >>>>>> channel (frequencies). >>>>> [GC] If the process involves 2 messages, then, the device and its >>>>> associated devices could change channels at will as long as all >>>>> these channels belong to the set of available channel. However, if >>>>> the third message is added, it would make sense that the master >>>>> device reports to the database any channel change that would occur >>>>> to the database, otherwise, the status of >>> the >>>>> spectrum occupation would be wrong at any moment and would be >>> useless >>>>> for >>>>> the purpose of any spectrum usage optimization such as coexistence. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> Peter >>>>>>> >>>>>>> On 3/8/12 10:17 AM, scott.probasco@nokia.com wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> The point from Brian is very relevant: >>>>>>>> >>>>>>>> Channel request >>>>>>>> Channel response >>>>>>>> Channel acknowledgement >>>>>>>> >>>>>>>> What Ofcom does with the information in the acknowledgement >>>>>>>> does >>>>> not >>>>>>>> matter. As the regulator in UK, they write rules that must be >>>>> followed >>>>>>>> in >>>>>>>> order to operate a whitespace radio in the UK. I believe the >>> scope >>>>> of >>>>>>>> the >>>>>>>> WG must be focused on a working solution. If this is simple >>> channel >>>>>>>> request& response in one regulator's domain, PAWS can support >>>>> this. If >>>>>>>> it >>>>>>>> means a channel request, response and acknowledgement in >>>>>>>> another regulator's domain, PAWS can support this. As a >>>>>>>> participating >>>>> member of >>>>>>>> the work group, I believe the scope should be basic working >>>>> solution, >>>>>>>> not >>>>>>>> limited to a specific number of messages. >>>>>>>> >>>>>>>> Kind Regards, >>>>>>>> Scott >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 3/8/12 11:11 AM, "ext Zuniga, Juan Carlos" >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Peter, Nancy, >>>>>>>>> >>>>>>>>> I agree should design a protocol with the best of our current >>>>>>>>> knowledge, and that should be accounting for all the known >>>>>>>>> regulations at >>>>> present >>>>>>>>> time. We should not limit the scope with the purpose of >>> designing >>>>> a >>>>>>>>> protocol 'faster'. Our goal is not only to design a WSDB >>> protocol. >>>>> Our >>>>>>>>> goal is to design a WSDB protocol that is USEFUL to the >>> community. >>>>>>>>> >>>>>>>>> The charter does state that >>>>>>>>> >>>>>>>>> "...the group should also reach out to other potential >>>>>>>>> "customers" for a white space database access method and >>> consider >>>>> input >>>>>>>>> from regulatory entities that are involved in the >>>>>>>>> specification >>> of >>>>> the >>>>>>>>> rules for secondary use of spectrum in specific radio bands. " >>>>>>>>> >>>>>>>>> I think that is exactly what we are doing now. >>>>>>>>> >>>>>>>>> Regarding whether the types of requirements belong to #1 or >>>>>>>>> #2, >>> I >>>>>>>>> believe >>>>>>>>> it is more of #1 type, as the information to be exchanged >>>>>>>>> would >>> be >>>>>>>>> known >>>>>>>>> after the initial query/response. >>>>>>>>> >>>>>>>>> If we know it today, I see no reason why we should not work on >>> it >>>>> in >>>>>>>>> the >>>>>>>>> first phase of the work. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Juan Carlos >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >>>>> Behalf >>>>>>>>>> Of >>>>>>>>>> Peter Saint-Andre >>>>>>>>>> Sent: Thursday, March 08, 2012 11:59 AM >>>>>>>>>> To: Nancy Bravin >>>>>>>>>> Cc: paws@ietf.org; johnny.dixon@bt.com; >>> chris.cheeseman@bt.com; >>>>> Pete >>>>>>>>>> Resnick >>>>>>>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- >>>>> usecases- >>>>>>>>>> rqmts-03: channel reporting >>>>>>>>>> >>>>>>>>>> Hi Nancy, >>>>>>>>>> >>>>>>>>>> You are absolutely right that different locales will have >>>>> different >>>>>>>>>> rules and requirements. We need to understand those, and work >>> to >>>>>>>>>> address >>>>>>>>>> them if possible (although we don't necessarily need to >>> address >>>>> them >>>>>>>>>> all >>>>>>>>>> at the same time). I see several kinds of requirements: >>>>>>>>>> >>>>>>>>>> 1. Some requirements might lead to features beyond the >>>>> query/response >>>>>>>>>> protocol we've envisioned so far. One example might be real- >>> time >>>>>>>>>> reporting about the channels that a device is actually using. >>> In >>>>> my >>>>>>>>>> opinion, it would be best to handle those in the next phase >>>>>>>>>> of >>>>> work, >>>>>>>>>> because as far as I can see they are outside the scope of our >>>>> charter. >>>>>>>>>> >>>>>>>>>> 2. Some requirements might be handled through by defining >>>>> additional >>>>>>>>>> fields that can be included in the query or response. We >>>>> definitely >>>>>>>>>> planned for that when working on the charter with the IESG: >>>>>>>>>> >>>>>>>>>> In addition, the particular >>>>>>>>>> data exchanged between a device and a database might >>>>>>>>>> depend >>> on >>>>> the >>>>>>>>>> ranges of radio spectrum that are to be used, the >>> requirements >>>>> of >>>>>>>>>> the >>>>>>>>>> database operators and their governing regulations, and >>> other >>>>>>>>>> factors. >>>>>>>>>> Therefore, the database access method and the >>> query/response >>>>> data >>>>>>>>>> formats that are exchanged using that method need to be >>>>> designed >>>>> for >>>>>>>>>> extensibility rather than being tied to any specific >>> spectrum, >>>>>>>>>> country, or phy/mac/air interface. >>>>>>>>>> >>>>>>>>>> It's unclear to me right now if the Ofcom requirement fits >>> into >>>>> #1 or >>>>>>>>>> #2, which is why we're having this discussion. :) >>>>>>>>>> >>>>>>>>>> Peter >>>>>>>>>> >>>>>>>>>> On 3/7/12 8:17 PM, Nancy Bravin wrote: >>>>>>>>>>> Peter and all, >>>>>>>>>>> >>>>>>>>>>> I agree that it is important to revisit now, so that in the >>>>> future, >>>>>>>>>>> it will be easy to align things in their proper place. Every >>>>> country >>>>>>>>>>> may have different regulations, spectrum, policy and what >>>>>>>>>>> responsibility is in the domain of the system, and what >>>>>>>>>>> comes >>>>> under >>>>>>>>>>> the PAWS charter is important. Maybe some separation might >>> be >>>>>>>>>>> possible, and dividing and clarifying issues now will help >>>>>>>>>>> in >>>>> the >>>>>>>>>>> future. Certainly it seems that the FCC may change some >>> rules, >>>>> and >>>>>>>>>>> we know that Ofcom is not yet finished with their >>> regulations. >>>>> Canada >>>>>>>>>>> has their own, and other countries are working on this as >>> well. >>>>> Just >>>>>>>>>>> a thought...Sharing is a realistic goal...as is off >>> loading... >>>>> Or you >>>>>>>>>>> slim line and every 6 months decide what to incorporate in >>> the >>>>>>>>>>> protocol based on new information, new ideas, new innovation >>> new >>>>>>>>>>> regulations and maybe spend more time than you could if >>>>> addressed >>>>>>>>>>> now. >>>>>>>>>>> >>>>>>>>>>> That way you leave the door open and outside of referencing >>> what >>>>> is >>>>>>>>>>> known today, by referencing regulations i.e. Ofcom, FCC, >>>>> Industry >>>>>>>>>>> Canada etc as of XX-XX-XXXX date. Out of scope not something >>> we >>>>> know >>>>>>>>>>> enough about to say at this point, In my opinion. >>>>>>>>>>> >>>>>>>>>>> My 2 cents.. >>>>>>>>>>> >>>>>>>>>>> Sincerely, Nancy >>>>>>>>>>> >>>>>>>>>>> On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> As your responsible Area Director (until March 28, when >>>>>>>>>>>> Pete Resnick will take over from me), I have reviewed this >>> thread. >>>>>>>>>>>> >>>>>>>>>>>> In my opinion (I am happy to be proven wrong), this new >>>>> requirement >>>>>>>>>>>> goes beyond what the charter defined as the scope of this >>>>> working >>>>>>>>>>>> group, which was to enable a device to discover the white >>> space >>>>>>>>>>>> available to it in its current location. Reporting usage >>> back >>>>> to >>>>>>>>>>>> the database is simply not mentioned in the charter. >>>>>>>>>>>> >>>>>>>>>>>> Earlier in this thread, Andy Sago wrote: >>>>>>>>>>>> >>>>>>>>>>>> There's no language I can find in the charter that >>> explicitly >>>>> puts >>>>>>>>>>>> this out of scope. >>>>>>>>>>>> >>>>>>>>>>>> An IETF charter defines what the working group shall work >>> on. >>>>> Many >>>>>>>>>>>> interesting features could be developed here. However, it >>>>>>>>>>>> is >>>>> not >>>>>>>>>>>> the job of the charter to mention explicitly that each of >>> those >>>>>>>>>>>> interesting features is out of scope. >>>>>>>>>>>> >>>>>>>>>>>> The charter does say: >>>>>>>>>>>> >>>>>>>>>>>> Once the device learns of the available white space (e.g., >>> in a >>>>> TV >>>>>>>>>>>> white space implementation, the list of available channels >>> at >>>>> that >>>>>>>>>>>> location), it can then select one of the bands from the >>>>>>>>>>>> list >>>>> and >>>>>>>>>>>> begin to transmit and receive on the selected band. >>>>>>>>>>>> >>>>>>>>>>>> This text might have assumed that no further communication >>> or >>>>>>>>>>>> authorization was required in order to select one of the >>> bands >>>>> from >>>>>>>>>>>> the list and then transmit/receive. Perhaps that assumption >>> was >>>>>>>>>>>> mistaken. If so, it would be good to have a discussion >>>>>>>>>>>> about >>>>> that, >>>>>>>>>>>> so we can determine if we need to revisit the assumptions >>>>>>>>>>>> we >>>>> made >>>>>>>>>>>> early on. If in fact we made some faulty or limited >>>>> assumptions, >>>>>>>>>>>> then let's get that out in the open. >>>>>>>>>>>> >>>>>>>>>>>> Peter >>>>>>>>>>>> >>>>>>>>>>>> On 3/7/12 9:40 AM, Rosen, Brian wrote: >>>>>>>>>>>>> I'd also suggest that >>> our >>>>>>>>>>>>> charter limitation is really support for sharing of >>> whitespace >>>>> by >>>>>>>>>>>>> whitespace devices. Reporting what you use is not >>>>>>>>>>>>> sharing, >>>>> it's >>>>>>>>>>>>> just data gathering. >>>>>>>>>>>>> >>>>>>>>>>>>> The point of excluding sharing was to eliminate the >>>>> complexities >>>>>>>>>>>>> of what constituted fairness, and what kinds of >>> communication >>>>>>>>>>>>> might be needed between databases, where more than one >>> could >>>>>>>>>>>>> supply available whitespace in a band. This doesn't have >>> any >>>>> of >>>>>>>>>>>>> those issues, As long as it's just sending information, I >>>>> don't >>>>>>>>>>>>> have a problem. Once the database is supposed to do >>> anything >>>>>>>>>>>>> with it that involves changing what spectrum it reports, >>> then >>>>> I >>>>>>>>>>>>> think we cross the line. >>>>>>>>>>>>> >>>>>>>>>>>>> Brian >>>>>>>>>>>>> >>>>>>>>>>>>> On Mar 6, 2012, at 12:28 PM, >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Joel >>>>>>>>>>>>>> >>>>>>>>>>>>>> Indeed, the regulator has not described the process or >>>>> provided >>>>>>>>>>>>>> a flow diagram, so there may be some wrinkles, but we >>>>>>>>>>>>>> need >>> to >>>>>>>>>>>>>> provide for their intent. To answer your question, the >>>>> channels >>>>>>>>>>>>>> that the master will use are sent in a separate message >>>>>>>>>>>>>> (described in P.12 ter), that occurs after the master >>>>> receives >>>>>>>>>>>>>> the response to its channel request, but before the >>>>>>>>>>>>>> master >>>>> can >>>>>>>>>>>>>> transmit. At this point, it knows what channels are >>>>> available, >>>>>>>>>>>>>> and which one it will use. As far as the slaves are >>>>> concerned, >>>>>>>>>>>>>> as they associate, the master will need to gather their >>>>> details >>>>>>>>>>>>>> and send further channel usage messages to the database >>>>>>>>>>>>>> on their behalf. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards >>>>>>>>>>>>>> >>>>>>>>>>>>>> Andy >>>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- From: paws-bounces@ietf.org >>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] On Behalf Of Joel M. >>> Halpern >>>>>>>>>>>>>> Sent: 06 March 2012 17:05 To: scott.probasco@nokia.com >> Cc: >>>>>>>>>>>>>> paws@ietf.org; Cheeseman,CJ,Chris,COD R; >>> Dixon,JS,Johnny,COD >>>>> R >>>>>>>>>>>>>> Subject: Re: [paws] WGLC for >>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel >>>>>>>>>>>>>> reporting >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ahh. I think I see where the request and my >>>>>>>>>>>>>> understanding divurge. If the idea here is that the >>>>>>>>>>>>>> master must provide, >>> in >>>>>>>>>>>>>> the request, an indication of what channels it expects to >>>>> use, >>>>>>>>>>>>>> I can at least understand that. I will return to >>> technical >>>>>>>>>>>>>> concerns in a moment. >>>>>>>>>>>>>> >>>>>>>>>>>>>> However, when you say "provide channel usage information, >>> in >>>>>>>>>>>>>> order to evaluate interference", what that says to me is >>>>>>>>>>>>>> providing, during operation, information as to what >>> channels >>>>>>>>>>>>>> are being used, and at what power levels. That is what >>> would >>>>>>>>>>>>>> be needed to analyze actual interference effects. And >>>>>>>>>>>>>> that >>> is >>>>>>>>>>>>>> out of scope as I understand our scope. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I do see a technical difficulty with having the master >>>>> provide, >>>>>>>>>>>>>> as part of either registering or requesting spectrum >>>>>>>>>>>>>> information, what channels it intends to use. It doesn;t >>>>> know >>>>>>>>>>>>>> what channels it intends to use. It intends to use some >>>>> number >>>>>>>>>>>>>> of available channels. It will figure out which ones >>>>>>>>>>>>>> when >>> it >>>>>>>>>>>>>> is told what is available. How can it send that >>> information >>>>> in >>>>>>>>>>>>>> the request? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There is a similarity here with device ID. In context of >>>>> PAWS >>>>>>>>>>>>>>> we are not concerned with why a device ID is required by >>> a >>>>>>>>>>>>>>> regulator, we accept it is a requirement from a >>>>>>>>>>>>>>> regulator >>>>> and >>>>>>>>>>>>>>> include it to the protocol. Ofcom identifies in 3.18& >>> 3.19 >>>>>>>>>>>>>>> that channel usage information is required and thus we >>> need >>>>>>>>>>>>>>> to include this information. Since the master must >>> provide >>>>>>>>>>>>>>> this information prior to transmitting, PAWS will not >>>>>>>>>>>>>>> function in the UK without this information and thus I >>>>>>>>>>>>>>> believe channel usage information is integral to the >>> channel >>>>>>>>>>>>>>> request& response messaging. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Kind Regards, Scott >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 3/6/12 10:30 AM, "ext Joel M. >>>>>>>>>>>>>>> Halpern" wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I would draw a distinction. Ofcom regulations about >>>>>>>>>>>>>>>> whitespace requests are very much relevant. Ofcom >>>>>>>>>>>>>>>> regulations about notification of dynamic behavior >>> (which >>>>>>>>>>>>>>>> spectrum is being used) are not in scope as I >>>>>>>>>>>>>>>> understand the earlier discussions, particularly the >>>>>>>>>>>>>>>> chartering discussions. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The ofcom requirements are very much relevant to the >>>>>>>>>>>>>>>>> scope of the PAWS WG. The only other regulatory >>>>>>>>>>>>>>>>> requirements that we have today is the FCC. Ofcom >>>>>>>>>>>>>>>>> requirements are a good addition to the set. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -Raj >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 3/6/12 10:03 AM, "ext >>>>>>>>>>>>>>>>> andy.sago@bt.com" wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi Joel >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> There's no language I can find in the charter that >>>>>>>>>>>>>>>>>> explicitly puts this out of scope. On the other hand, >>>>>>>>>>>>>>>>>> the charter says that the group will "consider input >>>>>>>>>>>>>>>>>> from regulatory entities", and this is one of the >>>>>>>>>>>>>>>>>> requirements from Ofcom that they have just >> published. >>>>>>>>>>>>>>>>>> The protocol will be worthless for the UK if it omits >>>>>>>>>>>>>>>>>> some requirements. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Andy >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -----Original Message----- From: Joel M. Halpern >>>>>>>>>>>>>>>>>> [mailto:jmh@joelhalpern.com] Sent: 06 March 2012 >>>>>>>>>>>>>>>>>> 15:53 >>>>>>>>>>>>>>>>>> To: Sago,AJ,Andy,COD R Cc: paws@ietf.org; >>>>>>>>>>>>>>>>>> Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for >>>>>>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: >>> channel >>>>>>>>>>>>>>>>>> reporting >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> As I understand, the information you are asking for >>>>>>>>>>>>>>>>>> is explicitly out of scope for the working group. >>>>>>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >>>>>>>>>>>>>>>>>>> All >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Comparing the draft with the Ofcom requirements at >>>>>>>>>>>>>>>>>>> http://www.cept.org/Documents/se- >>>>>>>>>> 43/4161/SE43(12)Info03_Draft-UK-r >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>> egul >>>>>>>>>>>>>>>>>>> atory-requirements-for-white-space-devices-in-the- >>> UHF- >>>>> TV- >>>>>>>>>> band, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>> I believe the WG draft is deficient in the area of reporting >>>>>>>>>>>>>>>>>>> frequencies and powers actually used by masters and >>>>>>>>>>>>>>>>>>> slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom >>>>>>>>>>>>>>>>>>> intends to collect this data to assesses the impact >>>>>>>>>>>>>>>>>>> of aggregate interference into other services. It >>>>>>>>>>>>>>>>>>> would also provide usage information (frequency in >>>>>>>>>>>>>>>>>>> use) that would inform the operation of a kill >>>>>>>>>>>>>>>>>>> switch capability. I suggest this deficiency can be >>>>>>>>>>>>>>>>>>> remedied with the following changes: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> New P requirements (probably best placed following >>>>>>>>>>>>>>>>>>> P.12): >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> P.12bis: The protocol MUST support a channel usage >>>>>>>>>>>>>>>>>>> message from the slave device to the master device. >>>>>>>>>>>>>>>>>>> The channel usage message MUST include parameters as >>>>>>>>>>>>>>>>>>> required by local regulatory requirement. These >>>>>>>>>>>>>>>>>>> parameters MAY include device ID, manufacturer's >>>>>>>>>>>>>>>>>>> serial number, channel usage and power level >>>>>>>>>>>>>>>>>>> information. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> P.12ter: The protocol MUST support a channel usage >>>>>>>>>>>>>>>>>>> message from the master device to the database. The >>>>>>>>>>>>>>>>>>> channel usage message MUST include parameters as >>>>>>>>>>>>>>>>>>> required by local regulatory requirement for the >>>>>>>>>>>>>>>>>>> master and its associated slaves. These parameters >>>>>>>>>>>>>>>>>>> MAY include device ID, manufacturer's serial number, >>>>>>>>>>>>>>>>>>> channel usage and power level information. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> P.12qua: The protocol MUST support a channel usage >>>>>>>>>>>>>>>>>>> message acknowledgement. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> New O requirements (probably best placed following >>>>>>>>>>>>>>>>>>> O13): >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> O.13bis: According to local regulatory policy, >>>>>>>>>>>>>>>>>>> after connecting to a master device's radio network >>>>>>>>>>>>>>>>>>> a slave device MAY inform the master device of the >>>>>>>>>>>>>>>>>>> actual channel usage. The slave MUST include >>>>>>>>>>>>>>>>>>> parameters required by local regulatory policy, e.g. >>>>>>>>>>>>>>>>>>> device ID, manufacturer's serial number, channel >>>>>>>>>>>>>>>>>>> usage and power level information. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> O.13ter: According to local regulatory policy, a >>>>>>>>>>>>>>>>>>> master device MAY inform the database of the actual >>>>>>>>>>>>>>>>>>> channel usage of the master and its slaves. The >>>>>>>>>>>>>>>>>>> master MUST include parameters required by local >>>>>>>>>>>>>>>>>>> regulatory policy, e.g. device ID, manufacturer's >>>>>>>>>>>>>>>>>>> serial number, channel usage and power level >>>>>>>>>>>>>>>>>>> information of the master and its slaves. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> New steps could be introduced into one or more use >>>>>>>>>>>>>>>>>>> cases to cover these Ofcom requirements, e.g. new >>>>>>>>>>>>>>>>>>> steps 6bis and 9bis in the hotspot use case at >>>>>>>>>>>>>>>>>>> 4.2.1: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 6bis. Prior to initiating transmission, if required >>>>>>>>>>>>>>>>>>> by local regulation, the master/AP informs the >>>>>>>>>>>>>>>>>>> database of the channel and power level it has >>>>>>>>>>>>>>>>>>> chosen. This is repeated for each slave that >>>>>>>>>>>>>>>>>>> associated with the master. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 9bis. Prior to initiating transmission, if required >>>>>>>>>>>>>>>>>>> by local regulation, the slave informs the master/AP >>>>>>>>>>>>>>>>>>> of the channel and power level it has chosen, and >>>>>>>>>>>>>>>>>>> the master/AP relays this information to the >> database. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> - end of new text - >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> For information, for those not accessing the url in >>>>>>>>>>>>>>>>>>> the first paragraph of this email, the full Ofcom >>>>>>>>>>>>>>>>>>> requirements leading to this new PAWS text are as >>>>>>>>>>>>>>>>>>> follows: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 3.18 After receiving instructions from a WSDB in >>>>>>>>>>>>>>>>>>> relation to the maximum permitted EIRPs over the DTT >>>>>>>>>>>>>>>>>>> channels, and prior to initiating transmissions >>>>>>>>>>>>>>>>>>> within the UHF TV band, a master WSD must >>>>>>>>>>>>>>>>>>> communicate to the WSDB the following information: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 3.18.1 The lower and upper frequency boundaries^13 >>>>>>>>>>>>>>>>>>> of the in-block emissions of the master WSD, and >>>>>>>>>>>>>>>>>>> those of the in-block emissions of its associated >>>>>>>>>>>>>>>>>>> slaves. A lower frequency will be specified as (470 >>>>>>>>>>>>>>>>>>> + 8k + >>>>>>>>>>>>>>>>>>> 0.2n) MHz, with the corresponding upper frequency >>>>>>>>>>>>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3?4 k >> 3?4 >>>>>>>>>>>>>>>>>>> 39, 0 3?4 n 3?4 39, 1 3?4 m 3?4 40, and n< m. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 3.18.2 The maximum in-block EIRP spectral densities >>>>>>>>>>>>>>>>>>> (in dBm/(0.2 MHz)) that the master WSD, and its >>>>>>>>>>>>>>>>>>> associated slaves, actually radiate between each >>>>>>>>>>>>>>>>>>> reported lower frequency boundary and its >>>>>>>>>>>>>>>>>>> corresponding upper frequency boundary. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Footnote 13 states: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The use of upper and lower frequency boundaries >>>>>>>>>>>>>>>>>>> (defined over a 200 kHz raster) allows a WSDB to >>>>>>>>>>>>>>>>>>> collect more granular information with regards to >>>>>>>>>>>>>>>>>>> the usage of the frequency resource by narrowband >>>>>>>>>>>>>>>>>>> WSD technologies. The upper and lower frequencies of >>>>>>>>>>>>>>>>>>> a boundary pair do not straddle a DTT channel >> boundary. >>>>>>>>>>>>>>>>>>> Note that a WSD may transmit over multiple, >>>>>>>>>>>>>>>>>>> non-contiguous, whole DTT channels or fractions of >>>>>>>>>>>>>>>>>>> DTT channels. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 3.19 A master WSD must be able to receive the >>>>>>>>>>>>>>>>>>> following information^14 from a WSDB: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in the >>>>>>>>>>>>>>>>>>> context of 3.18, that the reported information on >>>>>>>>>>>>>>>>>>> the DTT channels and EIRP spectral densities >>>>>>>>>>>>>>>>>>> actually used by the master and slave WSDs were >>>>>>>>>>>>>>>>>>> received successfully by the WSDB^18 ]. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Footnote 14 states: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 14 While the communication of some of this >>>>>>>>>>>>>>>>>>> information from a WSDB to a master WSD is optional, >>>>>>>>>>>>>>>>>>> master WSDs must be able to receive and interpret >>>>>>>>>>>>>>>>>>> these. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Footnote 18 states: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 18 This forms part of a handshake protocol and may >>>>>>>>>>>>>>>>>>> be an area where industry could harmonise without >>>>>>>>>>>>>>>>>>> the need for an explicit requirement in the >> regulations. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Andy >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> *From:*paws-bounces@ietf.org >>>>>>>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] *On Behalf Of >>>>>>>>>>>>>>>>>>> *Gabor.Bajko@nokia.com *Sent:* 05 March 2012 19:46 >>>>>>>>>>>>>>>>>>> *To:* paws@ietf.org *Subject:* [paws] WGLC for >>>>>>>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The authors of the use cases and requirements draft >>>>>>>>>>>>>>>>>>> have just posted a new version of the draft and >>>>>>>>>>>>>>>>>>> indicated that there are no unresolved >>>>>>>>>>>>>>>>>>> comments/issues they are aware of. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Therefore, I'd like to initiate a WG Last Call for >>>>>>>>>>>>>>>>>>> comments on >>>>>>>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-paws- >>>>> problem- >>>>>>>>>> stmt-u >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>> seca >>>>>>>>>>>>>>>>>>> ses-rqmts-03.txt >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Please review the draft and send your comments to >>>>>>>>>>>>>>>>>>> the list by March 20th, 2012. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> If you review the draft and have no comments, send a >>>>>>>>>>>>>>>>>>> note to the list that the draft is good as it is, we >>>>>>>>>>>>>>>>>>> need these notes as much as we need the actual >>>>>>>>>>>>>>>>>>> comments. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, Gabor >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> paws mailing list >>>>>> paws@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>> >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>>> >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>> _______________________________________________ >>>> 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 >> >> ________________________________ >> >> ************************************************************************ >> ****************************************** >> For more information visit www.ofcom.org.uk >> >> This email (and any attachments) is confidential and intended for the >> use of the addressee only. >> >> If you have received this email in error please notify the originator of >> the message and delete it from your system. >> >> This email has been scanned for viruses. However, you open any >> attachments at your own risk. >> >> Any views expressed in this message are those of the individual sender >> and do not represent the views or opinions of Ofcom unless expressly >> stated otherwise. >> ************************************************************************ >> ****************************************** >> _______________________________________________ >> 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 chris.cheeseman@bt.com Fri Mar 9 03:36:51 2012 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 73F9A21F85ED for ; Fri, 9 Mar 2012 03:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.972 X-Spam-Level: X-Spam-Status: No, score=-0.972 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, 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 Gg6O84TX0DIO for ; Fri, 9 Mar 2012 03:36:37 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 5206C21F8624 for ; Fri, 9 Mar 2012 03:36:04 -0800 (PST) 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.213.0; Fri, 9 Mar 2012 11:36:03 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.101]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Fri, 9 Mar 2012 11:36:03 +0000 From: To: , , , , , , , Date: Fri, 9 Mar 2012 11:36:02 +0000 Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting Thread-Index: AQHM/YFmF0824TXodkK/mH1uWWNaL5ZhGdfggAAfIxCAAJm4YA== Message-ID: References: , <7BAC95F5A7E67643AAFB2C31BEE662D0157A034B37@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D0157A034B37@SC-VEXCH2.marvell.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 X-Mailman-Approved-At: Fri, 09 Mar 2012 07:45:42 -0800 Cc: paws@ietf.org, presnick@qualcomm.com, Reza.Karimi@ofcom.org.uk, johnny.dixon@bt.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 11:38:10 -0000 Hi My reading of the UK regulatory requirements that Ofcom has made available = is that the Acknowledgement message that must be communicated back to the d= atabase from the white space device is simply the frequency range (or range= s) and maximum eirp density that the device intends to use (a subset of wha= t it would have been offered by the database). I don't believe there is any= intent to limit modulation schemes etc. as part of this exchange. This see= ms a relatively straightforward requirement and the PAWS protocol should ac= commodate this if it is to be relevant for the UK regulatory environment. Regards, Chris -----Original Message----- From: Paul Lambert [mailto:paul@marvell.com] Sent: 09 March 2012 02:15 To: Das, Subir; 'Siew Yoon Tan'; Zuniga, Juan Carlos; Basavaraj.Patil@nokia= .com; gerald.chouinard@sympatico.ca; jmh@joelhalpern.com; scott.probasco@no= kia.com Cc: paws@ietf.org; presnick@qualcomm.com; Reza Karimi; Dixon,JS,Johnny,COD = R; Cheeseman,CJ,Chris,COD R Subject: RE: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03= :channel reporting >I have a question here. Is it really an acknowledgement or we would >like to see a kind of notification message that includes channel, and >other parameters? What if it's multiple channels? What happens if the device adapts and chan= ges between modulation technique or bandwidth? Does every change over the = air need to be indicated to the GDB? This Channel acknowledgement does not seem useful and would limit real worl= d behaviors (like channel and modulation adaptation). If viewed as a potential regulatory requirement - does this imply we need t= o parameterize the protocol to have different behaviors in different region= s? Paul > >Regards, >_Subir > >-----Original Message----- >From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >Siew Yoon Tan >Sent: Thursday, March 08, 2012 4:06 PM >To: Zuniga, Juan Carlos; Basavaraj.Patil@nokia.com; >gerald.chouinard@sympatico.ca; jmh@joelhalpern.com; >scott.probasco@nokia.com >Cc: paws@ietf.org; presnick@qualcomm.com; Reza Karimi; >johnny.dixon@bt.com; chris.cheeseman@bt.com >Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >rqmts-03:channel reporting > >Dear All, > >Regarding Ofcom's requirement to have a return channel as part of the >protocol between the WSD and WSDB, I would like to confirm to following >sequence of messaging > >Channel request >Channel response >Channel acknowledgement > >which was raised in an earlier email to this list. > >Our view is that it would be beneficial to define the protocol between >WSD and WSDB that supports this requirement even though how the >information could be used is still subject to discussion in the UK. > > >Best regards, > >Siew Yoon > > >________________________________________ >From: paws-bounces@ietf.org [paws-bounces@ietf.org] on behalf of >Zuniga, Juan Carlos [JuanCarlos.Zuniga@InterDigital.com] >Sent: 08 March 2012 20:41 >To: Basavaraj.Patil@nokia.com; gerald.chouinard@sympatico.ca; >jmh@joelhalpern.com; scott.probasco@nokia.com >Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >chris.cheeseman@bt.com >Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >rqmts-03:channel reporting > >Hi Raj, > >I was reusing the language used from Gerald (which I know is familiar >to people working on IEEE 802 WS groups): > >>> [GC] You got it. This would be useless for spectrum regulators. One >>> should realize that, from the spectrum regulator's point of view, >>> the second and third messages could be iterated upon to optimize the >>> spectrum use. >>> Knowing >>> what channels the systems in an area are using, the spectrum >>> regulators and/or other entities such as those taking care of >>> coexistence could use the database in near-real-time to iterate on >>> the two last messages to reduce the range of channels that some >>> systems may use once they know precisely what channels are being >>> used in the area. The PAWS protocol would carry the information back >>> and forth but would not be involved in such spectrum use optimization. > >Having said that, I have no issue sticking to the WSDB terminology. I >like keeping things simple :) > >JC > >> -----Original Message----- >> From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] >> Sent: Thursday, March 08, 2012 3:33 PM >> To: Zuniga, Juan Carlos; gerald.chouinard@sympatico.ca; >> jmh@joelhalpern.com; scott.probasco@nokia.com >> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >> chris.cheeseman@bt.com >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >> rqmts-03:channel reporting >> >> >> Hi JC, >> >> Where/why did the coexistence manager come into the picture? Your >> comment about "communicating back to the WSDB/coexistence manager" >> may result in further misunderstanding. If we simply stick to to WSDB >> I think we are okay. >> >> -Raj >> >> On 3/8/12 2:25 PM, "ext Zuniga, Juan Carlos" >> wrote: >> >> >So, from Gerald and Andy's comments, it seems like from the point of >> view >> >of (at least) two regulatory entities it is important for the >> >protocol >> to >> >allow communicating back to the WSDB/coexistence manager the actual >> >channel usage after the first query is made. >> > >> >This is to me a very clear requirement. >> > >> >The actual messages/IEs that would carry this information should be >> >discussed as part of the solution document, and not the requirements. >> > >> >JC >> > >> >> -----Original Message----- >> >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >> >> Behalf >> Of >> >> Gerald Chouinard >> >> Sent: Thursday, March 08, 2012 1:59 PM >> >> To: 'Joel M. Halpern'; scott.probasco@nokia.com >> >> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >> >> chris.cheeseman@bt.com >> >> Subject: Re: [paws] WGLC for >> >> draft-ietf-paws-problem-stmt-usecases- >> >> rqmts-03:channel reporting >> >> >> >> Joel, Scott, >> >> >> >> Interesting discussion! See my comments in line below. >> >> >> >> Gerald >> >> >> >> -----Original Message----- >> >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >> >> Behalf >> Of >> >> Joel >> >> M. Halpern >> >> Sent: Thursday, 08 March, 2012 13:17 >> >> To: scott.probasco@nokia.com >> >> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >> >> chris.cheeseman@bt.com >> >> Subject: Re: [paws] WGLC for >> >> draft-ietf-paws-problem-stmt-usecases- >> >> rqmts-03: >> >> channel reporting >> >> >> >> So why won't the device simply say "I will use all of this?" >> >> [GC] This would defeat the purpose of the acknowledgement message. >> >> After all, that way it needs to do less work with the database. >> >> And >> it >> >> can change frequencies when it wants. >> >> Given that the stated goal of the Ofcom requriement was to be able >> to >> >> analyze interference effects, it seems that this will not actually >> lead >> >> to them getting what they want, even if it does comply with the >> >> regulations. >> >> [GC] You got it. This would be useless for spectrum regulators. >> >> One should realize that, from the spectrum regulator's point of >> >> view, the >> second >> >> and >> >> third messages could be iterated upon to optimize the spectrum use. >> >> Knowing >> >> what channels the systems in an area are using, the spectrum >> regulators >> >> and/or other entities such as those taking care of coexistence >> >> could use the database in near-real-time to iterate on the two >> >> last messages to reduce the range of channels that some systems >> >> may use once they know precisely what channels are being used in the = area. >> >> The PAWS protocol would carry >> the >> >> information back and forth but would not be involved in such >> spectrum >> >> use >> >> optimization. >> >> >> >> Yours, >> >> joel >> >> >> >> On 3/8/2012 1:09 PM, scott.probasco@nokia.com wrote: >> >> > Hi Peter, >> >> > >> >> > Answers below. >> >> > >> >> > Kind Regards, >> >> > Scott >> >> > >> >> > On 3/8/12 11:39 AM, "ext Peter Saint-Andre" >> >> wrote: >> >> > >> >> >> Hi Scott, I have two clarifying questions: >> >> >> >> >> >> 1. Does the device know, when it receives the channel response, >> >> which >> >> >> channel it will actually use? >> >> > Scott->This is all new and I am not aware of any existing >> >> implementations. >> >> > I would argue that the device must decide what channel(s) it >> >> > will >> use >> >> when >> >> > it receives the channel response. >> >> [GC] Agree with Scott but this is only a portion of the >> considerations. >> >> If a >> >> device was to operate on its own, this would be true but a >> >> communication device usually implies at least 2 devices to >> >> communicate. Hence, the choice of the channel to be used will need >> >> to be negotiated between the two devices before a choice can be >> >> made. The chosen channel will belong to the >> set >> >> of >> >> available channels that is common to both devices. Remember that >> some >> >> channels may be available at one device and not at the other >> >> because >> of >> >> their geolocation or other reason. Extending this concept to a >> >> star network topology, the channel that will be selected by this >> >> network will >> have >> >> to >> >> belong to the set of channels that are available to all devices. >> Each >> >> device >> >> will not be able to decide by itself which channel it wants to use. >> >> >> >> This is why in such a star topology, it makes sense that the slave >> >> devices to a base station or access point be represented by the >> >> base station acting as the master on their behalf to query the >> >> database and receive the list of available channels (and/or >> >> maximum EIRP per channel). It is then the responsibility of the >> >> base station to identify the set of available channels that is >> >> common for itself and all its slaves to decide on the >> channel >> >> that >> >> the network will use. As you can see, in this case, there is no >> >> need for each slave to receive its list of available channels. On >> >> its own, it would not know what to do with it. The only thing that >> >> needs to be sent >> from >> >> the >> >> master device to its slaves is the resulting operating channel. >> >> >> >> I a more sophisticated operation, the master device may add one or >> >> a few backup channels extracted from the common set of available >> >> channel >> to >> >> the >> >> message going to its slave so that if a change in channel >> availability >> >> occurs, an instantaneous switch to the next backup channel can be >> made >> >> without any further signaling, thus providing for a channel switch >> that >> >> is >> >> transparent to the user. It is the scheme that has been included >> >> in >> the >> >> IEEE >> >> 802.22-2011 Standard. This is why I don't believe that PAWS should >> get >> >> involved in defining this signaling between the base station and >> >> its slaves devices. >> >> >> >> >> >> 2. If the device then uses another channel or a different >> channel, >> >> does >> >> >> it need to report that change to the database? >> >> > Scott->My interpretation of section 3.18 is that the device can >> only >> >> > transmit within the upper& lower frequencies returned in the >> >> > acknowledgment. I do not (quickly) find any reference in the >> >> requirements >> >> > to changing channels. Thus operationally it could be that the >> channel >> >> > request process must be repeated before the device can use a >> >> different >> >> > channel (frequencies). >> >> [GC] If the process involves 2 messages, then, the device and its >> >> associated devices could change channels at will as long as all >> >> these channels belong to the set of available channel. However, if >> >> the third message is added, it would make sense that the master >> >> device reports to the database any channel change that would occur >> >> to the database, otherwise, the status of >> the >> >> spectrum occupation would be wrong at any moment and would be >> useless >> >> for >> >> the purpose of any spectrum usage optimization such as coexistence. >> >> >> >> >> >> Thanks! >> >> >> >> >> >> Peter >> >> >> >> >> >> On 3/8/12 10:17 AM, scott.probasco@nokia.com wrote: >> >> >>> Hi, >> >> >>> >> >> >>> The point from Brian is very relevant: >> >> >>> >> >> >>> Channel request >> >> >>> Channel response >> >> >>> Channel acknowledgement >> >> >>> >> >> >>> What Ofcom does with the information in the acknowledgement >> >> >>> does >> >> not >> >> >>> matter. As the regulator in UK, they write rules that must be >> >> followed >> >> >>> in >> >> >>> order to operate a whitespace radio in the UK. I believe the >> scope >> >> of >> >> >>> the >> >> >>> WG must be focused on a working solution. If this is simple >> channel >> >> >>> request& response in one regulator's domain, PAWS can support >> >> this. If >> >> >>> it >> >> >>> means a channel request, response and acknowledgement in >> >> >>> another regulator's domain, PAWS can support this. As a >> >> >>> participating >> >> member of >> >> >>> the work group, I believe the scope should be basic working >> >> solution, >> >> >>> not >> >> >>> limited to a specific number of messages. >> >> >>> >> >> >>> Kind Regards, >> >> >>> Scott >> >> >>> >> >> >>> >> >> >>> >> >> >>> On 3/8/12 11:11 AM, "ext Zuniga, Juan Carlos" >> >> >>> wrote: >> >> >>> >> >> >>>> Peter, Nancy, >> >> >>>> >> >> >>>> I agree should design a protocol with the best of our current >> >> >>>> knowledge, and that should be accounting for all the known >> >> >>>> regulations at >> >> present >> >> >>>> time. We should not limit the scope with the purpose of >> designing >> >> a >> >> >>>> protocol 'faster'. Our goal is not only to design a WSDB >> protocol. >> >> Our >> >> >>>> goal is to design a WSDB protocol that is USEFUL to the >> community. >> >> >>>> >> >> >>>> The charter does state that >> >> >>>> >> >> >>>> "...the group should also reach out to other potential >> >> >>>> "customers" for a white space database access method and >> consider >> >> input >> >> >>> >from regulatory entities that are involved in the >> >> >>> >specification >> of >> >> the >> >> >>>> rules for secondary use of spectrum in specific radio bands. " >> >> >>>> >> >> >>>> I think that is exactly what we are doing now. >> >> >>>> >> >> >>>> Regarding whether the types of requirements belong to #1 or >> >> >>>> #2, >> I >> >> >>>> believe >> >> >>>> it is more of #1 type, as the information to be exchanged >> >> >>>> would >> be >> >> >>>> known >> >> >>>> after the initial query/response. >> >> >>>> >> >> >>>> If we know it today, I see no reason why we should not work >> >> >>>> on >> it >> >> in >> >> >>>> the >> >> >>>> first phase of the work. >> >> >>>> >> >> >>>> Regards, >> >> >>>> >> >> >>>> Juan Carlos >> >> >>>> >> >> >>>>> -----Original Message----- >> >> >>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] >> >> >>>>> On >> >> Behalf >> >> >>>>> Of >> >> >>>>> Peter Saint-Andre >> >> >>>>> Sent: Thursday, March 08, 2012 11:59 AM >> >> >>>>> To: Nancy Bravin >> >> >>>>> Cc: paws@ietf.org; johnny.dixon@bt.com; >> chris.cheeseman@bt.com; >> >> Pete >> >> >>>>> Resnick >> >> >>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- >> >> usecases- >> >> >>>>> rqmts-03: channel reporting >> >> >>>>> >> >> >>>>> Hi Nancy, >> >> >>>>> >> >> >>>>> You are absolutely right that different locales will have >> >> different >> >> >>>>> rules and requirements. We need to understand those, and >> >> >>>>> work >> to >> >> >>>>> address >> >> >>>>> them if possible (although we don't necessarily need to >> address >> >> them >> >> >>>>> all >> >> >>>>> at the same time). I see several kinds of requirements: >> >> >>>>> >> >> >>>>> 1. Some requirements might lead to features beyond the >> >> query/response >> >> >>>>> protocol we've envisioned so far. One example might be real- >> time >> >> >>>>> reporting about the channels that a device is actually using. >> In >> >> my >> >> >>>>> opinion, it would be best to handle those in the next phase >> >> >>>>> of >> >> work, >> >> >>>>> because as far as I can see they are outside the scope of >> >> >>>>> our >> >> charter. >> >> >>>>> >> >> >>>>> 2. Some requirements might be handled through by defining >> >> additional >> >> >>>>> fields that can be included in the query or response. We >> >> definitely >> >> >>>>> planned for that when working on the charter with the IESG: >> >> >>>>> >> >> >>>>> In addition, the particular >> >> >>>>> data exchanged between a device and a database might >> >> >>>>> depend >> on >> >> the >> >> >>>>> ranges of radio spectrum that are to be used, the >> requirements >> >> of >> >> >>>>> the >> >> >>>>> database operators and their governing regulations, and >> other >> >> >>>>> factors. >> >> >>>>> Therefore, the database access method and the >> query/response >> >> data >> >> >>>>> formats that are exchanged using that method need to be >> >> designed >> >> for >> >> >>>>> extensibility rather than being tied to any specific >> spectrum, >> >> >>>>> country, or phy/mac/air interface. >> >> >>>>> >> >> >>>>> It's unclear to me right now if the Ofcom requirement fits >> into >> >> #1 or >> >> >>>>> #2, which is why we're having this discussion. :) >> >> >>>>> >> >> >>>>> Peter >> >> >>>>> >> >> >>>>> On 3/7/12 8:17 PM, Nancy Bravin wrote: >> >> >>>>>> Peter and all, >> >> >>>>>> >> >> >>>>>> I agree that it is important to revisit now, so that in the >> >> future, >> >> >>>>>> it will be easy to align things in their proper place. >> >> >>>>>> Every >> >> country >> >> >>>>>> may have different regulations, spectrum, policy and what >> >> >>>>>> responsibility is in the domain of the system, and what >> >> >>>>>> comes >> >> under >> >> >>>>>> the PAWS charter is important. Maybe some separation might >> be >> >> >>>>>> possible, and dividing and clarifying issues now will help >> >> >>>>>> in >> >> the >> >> >>>>>> future. Certainly it seems that the FCC may change some >> rules, >> >> and >> >> >>>>>> we know that Ofcom is not yet finished with their >> regulations. >> >> Canada >> >> >>>>>> has their own, and other countries are working on this as >> well. >> >> Just >> >> >>>>>> a thought...Sharing is a realistic goal...as is off >> loading... >> >> Or you >> >> >>>>>> slim line and every 6 months decide what to incorporate in >> the >> >> >>>>>> protocol based on new information, new ideas, new >> >> >>>>>> innovation >> new >> >> >>>>>> regulations and maybe spend more time than you could if >> >> addressed >> >> >>>>>> now. >> >> >>>>>> >> >> >>>>>> That way you leave the door open and outside of referencing >> what >> >> is >> >> >>>>>> known today, by referencing regulations i.e. Ofcom, FCC, >> >> Industry >> >> >>>>>> Canada etc as of XX-XX-XXXX date. Out of scope not >> >> >>>>>> something >> we >> >> know >> >> >>>>>> enough about to say at this point, In my opinion. >> >> >>>>>> >> >> >>>>>> My 2 cents.. >> >> >>>>>> >> >> >>>>>> Sincerely, Nancy >> >> >>>>>> >> >> >>>>>> On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote: >> >> >>>>>> >> >> >>>>>>> >> >> >>>>>>> >> >> >>>>>>> As your responsible Area Director (until March 28, when >> >> >>>>>>> Pete Resnick will take over from me), I have reviewed this >> thread. >> >> >>>>>>> >> >> >>>>>>> In my opinion (I am happy to be proven wrong), this new >> >> requirement >> >> >>>>>>> goes beyond what the charter defined as the scope of this >> >> working >> >> >>>>>>> group, which was to enable a device to discover the white >> space >> >> >>>>>>> available to it in its current location. Reporting usage >> back >> >> to >> >> >>>>>>> the database is simply not mentioned in the charter. >> >> >>>>>>> >> >> >>>>>>> Earlier in this thread, Andy Sago wrote: >> >> >>>>>>> >> >> >>>>>>> There's no language I can find in the charter that >> explicitly >> >> puts >> >> >>>>>>> this out of scope. >> >> >>>>>>> >> >> >>>>>>> An IETF charter defines what the working group shall work >> on. >> >> Many >> >> >>>>>>> interesting features could be developed here. However, it >> >> >>>>>>> is >> >> not >> >> >>>>>>> the job of the charter to mention explicitly that each of >> those >> >> >>>>>>> interesting features is out of scope. >> >> >>>>>>> >> >> >>>>>>> The charter does say: >> >> >>>>>>> >> >> >>>>>>> Once the device learns of the available white space (e.g., >> in a >> >> TV >> >> >>>>>>> white space implementation, the list of available channels >> at >> >> that >> >> >>>>>>> location), it can then select one of the bands from the >> >> >>>>>>> list >> >> and >> >> >>>>>>> begin to transmit and receive on the selected band. >> >> >>>>>>> >> >> >>>>>>> This text might have assumed that no further communication >> or >> >> >>>>>>> authorization was required in order to select one of the >> bands >> >> from >> >> >>>>>>> the list and then transmit/receive. Perhaps that >> >> >>>>>>> assumption >> was >> >> >>>>>>> mistaken. If so, it would be good to have a discussion >> >> >>>>>>> about >> >> that, >> >> >>>>>>> so we can determine if we need to revisit the assumptions >> >> >>>>>>> we >> >> made >> >> >>>>>>> early on. If in fact we made some faulty or limited >> >> assumptions, >> >> >>>>>>> then let's get that out in the open. >> >> >>>>>>> >> >> >>>>>>> Peter >> >> >>>>>>> >> >> >>>>>>> On 3/7/12 9:40 AM, Rosen, Brian wrote: >> >> >>>>>>>> I'd also suggest that >> our >> >> >>>>>>>> charter limitation is really support for sharing of >> whitespace >> >> by >> >> >>>>>>>> whitespace devices. Reporting what you use is not >> >> >>>>>>>> sharing, >> >> it's >> >> >>>>>>>> just data gathering. >> >> >>>>>>>> >> >> >>>>>>>> The point of excluding sharing was to eliminate the >> >> complexities >> >> >>>>>>>> of what constituted fairness, and what kinds of >> communication >> >> >>>>>>>> might be needed between databases, where more than one >> could >> >> >>>>>>>> supply available whitespace in a band. This doesn't have >> any >> >> of >> >> >>>>>>>> those issues, As long as it's just sending information, I >> >> don't >> >> >>>>>>>> have a problem. Once the database is supposed to do >> anything >> >> >>>>>>>> with it that involves changing what spectrum it reports, >> then >> >> I >> >> >>>>>>>> think we cross the line. >> >> >>>>>>>> >> >> >>>>>>>> Brian >> >> >>>>>>>> >> >> >>>>>>>> On Mar 6, 2012, at 12:28 PM, >> >> >>>>>>>> wrote: >> >> >>>>>>>> >> >> >>>>>>>>> Joel >> >> >>>>>>>>> >> >> >>>>>>>>> Indeed, the regulator has not described the process or >> >> provided >> >> >>>>>>>>> a flow diagram, so there may be some wrinkles, but we >> >> >>>>>>>>> need >> to >> >> >>>>>>>>> provide for their intent. To answer your question, the >> >> channels >> >> >>>>>>>>> that the master will use are sent in a separate message >> >> >>>>>>>>> (described in P.12 ter), that occurs after the master >> >> receives >> >> >>>>>>>>> the response to its channel request, but before the >> >> >>>>>>>>> master >> >> can >> >> >>>>>>>>> transmit. At this point, it knows what channels are >> >> available, >> >> >>>>>>>>> and which one it will use. As far as the slaves are >> >> concerned, >> >> >>>>>>>>> as they associate, the master will need to gather their >> >> details >> >> >>>>>>>>> and send further channel usage messages to the database >> >> >>>>>>>>> on their behalf. >> >> >>>>>>>>> >> >> >>>>>>>>> Regards >> >> >>>>>>>>> >> >> >>>>>>>>> Andy >> >> >>>>>>>>> >> >> >>>>>>>>> -----Original Message----- From: paws-bounces@ietf.org >> >> >>>>>>>>> [mailto:paws-bounces@ietf.org] On Behalf Of Joel M. >> Halpern >> >> >>>>>>>>> Sent: 06 March 2012 17:05 To: scott.probasco@nokia.com >Cc: >> >> >>>>>>>>> paws@ietf.org; Cheeseman,CJ,Chris,COD R; >> Dixon,JS,Johnny,COD >> >> R >> >> >>>>>>>>> Subject: Re: [paws] WGLC for >> >> >>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel >> >> >>>>>>>>> reporting >> >> >>>>>>>>> >> >> >>>>>>>>> Ahh. I think I see where the request and my >> >> >>>>>>>>> understanding divurge. If the idea here is that the >> >> >>>>>>>>> master must provide, >> in >> >> >>>>>>>>> the request, an indication of what channels it expects >> >> >>>>>>>>> to >> >> use, >> >> >>>>>>>>> I can at least understand that. I will return to >> technical >> >> >>>>>>>>> concerns in a moment. >> >> >>>>>>>>> >> >> >>>>>>>>> However, when you say "provide channel usage >> >> >>>>>>>>> information, >> in >> >> >>>>>>>>> order to evaluate interference", what that says to me is >> >> >>>>>>>>> providing, during operation, information as to what >> channels >> >> >>>>>>>>> are being used, and at what power levels. That is what >> would >> >> >>>>>>>>> be needed to analyze actual interference effects. And >> >> >>>>>>>>> that >> is >> >> >>>>>>>>> out of scope as I understand our scope. >> >> >>>>>>>>> >> >> >>>>>>>>> I do see a technical difficulty with having the master >> >> provide, >> >> >>>>>>>>> as part of either registering or requesting spectrum >> >> >>>>>>>>> information, what channels it intends to use. It >> >> >>>>>>>>> doesn;t >> >> know >> >> >>>>>>>>> what channels it intends to use. It intends to use some >> >> number >> >> >>>>>>>>> of available channels. It will figure out which ones >> >> >>>>>>>>> when >> it >> >> >>>>>>>>> is told what is available. How can it send that >> information >> >> in >> >> >>>>>>>>> the request? >> >> >>>>>>>>> >> >> >>>>>>>>> Yours, Joel >> >> >>>>>>>>> >> >> >>>>>>>>> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: >> >> >>>>>>>>>> Hi, >> >> >>>>>>>>>> >> >> >>>>>>>>>> There is a similarity here with device ID. In context >> >> >>>>>>>>>> of >> >> PAWS >> >> >>>>>>>>>> we are not concerned with why a device ID is required >> >> >>>>>>>>>> by >> a >> >> >>>>>>>>>> regulator, we accept it is a requirement from a >> >> >>>>>>>>>> regulator >> >> and >> >> >>>>>>>>>> include it to the protocol. Ofcom identifies in 3.18& >> 3.19 >> >> >>>>>>>>>> that channel usage information is required and thus we >> need >> >> >>>>>>>>>> to include this information. Since the master must >> provide >> >> >>>>>>>>>> this information prior to transmitting, PAWS will not >> >> >>>>>>>>>> function in the UK without this information and thus I >> >> >>>>>>>>>> believe channel usage information is integral to the >> channel >> >> >>>>>>>>>> request& response messaging. >> >> >>>>>>>>>> >> >> >>>>>>>>>> Kind Regards, Scott >> >> >>>>>>>>>> >> >> >>>>>>>>>> >> >> >>>>>>>>>> On 3/6/12 10:30 AM, "ext Joel M. >> >> >>>>>>>>>> Halpern" wrote: >> >> >>>>>>>>>> >> >> >>>>>>>>>>> I would draw a distinction. Ofcom regulations about >> >> >>>>>>>>>>> whitespace requests are very much relevant. Ofcom >> >> >>>>>>>>>>> regulations about notification of dynamic behavior >> (which >> >> >>>>>>>>>>> spectrum is being used) are not in scope as I >> >> >>>>>>>>>>> understand the earlier discussions, particularly the >> >> >>>>>>>>>>> chartering discussions. >> >> >>>>>>>>>>> >> >> >>>>>>>>>>> Yours, Joel >> >> >>>>>>>>>>> >> >> >>>>>>>>>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: >> >> >>>>>>>>>>>> >> >> >>>>>>>>>>>> The ofcom requirements are very much relevant to the >> >> >>>>>>>>>>>> scope of the PAWS WG. The only other regulatory >> >> >>>>>>>>>>>> requirements that we have today is the FCC. Ofcom >> >> >>>>>>>>>>>> requirements are a good addition to the set. >> >> >>>>>>>>>>>> >> >> >>>>>>>>>>>> -Raj >> >> >>>>>>>>>>>> >> >> >>>>>>>>>>>> On 3/6/12 10:03 AM, "ext >> >> >>>>>>>>>>>> andy.sago@bt.com" wrote: >> >> >>>>>>>>>>>> >> >> >>>>>>>>>>>>> Hi Joel >> >> >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> There's no language I can find in the charter that >> >> >>>>>>>>>>>>> explicitly puts this out of scope. On the other >> >> >>>>>>>>>>>>> hand, the charter says that the group will "consider >> >> >>>>>>>>>>>>> input from regulatory entities", and this is one of >> >> >>>>>>>>>>>>> the requirements from Ofcom that they have just >published. >> >> >>>>>>>>>>>>> The protocol will be worthless for the UK if it >> >> >>>>>>>>>>>>> omits some requirements. >> >> >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> Regards >> >> >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> Andy >> >> >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> -----Original Message----- From: Joel M. Halpern >> >> >>>>>>>>>>>>> [mailto:jmh@joelhalpern.com] Sent: 06 March 2012 >> >> >>>>>>>>>>>>> 15:53 >> >> >>>>>>>>>>>>> To: Sago,AJ,Andy,COD R Cc: paws@ietf.org; >> >> >>>>>>>>>>>>> Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for >> >> >>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: >> channel >> >> >>>>>>>>>>>>> reporting >> >> >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> As I understand, the information you are asking for >> >> >>>>>>>>>>>>> is explicitly out of scope for the working group. >> >> >>>>>>>>>>>>> Yours, Joel >> >> >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >> >> >>>>>>>>>>>>>> All >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Comparing the draft with the Ofcom requirements at >> >> >>>>>>>>>>>>>> http://www.cept.org/Documents/se- >> >> >>>>> 43/4161/SE43(12)Info03_Draft-UK-r >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> >>>>> egul >> >> >>>>>>>>>>>>>> atory-requirements-for-white-space-devices-in-the- >> UHF- >> >> TV- >> >> >>>>> band, >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> >>>>> I believe the WG draft is deficient in the area of reporting >> >> >>>>>>>>>>>>>> frequencies and powers actually used by masters and >> >> >>>>>>>>>>>>>> slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom >> >> >>>>>>>>>>>>>> intends to collect this data to assesses the impact >> >> >>>>>>>>>>>>>> of aggregate interference into other services. It >> >> >>>>>>>>>>>>>> would also provide usage information (frequency in >> >> >>>>>>>>>>>>>> use) that would inform the operation of a kill >> >> >>>>>>>>>>>>>> switch capability. I suggest this deficiency can be >> >> >>>>>>>>>>>>>> remedied with the following changes: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> New P requirements (probably best placed following >> >> >>>>>>>>>>>>>> P.12): >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> P.12bis: The protocol MUST support a channel usage >> >> >>>>>>>>>>>>>> message from the slave device to the master device. >> >> >>>>>>>>>>>>>> The channel usage message MUST include parameters >> >> >>>>>>>>>>>>>> as required by local regulatory requirement. These >> >> >>>>>>>>>>>>>> parameters MAY include device ID, manufacturer's >> >> >>>>>>>>>>>>>> serial number, channel usage and power level >> >> >>>>>>>>>>>>>> information. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> P.12ter: The protocol MUST support a channel usage >> >> >>>>>>>>>>>>>> message from the master device to the database. >> >> >>>>>>>>>>>>>> The channel usage message MUST include parameters >> >> >>>>>>>>>>>>>> as required by local regulatory requirement for the >> >> >>>>>>>>>>>>>> master and its associated slaves. These parameters >> >> >>>>>>>>>>>>>> MAY include device ID, manufacturer's serial >> >> >>>>>>>>>>>>>> number, channel usage and power level information. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> P.12qua: The protocol MUST support a channel usage >> >> >>>>>>>>>>>>>> message acknowledgement. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> New O requirements (probably best placed following >> >> >>>>>>>>>>>>>> O13): >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> O.13bis: According to local regulatory policy, >> >> >>>>>>>>>>>>>> after connecting to a master device's radio network >> >> >>>>>>>>>>>>>> a slave device MAY inform the master device of the >> >> >>>>>>>>>>>>>> actual channel usage. The slave MUST include >> >> >>>>>>>>>>>>>> parameters required by local regulatory policy, e.g. >> >> >>>>>>>>>>>>>> device ID, manufacturer's serial number, channel >> >> >>>>>>>>>>>>>> usage and power level information. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> O.13ter: According to local regulatory policy, a >> >> >>>>>>>>>>>>>> master device MAY inform the database of the actual >> >> >>>>>>>>>>>>>> channel usage of the master and its slaves. The >> >> >>>>>>>>>>>>>> master MUST include parameters required by local >> >> >>>>>>>>>>>>>> regulatory policy, e.g. device ID, manufacturer's >> >> >>>>>>>>>>>>>> serial number, channel usage and power level >> >> >>>>>>>>>>>>>> information of the master and its slaves. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> New steps could be introduced into one or more use >> >> >>>>>>>>>>>>>> cases to cover these Ofcom requirements, e.g. new >> >> >>>>>>>>>>>>>> steps 6bis and 9bis in the hotspot use case at >> >> >>>>>>>>>>>>>> 4.2.1: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 6bis. Prior to initiating transmission, if required >> >> >>>>>>>>>>>>>> by local regulation, the master/AP informs the >> >> >>>>>>>>>>>>>> database of the channel and power level it has >> >> >>>>>>>>>>>>>> chosen. This is repeated for each slave that >> >> >>>>>>>>>>>>>> associated with the master. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 9bis. Prior to initiating transmission, if required >> >> >>>>>>>>>>>>>> by local regulation, the slave informs the >> >> >>>>>>>>>>>>>> master/AP of the channel and power level it has >> >> >>>>>>>>>>>>>> chosen, and the master/AP relays this information >> >> >>>>>>>>>>>>>> to the >database. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> - end of new text - >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> For information, for those not accessing the url in >> >> >>>>>>>>>>>>>> the first paragraph of this email, the full Ofcom >> >> >>>>>>>>>>>>>> requirements leading to this new PAWS text are as >> >> >>>>>>>>>>>>>> follows: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 3.18 After receiving instructions from a WSDB in >> >> >>>>>>>>>>>>>> relation to the maximum permitted EIRPs over the >> >> >>>>>>>>>>>>>> DTT channels, and prior to initiating transmissions >> >> >>>>>>>>>>>>>> within the UHF TV band, a master WSD must >> >> >>>>>>>>>>>>>> communicate to the WSDB the following information: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 3.18.1 The lower and upper frequency boundaries^13 >> >> >>>>>>>>>>>>>> of the in-block emissions of the master WSD, and >> >> >>>>>>>>>>>>>> those of the in-block emissions of its associated >> >> >>>>>>>>>>>>>> slaves. A lower frequency will be specified as (470 >> >> >>>>>>>>>>>>>> + 8k + >> >> >>>>>>>>>>>>>> 0.2n) MHz, with the corresponding upper frequency >> >> >>>>>>>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3?4 k >3?4 >> >> >>>>>>>>>>>>>> 39, 0 3?4 n 3?4 39, 1 3?4 m 3?4 40, and n< m. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 3.18.2 The maximum in-block EIRP spectral densities >> >> >>>>>>>>>>>>>> (in dBm/(0.2 MHz)) that the master WSD, and its >> >> >>>>>>>>>>>>>> associated slaves, actually radiate between each >> >> >>>>>>>>>>>>>> reported lower frequency boundary and its >> >> >>>>>>>>>>>>>> corresponding upper frequency boundary. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Footnote 13 states: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> The use of upper and lower frequency boundaries >> >> >>>>>>>>>>>>>> (defined over a 200 kHz raster) allows a WSDB to >> >> >>>>>>>>>>>>>> collect more granular information with regards to >> >> >>>>>>>>>>>>>> the usage of the frequency resource by narrowband >> >> >>>>>>>>>>>>>> WSD technologies. The upper and lower frequencies >> >> >>>>>>>>>>>>>> of a boundary pair do not straddle a DTT channel >boundary. >> >> >>>>>>>>>>>>>> Note that a WSD may transmit over multiple, >> >> >>>>>>>>>>>>>> non-contiguous, whole DTT channels or fractions of >> >> >>>>>>>>>>>>>> DTT channels. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 3.19 A master WSD must be able to receive the >> >> >>>>>>>>>>>>>> following information^14 from a WSDB: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in the >> >> >>>>>>>>>>>>>> context of 3.18, that the reported information on >> >> >>>>>>>>>>>>>> the DTT channels and EIRP spectral densities >> >> >>>>>>>>>>>>>> actually used by the master and slave WSDs were >> >> >>>>>>>>>>>>>> received successfully by the WSDB^18 ]. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Footnote 14 states: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 14 While the communication of some of this >> >> >>>>>>>>>>>>>> information from a WSDB to a master WSD is >> >> >>>>>>>>>>>>>> optional, master WSDs must be able to receive and >> >> >>>>>>>>>>>>>> interpret these. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Footnote 18 states: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 18 This forms part of a handshake protocol and may >> >> >>>>>>>>>>>>>> be an area where industry could harmonise without >> >> >>>>>>>>>>>>>> the need for an explicit requirement in the >regulations. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Regards >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Andy >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> *From:*paws-bounces@ietf.org >> >> >>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] *On Behalf Of >> >> >>>>>>>>>>>>>> *Gabor.Bajko@nokia.com *Sent:* 05 March 2012 19:46 >> >> >>>>>>>>>>>>>> *To:* paws@ietf.org *Subject:* [paws] WGLC for >> >> >>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> The authors of the use cases and requirements draft >> >> >>>>>>>>>>>>>> have just posted a new version of the draft and >> >> >>>>>>>>>>>>>> indicated that there are no unresolved >> >> >>>>>>>>>>>>>> comments/issues they are aware of. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Therefore, I'd like to initiate a WG Last Call for >> >> >>>>>>>>>>>>>> comments on >> >> >>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-paws >> >> >>>>>>>>>>>>>> - >> >> problem- >> >> >>>>> stmt-u >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> >>>>> seca >> >> >>>>>>>>>>>>>> ses-rqmts-03.txt >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Please review the draft and send your comments to >> >> >>>>>>>>>>>>>> the list by March 20th, 2012. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> If you review the draft and have no comments, send >> >> >>>>>>>>>>>>>> a note to the list that the draft is good as it is, >> >> >>>>>>>>>>>>>> we need these notes as much as we need the actual >> >> >>>>>>>>>>>>>> comments. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Thanks, Gabor >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> > >> >> > _______________________________________________ >> >> > paws mailing list >> >> > paws@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/paws >> >> > >> >> _______________________________________________ >> >> paws mailing list >> >> paws@ietf.org >> >> https://www.ietf.org/mailman/listinfo/paws >> >> >> >> _______________________________________________ >> >> paws mailing list >> >> paws@ietf.org >> >> https://www.ietf.org/mailman/listinfo/paws >> >_______________________________________________ >> >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 > >________________________________ > >*********************************************************************** >* >****************************************** >For more information visit www.ofcom.org.uk > >This email (and any attachments) is confidential and intended for the >use of the addressee only. > >If you have received this email in error please notify the originator >of the message and delete it from your system. > >This email has been scanned for viruses. However, you open any >attachments at your own risk. > >Any views expressed in this message are those of the individual sender >and do not represent the views or opinions of Ofcom unless expressly >stated otherwise. >*********************************************************************** >* >****************************************** >_______________________________________________ >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 Mar 9 06:23:31 2012 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 433D121F868C for ; Fri, 9 Mar 2012 06:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.841 X-Spam-Level: X-Spam-Status: No, score=-4.841 tagged_above=-999 required=5 tests=[AWL=-0.869, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4, 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 tY33oG85PxRf for ; Fri, 9 Mar 2012 06:23:28 -0800 (PST) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id ECBB821F868A for ; Fri, 9 Mar 2012 06:23:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1331303150; x=1646647822; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=8Efon0VWtIv1X/UkXlwtB zIdJKuREdAW98eZqpCPHcY=; b=MqvF0GpGRZHrdTHWmWC01zgWA44acn9hy/GNT 4R0hvgUEdvr+MSdyDxVzpGQ1lbGeaHZiOqOvq4UQYBKoX93nw== Received: from ([10.31.13.228]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.6557656; Fri, 09 Mar 2012 09:25:49 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Fri, 9 Mar 2012 09:23:16 -0500 From: "Rosen, Brian" To: Paul Lambert Date: Fri, 9 Mar 2012 09:23:15 -0500 Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting Thread-Index: Acz+ACskO8SUp+IDQpSvKz7avSwIag== Message-ID: <2D1F0F0C-F3B9-43ED-8195-0962DF863AC8@neustar.biz> References: , <7BAC95F5A7E67643AAFB2C31BEE662D0157A034B37@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D0157A034B37@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: kZQmupG84izg26BgJi/fMg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 09 Mar 2012 07:45:42 -0800 Cc: Reza Karimi , "paws@ietf.org" , "johnny.dixon@bt.com" , "presnick@qualcomm.com" Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 14:23:31 -0000 We are limited by our charter. As you can see by the discussion, even a mi= nor extension to report channels used in an ack is controversial. Adding = a whole new transaction would clearly, in my opinion, be beyond our charter= . Charter limitations are good, if frustrating. If we feel we made an err= or in the original charter, we can ask that it be changed, but it's best to= try to work within the charter, get that done, and then expand the scope o= f the work. Right at the moment, we're trying to accommodate the regulatory requirement= s of the UK within our initial charter. As such, I would like to see the s= implest way to do that and stay within the charter. Any further work could= be considered later when we accomplish our initial goals. Brian On Mar 8, 2012, at 9:15 PM, Paul Lambert wrote: > > > > > >> I have a question here. Is it really an acknowledgement or we would like >> to see a kind of notification message that includes channel, and other >> parameters? > > What if it's multiple channels? What happens if the device adapts and ch= anges between modulation technique or bandwidth? Does every change over th= e air need to be indicated to the GDB? > > This Channel acknowledgement does not seem useful and would limit real wo= rld behaviors (like channel and modulation adaptation). > > If viewed as a potential regulatory requirement - does this imply we need= to parameterize the protocol to have different behaviors in different regi= ons? > > Paul > > > >> >> Regards, >> _Subir >> >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >> Siew Yoon Tan >> Sent: Thursday, March 08, 2012 4:06 PM >> To: Zuniga, Juan Carlos; Basavaraj.Patil@nokia.com; >> gerald.chouinard@sympatico.ca; jmh@joelhalpern.com; >> scott.probasco@nokia.com >> Cc: paws@ietf.org; presnick@qualcomm.com; Reza Karimi; >> johnny.dixon@bt.com; chris.cheeseman@bt.com >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >> rqmts-03:channel reporting >> >> Dear All, >> >> Regarding Ofcom's requirement to have a return channel as part of the >> protocol between the WSD and WSDB, I would like to confirm to following >> sequence of messaging >> >> Channel request >> Channel response >> Channel acknowledgement >> >> which was raised in an earlier email to this list. >> >> Our view is that it would be beneficial to define the protocol between >> WSD and WSDB that supports this requirement even though how the >> information could be used is still subject to discussion in the UK. >> >> >> Best regards, >> >> Siew Yoon >> >> >> ________________________________________ >> From: paws-bounces@ietf.org [paws-bounces@ietf.org] on behalf of Zuniga, >> Juan Carlos [JuanCarlos.Zuniga@InterDigital.com] >> Sent: 08 March 2012 20:41 >> To: Basavaraj.Patil@nokia.com; gerald.chouinard@sympatico.ca; >> jmh@joelhalpern.com; scott.probasco@nokia.com >> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >> chris.cheeseman@bt.com >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >> rqmts-03:channel reporting >> >> Hi Raj, >> >> I was reusing the language used from Gerald (which I know is familiar to >> people working on IEEE 802 WS groups): >> >>>> [GC] You got it. This would be useless for spectrum regulators. One >>>> should realize that, from the spectrum regulator's point of view, the >>>> second and third messages could be iterated upon to optimize the >>>> spectrum use. >>>> Knowing >>>> what channels the systems in an area are using, the spectrum >>>> regulators and/or other entities such as those taking care of >>>> coexistence could use the database in near-real-time to iterate on >>>> the two last messages to reduce the range of channels that some >>>> systems may use once they know precisely what channels are being used >>>> in the area. The PAWS protocol would carry the information back and >>>> forth but would not be involved in such spectrum use optimization. >> >> Having said that, I have no issue sticking to the WSDB terminology. I >> like keeping things simple :) >> >> JC >> >>> -----Original Message----- >>> From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] >>> Sent: Thursday, March 08, 2012 3:33 PM >>> To: Zuniga, Juan Carlos; gerald.chouinard@sympatico.ca; >>> jmh@joelhalpern.com; scott.probasco@nokia.com >>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>> chris.cheeseman@bt.com >>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >>> rqmts-03:channel reporting >>> >>> >>> Hi JC, >>> >>> Where/why did the coexistence manager come into the picture? Your >>> comment about "communicating back to the WSDB/coexistence manager" may >>> result in further misunderstanding. If we simply stick to to WSDB I >>> think we are okay. >>> >>> -Raj >>> >>> On 3/8/12 2:25 PM, "ext Zuniga, Juan Carlos" >>> wrote: >>> >>>> So, from Gerald and Andy's comments, it seems like from the point of >>> view >>>> of (at least) two regulatory entities it is important for the >>>> protocol >>> to >>>> allow communicating back to the WSDB/coexistence manager the actual >>>> channel usage after the first query is made. >>>> >>>> This is to me a very clear requirement. >>>> >>>> The actual messages/IEs that would carry this information should be >>>> discussed as part of the solution document, and not the requirements. >>>> >>>> JC >>>> >>>>> -----Original Message----- >>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >>>>> Behalf >>> Of >>>>> Gerald Chouinard >>>>> Sent: Thursday, March 08, 2012 1:59 PM >>>>> To: 'Joel M. Halpern'; scott.probasco@nokia.com >>>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>>>> chris.cheeseman@bt.com >>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >>>>> rqmts-03:channel reporting >>>>> >>>>> Joel, Scott, >>>>> >>>>> Interesting discussion! See my comments in line below. >>>>> >>>>> Gerald >>>>> >>>>> -----Original Message----- >>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >>>>> Behalf >>> Of >>>>> Joel >>>>> M. Halpern >>>>> Sent: Thursday, 08 March, 2012 13:17 >>>>> To: scott.probasco@nokia.com >>>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>>>> chris.cheeseman@bt.com >>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >>>>> rqmts-03: >>>>> channel reporting >>>>> >>>>> So why won't the device simply say "I will use all of this?" >>>>> [GC] This would defeat the purpose of the acknowledgement message. >>>>> After all, that way it needs to do less work with the database. >>>>> And >>> it >>>>> can change frequencies when it wants. >>>>> Given that the stated goal of the Ofcom requriement was to be able >>> to >>>>> analyze interference effects, it seems that this will not actually >>> lead >>>>> to them getting what they want, even if it does comply with the >>>>> regulations. >>>>> [GC] You got it. This would be useless for spectrum regulators. >>>>> One should realize that, from the spectrum regulator's point of >>>>> view, the >>> second >>>>> and >>>>> third messages could be iterated upon to optimize the spectrum use. >>>>> Knowing >>>>> what channels the systems in an area are using, the spectrum >>> regulators >>>>> and/or other entities such as those taking care of coexistence >>>>> could use the database in near-real-time to iterate on the two last >>>>> messages to reduce the range of channels that some systems may use >>>>> once they know precisely what channels are being used in the area. >>>>> The PAWS protocol would carry >>> the >>>>> information back and forth but would not be involved in such >>> spectrum >>>>> use >>>>> optimization. >>>>> >>>>> Yours, >>>>> joel >>>>> >>>>> On 3/8/2012 1:09 PM, scott.probasco@nokia.com wrote: >>>>>> Hi Peter, >>>>>> >>>>>> Answers below. >>>>>> >>>>>> Kind Regards, >>>>>> Scott >>>>>> >>>>>> On 3/8/12 11:39 AM, "ext Peter Saint-Andre" >>>>> wrote: >>>>>> >>>>>>> Hi Scott, I have two clarifying questions: >>>>>>> >>>>>>> 1. Does the device know, when it receives the channel response, >>>>> which >>>>>>> channel it will actually use? >>>>>> Scott->This is all new and I am not aware of any existing >>>>> implementations. >>>>>> I would argue that the device must decide what channel(s) it will >>> use >>>>> when >>>>>> it receives the channel response. >>>>> [GC] Agree with Scott but this is only a portion of the >>> considerations. >>>>> If a >>>>> device was to operate on its own, this would be true but a >>>>> communication device usually implies at least 2 devices to >>>>> communicate. Hence, the choice of the channel to be used will need >>>>> to be negotiated between the two devices before a choice can be >>>>> made. The chosen channel will belong to the >>> set >>>>> of >>>>> available channels that is common to both devices. Remember that >>> some >>>>> channels may be available at one device and not at the other >>>>> because >>> of >>>>> their geolocation or other reason. Extending this concept to a star >>>>> network topology, the channel that will be selected by this network >>>>> will >>> have >>>>> to >>>>> belong to the set of channels that are available to all devices. >>> Each >>>>> device >>>>> will not be able to decide by itself which channel it wants to use. >>>>> >>>>> This is why in such a star topology, it makes sense that the slave >>>>> devices to a base station or access point be represented by the >>>>> base station acting as the master on their behalf to query the >>>>> database and receive the list of available channels (and/or maximum >>>>> EIRP per channel). It is then the responsibility of the base >>>>> station to identify the set of available channels that is common >>>>> for itself and all its slaves to decide on the >>> channel >>>>> that >>>>> the network will use. As you can see, in this case, there is no >>>>> need for each slave to receive its list of available channels. On >>>>> its own, it would not know what to do with it. The only thing that >>>>> needs to be sent >>> from >>>>> the >>>>> master device to its slaves is the resulting operating channel. >>>>> >>>>> I a more sophisticated operation, the master device may add one or >>>>> a few backup channels extracted from the common set of available >>>>> channel >>> to >>>>> the >>>>> message going to its slave so that if a change in channel >>> availability >>>>> occurs, an instantaneous switch to the next backup channel can be >>> made >>>>> without any further signaling, thus providing for a channel switch >>> that >>>>> is >>>>> transparent to the user. It is the scheme that has been included in >>> the >>>>> IEEE >>>>> 802.22-2011 Standard. This is why I don't believe that PAWS should >>> get >>>>> involved in defining this signaling between the base station and >>>>> its slaves devices. >>>>>>> >>>>>>> 2. If the device then uses another channel or a different >>> channel, >>>>> does >>>>>>> it need to report that change to the database? >>>>>> Scott->My interpretation of section 3.18 is that the device can >>> only >>>>>> transmit within the upper& lower frequencies returned in the >>>>>> acknowledgment. I do not (quickly) find any reference in the >>>>> requirements >>>>>> to changing channels. Thus operationally it could be that the >>> channel >>>>>> request process must be repeated before the device can use a >>>>> different >>>>>> channel (frequencies). >>>>> [GC] If the process involves 2 messages, then, the device and its >>>>> associated devices could change channels at will as long as all >>>>> these channels belong to the set of available channel. However, if >>>>> the third message is added, it would make sense that the master >>>>> device reports to the database any channel change that would occur >>>>> to the database, otherwise, the status of >>> the >>>>> spectrum occupation would be wrong at any moment and would be >>> useless >>>>> for >>>>> the purpose of any spectrum usage optimization such as coexistence. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> Peter >>>>>>> >>>>>>> On 3/8/12 10:17 AM, scott.probasco@nokia.com wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> The point from Brian is very relevant: >>>>>>>> >>>>>>>> Channel request >>>>>>>> Channel response >>>>>>>> Channel acknowledgement >>>>>>>> >>>>>>>> What Ofcom does with the information in the acknowledgement >>>>>>>> does >>>>> not >>>>>>>> matter. As the regulator in UK, they write rules that must be >>>>> followed >>>>>>>> in >>>>>>>> order to operate a whitespace radio in the UK. I believe the >>> scope >>>>> of >>>>>>>> the >>>>>>>> WG must be focused on a working solution. If this is simple >>> channel >>>>>>>> request& response in one regulator's domain, PAWS can support >>>>> this. If >>>>>>>> it >>>>>>>> means a channel request, response and acknowledgement in >>>>>>>> another regulator's domain, PAWS can support this. As a >>>>>>>> participating >>>>> member of >>>>>>>> the work group, I believe the scope should be basic working >>>>> solution, >>>>>>>> not >>>>>>>> limited to a specific number of messages. >>>>>>>> >>>>>>>> Kind Regards, >>>>>>>> Scott >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 3/8/12 11:11 AM, "ext Zuniga, Juan Carlos" >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Peter, Nancy, >>>>>>>>> >>>>>>>>> I agree should design a protocol with the best of our current >>>>>>>>> knowledge, and that should be accounting for all the known >>>>>>>>> regulations at >>>>> present >>>>>>>>> time. We should not limit the scope with the purpose of >>> designing >>>>> a >>>>>>>>> protocol 'faster'. Our goal is not only to design a WSDB >>> protocol. >>>>> Our >>>>>>>>> goal is to design a WSDB protocol that is USEFUL to the >>> community. >>>>>>>>> >>>>>>>>> The charter does state that >>>>>>>>> >>>>>>>>> "...the group should also reach out to other potential >>>>>>>>> "customers" for a white space database access method and >>> consider >>>>> input >>>>>>>>> from regulatory entities that are involved in the >>>>>>>>> specification >>> of >>>>> the >>>>>>>>> rules for secondary use of spectrum in specific radio bands. " >>>>>>>>> >>>>>>>>> I think that is exactly what we are doing now. >>>>>>>>> >>>>>>>>> Regarding whether the types of requirements belong to #1 or >>>>>>>>> #2, >>> I >>>>>>>>> believe >>>>>>>>> it is more of #1 type, as the information to be exchanged >>>>>>>>> would >>> be >>>>>>>>> known >>>>>>>>> after the initial query/response. >>>>>>>>> >>>>>>>>> If we know it today, I see no reason why we should not work on >>> it >>>>> in >>>>>>>>> the >>>>>>>>> first phase of the work. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Juan Carlos >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >>>>> Behalf >>>>>>>>>> Of >>>>>>>>>> Peter Saint-Andre >>>>>>>>>> Sent: Thursday, March 08, 2012 11:59 AM >>>>>>>>>> To: Nancy Bravin >>>>>>>>>> Cc: paws@ietf.org; johnny.dixon@bt.com; >>> chris.cheeseman@bt.com; >>>>> Pete >>>>>>>>>> Resnick >>>>>>>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- >>>>> usecases- >>>>>>>>>> rqmts-03: channel reporting >>>>>>>>>> >>>>>>>>>> Hi Nancy, >>>>>>>>>> >>>>>>>>>> You are absolutely right that different locales will have >>>>> different >>>>>>>>>> rules and requirements. We need to understand those, and work >>> to >>>>>>>>>> address >>>>>>>>>> them if possible (although we don't necessarily need to >>> address >>>>> them >>>>>>>>>> all >>>>>>>>>> at the same time). I see several kinds of requirements: >>>>>>>>>> >>>>>>>>>> 1. Some requirements might lead to features beyond the >>>>> query/response >>>>>>>>>> protocol we've envisioned so far. One example might be real- >>> time >>>>>>>>>> reporting about the channels that a device is actually using. >>> In >>>>> my >>>>>>>>>> opinion, it would be best to handle those in the next phase >>>>>>>>>> of >>>>> work, >>>>>>>>>> because as far as I can see they are outside the scope of our >>>>> charter. >>>>>>>>>> >>>>>>>>>> 2. Some requirements might be handled through by defining >>>>> additional >>>>>>>>>> fields that can be included in the query or response. We >>>>> definitely >>>>>>>>>> planned for that when working on the charter with the IESG: >>>>>>>>>> >>>>>>>>>> In addition, the particular >>>>>>>>>> data exchanged between a device and a database might >>>>>>>>>> depend >>> on >>>>> the >>>>>>>>>> ranges of radio spectrum that are to be used, the >>> requirements >>>>> of >>>>>>>>>> the >>>>>>>>>> database operators and their governing regulations, and >>> other >>>>>>>>>> factors. >>>>>>>>>> Therefore, the database access method and the >>> query/response >>>>> data >>>>>>>>>> formats that are exchanged using that method need to be >>>>> designed >>>>> for >>>>>>>>>> extensibility rather than being tied to any specific >>> spectrum, >>>>>>>>>> country, or phy/mac/air interface. >>>>>>>>>> >>>>>>>>>> It's unclear to me right now if the Ofcom requirement fits >>> into >>>>> #1 or >>>>>>>>>> #2, which is why we're having this discussion. :) >>>>>>>>>> >>>>>>>>>> Peter >>>>>>>>>> >>>>>>>>>> On 3/7/12 8:17 PM, Nancy Bravin wrote: >>>>>>>>>>> Peter and all, >>>>>>>>>>> >>>>>>>>>>> I agree that it is important to revisit now, so that in the >>>>> future, >>>>>>>>>>> it will be easy to align things in their proper place. Every >>>>> country >>>>>>>>>>> may have different regulations, spectrum, policy and what >>>>>>>>>>> responsibility is in the domain of the system, and what >>>>>>>>>>> comes >>>>> under >>>>>>>>>>> the PAWS charter is important. Maybe some separation might >>> be >>>>>>>>>>> possible, and dividing and clarifying issues now will help >>>>>>>>>>> in >>>>> the >>>>>>>>>>> future. Certainly it seems that the FCC may change some >>> rules, >>>>> and >>>>>>>>>>> we know that Ofcom is not yet finished with their >>> regulations. >>>>> Canada >>>>>>>>>>> has their own, and other countries are working on this as >>> well. >>>>> Just >>>>>>>>>>> a thought...Sharing is a realistic goal...as is off >>> loading... >>>>> Or you >>>>>>>>>>> slim line and every 6 months decide what to incorporate in >>> the >>>>>>>>>>> protocol based on new information, new ideas, new innovation >>> new >>>>>>>>>>> regulations and maybe spend more time than you could if >>>>> addressed >>>>>>>>>>> now. >>>>>>>>>>> >>>>>>>>>>> That way you leave the door open and outside of referencing >>> what >>>>> is >>>>>>>>>>> known today, by referencing regulations i.e. Ofcom, FCC, >>>>> Industry >>>>>>>>>>> Canada etc as of XX-XX-XXXX date. Out of scope not something >>> we >>>>> know >>>>>>>>>>> enough about to say at this point, In my opinion. >>>>>>>>>>> >>>>>>>>>>> My 2 cents.. >>>>>>>>>>> >>>>>>>>>>> Sincerely, Nancy >>>>>>>>>>> >>>>>>>>>>> On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> As your responsible Area Director (until March 28, when >>>>>>>>>>>> Pete Resnick will take over from me), I have reviewed this >>> thread. >>>>>>>>>>>> >>>>>>>>>>>> In my opinion (I am happy to be proven wrong), this new >>>>> requirement >>>>>>>>>>>> goes beyond what the charter defined as the scope of this >>>>> working >>>>>>>>>>>> group, which was to enable a device to discover the white >>> space >>>>>>>>>>>> available to it in its current location. Reporting usage >>> back >>>>> to >>>>>>>>>>>> the database is simply not mentioned in the charter. >>>>>>>>>>>> >>>>>>>>>>>> Earlier in this thread, Andy Sago wrote: >>>>>>>>>>>> >>>>>>>>>>>> There's no language I can find in the charter that >>> explicitly >>>>> puts >>>>>>>>>>>> this out of scope. >>>>>>>>>>>> >>>>>>>>>>>> An IETF charter defines what the working group shall work >>> on. >>>>> Many >>>>>>>>>>>> interesting features could be developed here. However, it >>>>>>>>>>>> is >>>>> not >>>>>>>>>>>> the job of the charter to mention explicitly that each of >>> those >>>>>>>>>>>> interesting features is out of scope. >>>>>>>>>>>> >>>>>>>>>>>> The charter does say: >>>>>>>>>>>> >>>>>>>>>>>> Once the device learns of the available white space (e.g., >>> in a >>>>> TV >>>>>>>>>>>> white space implementation, the list of available channels >>> at >>>>> that >>>>>>>>>>>> location), it can then select one of the bands from the >>>>>>>>>>>> list >>>>> and >>>>>>>>>>>> begin to transmit and receive on the selected band. >>>>>>>>>>>> >>>>>>>>>>>> This text might have assumed that no further communication >>> or >>>>>>>>>>>> authorization was required in order to select one of the >>> bands >>>>> from >>>>>>>>>>>> the list and then transmit/receive. Perhaps that assumption >>> was >>>>>>>>>>>> mistaken. If so, it would be good to have a discussion >>>>>>>>>>>> about >>>>> that, >>>>>>>>>>>> so we can determine if we need to revisit the assumptions >>>>>>>>>>>> we >>>>> made >>>>>>>>>>>> early on. If in fact we made some faulty or limited >>>>> assumptions, >>>>>>>>>>>> then let's get that out in the open. >>>>>>>>>>>> >>>>>>>>>>>> Peter >>>>>>>>>>>> >>>>>>>>>>>> On 3/7/12 9:40 AM, Rosen, Brian wrote: >>>>>>>>>>>>> I'd also suggest that >>> our >>>>>>>>>>>>> charter limitation is really support for sharing of >>> whitespace >>>>> by >>>>>>>>>>>>> whitespace devices. Reporting what you use is not >>>>>>>>>>>>> sharing, >>>>> it's >>>>>>>>>>>>> just data gathering. >>>>>>>>>>>>> >>>>>>>>>>>>> The point of excluding sharing was to eliminate the >>>>> complexities >>>>>>>>>>>>> of what constituted fairness, and what kinds of >>> communication >>>>>>>>>>>>> might be needed between databases, where more than one >>> could >>>>>>>>>>>>> supply available whitespace in a band. This doesn't have >>> any >>>>> of >>>>>>>>>>>>> those issues, As long as it's just sending information, I >>>>> don't >>>>>>>>>>>>> have a problem. Once the database is supposed to do >>> anything >>>>>>>>>>>>> with it that involves changing what spectrum it reports, >>> then >>>>> I >>>>>>>>>>>>> think we cross the line. >>>>>>>>>>>>> >>>>>>>>>>>>> Brian >>>>>>>>>>>>> >>>>>>>>>>>>> On Mar 6, 2012, at 12:28 PM, >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Joel >>>>>>>>>>>>>> >>>>>>>>>>>>>> Indeed, the regulator has not described the process or >>>>> provided >>>>>>>>>>>>>> a flow diagram, so there may be some wrinkles, but we >>>>>>>>>>>>>> need >>> to >>>>>>>>>>>>>> provide for their intent. To answer your question, the >>>>> channels >>>>>>>>>>>>>> that the master will use are sent in a separate message >>>>>>>>>>>>>> (described in P.12 ter), that occurs after the master >>>>> receives >>>>>>>>>>>>>> the response to its channel request, but before the >>>>>>>>>>>>>> master >>>>> can >>>>>>>>>>>>>> transmit. At this point, it knows what channels are >>>>> available, >>>>>>>>>>>>>> and which one it will use. As far as the slaves are >>>>> concerned, >>>>>>>>>>>>>> as they associate, the master will need to gather their >>>>> details >>>>>>>>>>>>>> and send further channel usage messages to the database >>>>>>>>>>>>>> on their behalf. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards >>>>>>>>>>>>>> >>>>>>>>>>>>>> Andy >>>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- From: paws-bounces@ietf.org >>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] On Behalf Of Joel M. >>> Halpern >>>>>>>>>>>>>> Sent: 06 March 2012 17:05 To: scott.probasco@nokia.com >> Cc: >>>>>>>>>>>>>> paws@ietf.org; Cheeseman,CJ,Chris,COD R; >>> Dixon,JS,Johnny,COD >>>>> R >>>>>>>>>>>>>> Subject: Re: [paws] WGLC for >>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel >>>>>>>>>>>>>> reporting >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ahh. I think I see where the request and my >>>>>>>>>>>>>> understanding divurge. If the idea here is that the >>>>>>>>>>>>>> master must provide, >>> in >>>>>>>>>>>>>> the request, an indication of what channels it expects to >>>>> use, >>>>>>>>>>>>>> I can at least understand that. I will return to >>> technical >>>>>>>>>>>>>> concerns in a moment. >>>>>>>>>>>>>> >>>>>>>>>>>>>> However, when you say "provide channel usage information, >>> in >>>>>>>>>>>>>> order to evaluate interference", what that says to me is >>>>>>>>>>>>>> providing, during operation, information as to what >>> channels >>>>>>>>>>>>>> are being used, and at what power levels. That is what >>> would >>>>>>>>>>>>>> be needed to analyze actual interference effects. And >>>>>>>>>>>>>> that >>> is >>>>>>>>>>>>>> out of scope as I understand our scope. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I do see a technical difficulty with having the master >>>>> provide, >>>>>>>>>>>>>> as part of either registering or requesting spectrum >>>>>>>>>>>>>> information, what channels it intends to use. It doesn;t >>>>> know >>>>>>>>>>>>>> what channels it intends to use. It intends to use some >>>>> number >>>>>>>>>>>>>> of available channels. It will figure out which ones >>>>>>>>>>>>>> when >>> it >>>>>>>>>>>>>> is told what is available. How can it send that >>> information >>>>> in >>>>>>>>>>>>>> the request? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There is a similarity here with device ID. In context of >>>>> PAWS >>>>>>>>>>>>>>> we are not concerned with why a device ID is required by >>> a >>>>>>>>>>>>>>> regulator, we accept it is a requirement from a >>>>>>>>>>>>>>> regulator >>>>> and >>>>>>>>>>>>>>> include it to the protocol. Ofcom identifies in 3.18& >>> 3.19 >>>>>>>>>>>>>>> that channel usage information is required and thus we >>> need >>>>>>>>>>>>>>> to include this information. Since the master must >>> provide >>>>>>>>>>>>>>> this information prior to transmitting, PAWS will not >>>>>>>>>>>>>>> function in the UK without this information and thus I >>>>>>>>>>>>>>> believe channel usage information is integral to the >>> channel >>>>>>>>>>>>>>> request& response messaging. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Kind Regards, Scott >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 3/6/12 10:30 AM, "ext Joel M. >>>>>>>>>>>>>>> Halpern" wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I would draw a distinction. Ofcom regulations about >>>>>>>>>>>>>>>> whitespace requests are very much relevant. Ofcom >>>>>>>>>>>>>>>> regulations about notification of dynamic behavior >>> (which >>>>>>>>>>>>>>>> spectrum is being used) are not in scope as I >>>>>>>>>>>>>>>> understand the earlier discussions, particularly the >>>>>>>>>>>>>>>> chartering discussions. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The ofcom requirements are very much relevant to the >>>>>>>>>>>>>>>>> scope of the PAWS WG. The only other regulatory >>>>>>>>>>>>>>>>> requirements that we have today is the FCC. Ofcom >>>>>>>>>>>>>>>>> requirements are a good addition to the set. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -Raj >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 3/6/12 10:03 AM, "ext >>>>>>>>>>>>>>>>> andy.sago@bt.com" wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi Joel >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> There's no language I can find in the charter that >>>>>>>>>>>>>>>>>> explicitly puts this out of scope. On the other hand, >>>>>>>>>>>>>>>>>> the charter says that the group will "consider input >>>>>>>>>>>>>>>>>> from regulatory entities", and this is one of the >>>>>>>>>>>>>>>>>> requirements from Ofcom that they have just >> published. >>>>>>>>>>>>>>>>>> The protocol will be worthless for the UK if it omits >>>>>>>>>>>>>>>>>> some requirements. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Andy >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -----Original Message----- From: Joel M. Halpern >>>>>>>>>>>>>>>>>> [mailto:jmh@joelhalpern.com] Sent: 06 March 2012 >>>>>>>>>>>>>>>>>> 15:53 >>>>>>>>>>>>>>>>>> To: Sago,AJ,Andy,COD R Cc: paws@ietf.org; >>>>>>>>>>>>>>>>>> Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for >>>>>>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: >>> channel >>>>>>>>>>>>>>>>>> reporting >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> As I understand, the information you are asking for >>>>>>>>>>>>>>>>>> is explicitly out of scope for the working group. >>>>>>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >>>>>>>>>>>>>>>>>>> All >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Comparing the draft with the Ofcom requirements at >>>>>>>>>>>>>>>>>>> http://www.cept.org/Documents/se- >>>>>>>>>> 43/4161/SE43(12)Info03_Draft-UK-r >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>> egul >>>>>>>>>>>>>>>>>>> atory-requirements-for-white-space-devices-in-the- >>> UHF- >>>>> TV- >>>>>>>>>> band, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>> I believe the WG draft is deficient in the area of reporting >>>>>>>>>>>>>>>>>>> frequencies and powers actually used by masters and >>>>>>>>>>>>>>>>>>> slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom >>>>>>>>>>>>>>>>>>> intends to collect this data to assesses the impact >>>>>>>>>>>>>>>>>>> of aggregate interference into other services. It >>>>>>>>>>>>>>>>>>> would also provide usage information (frequency in >>>>>>>>>>>>>>>>>>> use) that would inform the operation of a kill >>>>>>>>>>>>>>>>>>> switch capability. I suggest this deficiency can be >>>>>>>>>>>>>>>>>>> remedied with the following changes: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> New P requirements (probably best placed following >>>>>>>>>>>>>>>>>>> P.12): >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> P.12bis: The protocol MUST support a channel usage >>>>>>>>>>>>>>>>>>> message from the slave device to the master device. >>>>>>>>>>>>>>>>>>> The channel usage message MUST include parameters as >>>>>>>>>>>>>>>>>>> required by local regulatory requirement. These >>>>>>>>>>>>>>>>>>> parameters MAY include device ID, manufacturer's >>>>>>>>>>>>>>>>>>> serial number, channel usage and power level >>>>>>>>>>>>>>>>>>> information. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> P.12ter: The protocol MUST support a channel usage >>>>>>>>>>>>>>>>>>> message from the master device to the database. The >>>>>>>>>>>>>>>>>>> channel usage message MUST include parameters as >>>>>>>>>>>>>>>>>>> required by local regulatory requirement for the >>>>>>>>>>>>>>>>>>> master and its associated slaves. These parameters >>>>>>>>>>>>>>>>>>> MAY include device ID, manufacturer's serial number, >>>>>>>>>>>>>>>>>>> channel usage and power level information. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> P.12qua: The protocol MUST support a channel usage >>>>>>>>>>>>>>>>>>> message acknowledgement. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> New O requirements (probably best placed following >>>>>>>>>>>>>>>>>>> O13): >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> O.13bis: According to local regulatory policy, >>>>>>>>>>>>>>>>>>> after connecting to a master device's radio network >>>>>>>>>>>>>>>>>>> a slave device MAY inform the master device of the >>>>>>>>>>>>>>>>>>> actual channel usage. The slave MUST include >>>>>>>>>>>>>>>>>>> parameters required by local regulatory policy, e.g. >>>>>>>>>>>>>>>>>>> device ID, manufacturer's serial number, channel >>>>>>>>>>>>>>>>>>> usage and power level information. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> O.13ter: According to local regulatory policy, a >>>>>>>>>>>>>>>>>>> master device MAY inform the database of the actual >>>>>>>>>>>>>>>>>>> channel usage of the master and its slaves. The >>>>>>>>>>>>>>>>>>> master MUST include parameters required by local >>>>>>>>>>>>>>>>>>> regulatory policy, e.g. device ID, manufacturer's >>>>>>>>>>>>>>>>>>> serial number, channel usage and power level >>>>>>>>>>>>>>>>>>> information of the master and its slaves. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> New steps could be introduced into one or more use >>>>>>>>>>>>>>>>>>> cases to cover these Ofcom requirements, e.g. new >>>>>>>>>>>>>>>>>>> steps 6bis and 9bis in the hotspot use case at >>>>>>>>>>>>>>>>>>> 4.2.1: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 6bis. Prior to initiating transmission, if required >>>>>>>>>>>>>>>>>>> by local regulation, the master/AP informs the >>>>>>>>>>>>>>>>>>> database of the channel and power level it has >>>>>>>>>>>>>>>>>>> chosen. This is repeated for each slave that >>>>>>>>>>>>>>>>>>> associated with the master. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 9bis. Prior to initiating transmission, if required >>>>>>>>>>>>>>>>>>> by local regulation, the slave informs the master/AP >>>>>>>>>>>>>>>>>>> of the channel and power level it has chosen, and >>>>>>>>>>>>>>>>>>> the master/AP relays this information to the >> database. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> - end of new text - >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> For information, for those not accessing the url in >>>>>>>>>>>>>>>>>>> the first paragraph of this email, the full Ofcom >>>>>>>>>>>>>>>>>>> requirements leading to this new PAWS text are as >>>>>>>>>>>>>>>>>>> follows: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 3.18 After receiving instructions from a WSDB in >>>>>>>>>>>>>>>>>>> relation to the maximum permitted EIRPs over the DTT >>>>>>>>>>>>>>>>>>> channels, and prior to initiating transmissions >>>>>>>>>>>>>>>>>>> within the UHF TV band, a master WSD must >>>>>>>>>>>>>>>>>>> communicate to the WSDB the following information: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 3.18.1 The lower and upper frequency boundaries^13 >>>>>>>>>>>>>>>>>>> of the in-block emissions of the master WSD, and >>>>>>>>>>>>>>>>>>> those of the in-block emissions of its associated >>>>>>>>>>>>>>>>>>> slaves. A lower frequency will be specified as (470 >>>>>>>>>>>>>>>>>>> + 8k + >>>>>>>>>>>>>>>>>>> 0.2n) MHz, with the corresponding upper frequency >>>>>>>>>>>>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3?4 k >> 3?4 >>>>>>>>>>>>>>>>>>> 39, 0 3?4 n 3?4 39, 1 3?4 m 3?4 40, and n< m. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 3.18.2 The maximum in-block EIRP spectral densities >>>>>>>>>>>>>>>>>>> (in dBm/(0.2 MHz)) that the master WSD, and its >>>>>>>>>>>>>>>>>>> associated slaves, actually radiate between each >>>>>>>>>>>>>>>>>>> reported lower frequency boundary and its >>>>>>>>>>>>>>>>>>> corresponding upper frequency boundary. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Footnote 13 states: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The use of upper and lower frequency boundaries >>>>>>>>>>>>>>>>>>> (defined over a 200 kHz raster) allows a WSDB to >>>>>>>>>>>>>>>>>>> collect more granular information with regards to >>>>>>>>>>>>>>>>>>> the usage of the frequency resource by narrowband >>>>>>>>>>>>>>>>>>> WSD technologies. The upper and lower frequencies of >>>>>>>>>>>>>>>>>>> a boundary pair do not straddle a DTT channel >> boundary. >>>>>>>>>>>>>>>>>>> Note that a WSD may transmit over multiple, >>>>>>>>>>>>>>>>>>> non-contiguous, whole DTT channels or fractions of >>>>>>>>>>>>>>>>>>> DTT channels. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 3.19 A master WSD must be able to receive the >>>>>>>>>>>>>>>>>>> following information^14 from a WSDB: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in the >>>>>>>>>>>>>>>>>>> context of 3.18, that the reported information on >>>>>>>>>>>>>>>>>>> the DTT channels and EIRP spectral densities >>>>>>>>>>>>>>>>>>> actually used by the master and slave WSDs were >>>>>>>>>>>>>>>>>>> received successfully by the WSDB^18 ]. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Footnote 14 states: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 14 While the communication of some of this >>>>>>>>>>>>>>>>>>> information from a WSDB to a master WSD is optional, >>>>>>>>>>>>>>>>>>> master WSDs must be able to receive and interpret >>>>>>>>>>>>>>>>>>> these. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Footnote 18 states: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 18 This forms part of a handshake protocol and may >>>>>>>>>>>>>>>>>>> be an area where industry could harmonise without >>>>>>>>>>>>>>>>>>> the need for an explicit requirement in the >> regulations. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Andy >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> *From:*paws-bounces@ietf.org >>>>>>>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] *On Behalf Of >>>>>>>>>>>>>>>>>>> *Gabor.Bajko@nokia.com *Sent:* 05 March 2012 19:46 >>>>>>>>>>>>>>>>>>> *To:* paws@ietf.org *Subject:* [paws] WGLC for >>>>>>>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The authors of the use cases and requirements draft >>>>>>>>>>>>>>>>>>> have just posted a new version of the draft and >>>>>>>>>>>>>>>>>>> indicated that there are no unresolved >>>>>>>>>>>>>>>>>>> comments/issues they are aware of. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Therefore, I'd like to initiate a WG Last Call for >>>>>>>>>>>>>>>>>>> comments on >>>>>>>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-paws- >>>>> problem- >>>>>>>>>> stmt-u >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>> seca >>>>>>>>>>>>>>>>>>> ses-rqmts-03.txt >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Please review the draft and send your comments to >>>>>>>>>>>>>>>>>>> the list by March 20th, 2012. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> If you review the draft and have no comments, send a >>>>>>>>>>>>>>>>>>> note to the list that the draft is good as it is, we >>>>>>>>>>>>>>>>>>> need these notes as much as we need the actual >>>>>>>>>>>>>>>>>>> comments. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, Gabor >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> paws mailing list >>>>>> paws@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>> >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>>> >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>> _______________________________________________ >>>> 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 >> >> ________________________________ >> >> ************************************************************************ >> ****************************************** >> For more information visit www.ofcom.org.uk >> >> This email (and any attachments) is confidential and intended for the >> use of the addressee only. >> >> If you have received this email in error please notify the originator of >> the message and delete it from your system. >> >> This email has been scanned for viruses. However, you open any >> attachments at your own risk. >> >> Any views expressed in this message are those of the individual sender >> and do not represent the views or opinions of Ofcom unless expressly >> stated otherwise. >> ************************************************************************ >> ****************************************** >> _______________________________________________ >> 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 presnick@qualcomm.com Fri Mar 9 07:56:53 2012 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 0B5EA21F86AB for ; Fri, 9 Mar 2012 07:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.454 X-Spam-Level: X-Spam-Status: No, score=-106.454 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 KgXP+zSeTDoq for ; Fri, 9 Mar 2012 07:56:52 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 09E0721F8573 for ; Fri, 9 Mar 2012 07:56:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1331308612; x=1362844612; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F5A2841.4030506@qualcomm.com>|Date:=20Fr i,=209=20Mar=202012=2009:56:49=20-0600|From:=20Pete=20Res nick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Gerald=20Chouinard=20|CC:=20"'Rosen,=20Brian'"=20,=20'Paul=20Lambert'=0D=0A=09,=20|Subject:=20Re:=20[paws]=09WGL C=09fordraft-ietf-paws-problem-stmt-usecases-rqmts-03:cha nnel=0D=0A=20reporting|References:=20=09,=09=09=09=09<7BAC95F5A7E67643AAFB2C31BEE662D0157A034B37@SC-V EXCH2.marvell.com>=09<2D1F0F0C-F3B9-43ED-8195-0962DF863AC 8@neustar.biz>=20|In-Reply-To:=20|Content-Type:=20text/plain=3B=20charset=3D"IS O-8859-1"=3B=20format=3Dflowed|Content-Transfer-Encoding: =207bit|X-Originating-IP:=20[172.30.48.1]; bh=k692SXvry19n6LwfiPeM9u+fNQViPIR8vWBPvU5S55E=; b=LnwiGsr0ML5BKMbVgrwKSDqcxdY2JekJ+SI4hf9b6/ig98Ny+UFdried 6l392rZVyOdjWyGHcFNKY6GW9NVDtfdrnoxv6jQkqZNlngZogi/MW5Fzb TVVJ+WEdN8Lm1epPxDsMK/xttPPpUpbH0/l/yokk1OKHvNEX8rzF0vy5j Q=; X-IronPort-AV: E=McAfee;i="5400,1158,6643"; a="171030512" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP; 09 Mar 2012 07:56:51 -0800 X-IronPort-AV: E=Sophos;i="4.73,558,1325491200"; d="scan'208";a="175588265" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 09 Mar 2012 07:56:51 -0800 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 9 Mar 2012 07:56:50 -0800 Message-ID: <4F5A2841.4030506@qualcomm.com> Date: Fri, 9 Mar 2012 09:56:49 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Gerald Chouinard References: , <7BAC95F5A7E67643AAFB2C31BEE662D0157A034B37@SC-VEXCH2.marvell.com> <2D1F0F0C-F3B9-43ED-8195-0962DF863AC8@neustar.biz> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: paws@ietf.org Subject: Re: [paws] WGLC fordraft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 15:56:53 -0000 On 3/9/12 8:58 AM, Gerald Chouinard wrote: > Agreed. This acknowledgement should be kept to its simplest form. > > My guess is that confirming back to the WSDB the channel(s) that is(are) > being used by the device and the maximum EIRP that will be used (per > channel) should be sufficient for the purpose of interference > considerations. Folks, Fair warning as your incoming AD, but also as a current AD who thought he understood what work this group was chartered to do: The group is chartered to do (1) database discovery, (2) database access, (3) data formats for that database access, and (4) security for that database access. The charter also describes what that database access is like: (a) provide geolocation and other info to query the database, and (b) receive the whitespace that can be used. Insofar as what this charter only allows for protocol that is about database discovery and database access, the so-called "acknowledgment" you all are talking is either writing back to the database (if the "acknowledgment" data gets saved into the same database) or is non-database-access protocol to talk to a third party. In either case, I, as an AD, would be extremely surprised to find out either that the database was writeable by the client (that was not my understanding of the query described in the "rough outline of the protocol" section of the charter) or that there was to be additional protocol that sent data from the client to a third party. There is a whole new set of considerations on such protocol (e.g., Does the information sent back from the client need TTL values? Is there a renewal process on the data after some time? What if there are multiple clients accessing at the same time and they choose the same value? Can the response get back an error and the client has to choose something different?). If you wish to take on this work, you need to go back to the IESG and re-charter. That's fine: If the WG feels that this piece of protocol is required in order to make the rest of the protocol at all useful, now is the time to tell the IESG that and figure out how to write it into the charter. But doing this work without a charter change is going to cause heartache later. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From jmh@joelhalpern.com Fri Mar 9 08:00:27 2012 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 BEA3C21F8716 for ; Fri, 9 Mar 2012 08:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.092 X-Spam-Level: X-Spam-Status: No, score=-101.092 tagged_above=-999 required=5 tests=[AWL=-0.854, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, 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 UibL9C8wsbEF for ; Fri, 9 Mar 2012 08:00:00 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0605B21F86AB for ; Fri, 9 Mar 2012 07:59:58 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id B2515CD6C7 for ; Fri, 9 Mar 2012 07:59:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 55D091C01EED; Fri, 9 Mar 2012 07:59:57 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.100] (pool-71-161-51-182.clppva.btas.verizon.net [71.161.51.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id AF3F31C01EEC; Fri, 9 Mar 2012 07:59:52 -0800 (PST) Message-ID: <4F5A28F7.4070905@joelhalpern.com> Date: Fri, 09 Mar 2012 10:59:51 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: chris.cheeseman@bt.com References: , <7BAC95F5A7E67643AAFB2C31BEE662D0157A034B37@SC-VEXCH2.marvell.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 09 Mar 2012 08:01:03 -0800 Cc: Reza.Karimi@ofcom.org.uk, paws@ietf.org, presnick@qualcomm.com, johnny.dixon@bt.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 16:00:27 -0000 I am having trouble connecting the goal of the requirement, the expected protocol behavior, and the expected real-world operation. Lets keep it simple. A master, connected by wired internet to the World. A set of slaves who want to use whitespace to talk to the master. All within a small physical space. All within the the time limit of whatever answer the master gets from the database. The Ofcom requirement is described as being important for understanding interference effects. Therefore, presumably, it needs to relate to actual spectrum usage. The stated protocol behavior is that the master would reply to the shitespace database with an ack indicating what it expects to use, at what power level. The way folks are writing this, I believe the intention is "respond once". As I understand such master / slave behavior (and I am by no means a radio expert), the actual usage of spectrum, within the whitespace band, will depend upon how many slaves are active, and possibly on what they are doing. If the actual usage is going to depend upon the slave device population / behavior, then the only answer the master can correctly provide is "I will use all of the whitespace you have identified, with the highest power I might use. Such an answer is a valid answer in terms of protocol and in terms of the stated regulatory requirements. However, it is utterly useless in terms of the stated goal. As an engineer, I am very uncomfortable designing a protocol messaging exchange which I know will not meet the end-users needs. Note1: If I have mischaracterized ro misunderstood what folks ahve explained, I apologize. Note2: If instead the intention is for the master to update the database every time it changes the spectrum usage pattern, then this is NOT an acknowledgment of the reply from the database. It is a dynamic behavior reporting requirement. Yours, Joel On 3/9/2012 6:36 AM, chris.cheeseman@bt.com wrote: > Hi > > My reading of the UK regulatory requirements that Ofcom has made available is that the Acknowledgement message that must be communicated back to the database from the white space device is simply the frequency range (or ranges) and maximum eirp density that the device intends to use (a subset of what it would have been offered by the database). I don't believe there is any intent to limit modulation schemes etc. as part of this exchange. This seems a relatively straightforward requirement and the PAWS protocol should accommodate this if it is to be relevant for the UK regulatory environment. > > Regards, > > Chris > > -----Original Message----- > From: Paul Lambert [mailto:paul@marvell.com] > Sent: 09 March 2012 02:15 > To: Das, Subir; 'Siew Yoon Tan'; Zuniga, Juan Carlos; Basavaraj.Patil@nokia.com; gerald.chouinard@sympatico.ca; jmh@joelhalpern.com; scott.probasco@nokia.com > Cc: paws@ietf.org; presnick@qualcomm.com; Reza Karimi; Dixon,JS,Johnny,COD R; Cheeseman,CJ,Chris,COD R > Subject: RE: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting > > > > > > >> I have a question here. Is it really an acknowledgement or we would >> like to see a kind of notification message that includes channel, and >> other parameters? > > What if it's multiple channels? What happens if the device adapts and changes between modulation technique or bandwidth? Does every change over the air need to be indicated to the GDB? > > This Channel acknowledgement does not seem useful and would limit real world behaviors (like channel and modulation adaptation). > > If viewed as a potential regulatory requirement - does this imply we need to parameterize the protocol to have different behaviors in different regions? > > Paul > > > >> >> Regards, >> _Subir >> >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >> Siew Yoon Tan >> Sent: Thursday, March 08, 2012 4:06 PM >> To: Zuniga, Juan Carlos; Basavaraj.Patil@nokia.com; >> gerald.chouinard@sympatico.ca; jmh@joelhalpern.com; >> scott.probasco@nokia.com >> Cc: paws@ietf.org; presnick@qualcomm.com; Reza Karimi; >> johnny.dixon@bt.com; chris.cheeseman@bt.com >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >> rqmts-03:channel reporting >> >> Dear All, >> >> Regarding Ofcom's requirement to have a return channel as part of the >> protocol between the WSD and WSDB, I would like to confirm to following >> sequence of messaging >> >> Channel request >> Channel response >> Channel acknowledgement >> >> which was raised in an earlier email to this list. >> >> Our view is that it would be beneficial to define the protocol between >> WSD and WSDB that supports this requirement even though how the >> information could be used is still subject to discussion in the UK. >> >> >> Best regards, >> >> Siew Yoon >> >> >> ________________________________________ >> From: paws-bounces@ietf.org [paws-bounces@ietf.org] on behalf of >> Zuniga, Juan Carlos [JuanCarlos.Zuniga@InterDigital.com] >> Sent: 08 March 2012 20:41 >> To: Basavaraj.Patil@nokia.com; gerald.chouinard@sympatico.ca; >> jmh@joelhalpern.com; scott.probasco@nokia.com >> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >> chris.cheeseman@bt.com >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >> rqmts-03:channel reporting >> >> Hi Raj, >> >> I was reusing the language used from Gerald (which I know is familiar >> to people working on IEEE 802 WS groups): >> >>>> [GC] You got it. This would be useless for spectrum regulators. One >>>> should realize that, from the spectrum regulator's point of view, >>>> the second and third messages could be iterated upon to optimize the >>>> spectrum use. >>>> Knowing >>>> what channels the systems in an area are using, the spectrum >>>> regulators and/or other entities such as those taking care of >>>> coexistence could use the database in near-real-time to iterate on >>>> the two last messages to reduce the range of channels that some >>>> systems may use once they know precisely what channels are being >>>> used in the area. The PAWS protocol would carry the information back >>>> and forth but would not be involved in such spectrum use optimization. >> >> Having said that, I have no issue sticking to the WSDB terminology. I >> like keeping things simple :) >> >> JC >> >>> -----Original Message----- >>> From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] >>> Sent: Thursday, March 08, 2012 3:33 PM >>> To: Zuniga, Juan Carlos; gerald.chouinard@sympatico.ca; >>> jmh@joelhalpern.com; scott.probasco@nokia.com >>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>> chris.cheeseman@bt.com >>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >>> rqmts-03:channel reporting >>> >>> >>> Hi JC, >>> >>> Where/why did the coexistence manager come into the picture? Your >>> comment about "communicating back to the WSDB/coexistence manager" >>> may result in further misunderstanding. If we simply stick to to WSDB >>> I think we are okay. >>> >>> -Raj >>> >>> On 3/8/12 2:25 PM, "ext Zuniga, Juan Carlos" >>> wrote: >>> >>>> So, from Gerald and Andy's comments, it seems like from the point of >>> view >>>> of (at least) two regulatory entities it is important for the >>>> protocol >>> to >>>> allow communicating back to the WSDB/coexistence manager the actual >>>> channel usage after the first query is made. >>>> >>>> This is to me a very clear requirement. >>>> >>>> The actual messages/IEs that would carry this information should be >>>> discussed as part of the solution document, and not the requirements. >>>> >>>> JC >>>> >>>>> -----Original Message----- >>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >>>>> Behalf >>> Of >>>>> Gerald Chouinard >>>>> Sent: Thursday, March 08, 2012 1:59 PM >>>>> To: 'Joel M. Halpern'; scott.probasco@nokia.com >>>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>>>> chris.cheeseman@bt.com >>>>> Subject: Re: [paws] WGLC for >>>>> draft-ietf-paws-problem-stmt-usecases- >>>>> rqmts-03:channel reporting >>>>> >>>>> Joel, Scott, >>>>> >>>>> Interesting discussion! See my comments in line below. >>>>> >>>>> Gerald >>>>> >>>>> -----Original Message----- >>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >>>>> Behalf >>> Of >>>>> Joel >>>>> M. Halpern >>>>> Sent: Thursday, 08 March, 2012 13:17 >>>>> To: scott.probasco@nokia.com >>>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>>>> chris.cheeseman@bt.com >>>>> Subject: Re: [paws] WGLC for >>>>> draft-ietf-paws-problem-stmt-usecases- >>>>> rqmts-03: >>>>> channel reporting >>>>> >>>>> So why won't the device simply say "I will use all of this?" >>>>> [GC] This would defeat the purpose of the acknowledgement message. >>>>> After all, that way it needs to do less work with the database. >>>>> And >>> it >>>>> can change frequencies when it wants. >>>>> Given that the stated goal of the Ofcom requriement was to be able >>> to >>>>> analyze interference effects, it seems that this will not actually >>> lead >>>>> to them getting what they want, even if it does comply with the >>>>> regulations. >>>>> [GC] You got it. This would be useless for spectrum regulators. >>>>> One should realize that, from the spectrum regulator's point of >>>>> view, the >>> second >>>>> and >>>>> third messages could be iterated upon to optimize the spectrum use. >>>>> Knowing >>>>> what channels the systems in an area are using, the spectrum >>> regulators >>>>> and/or other entities such as those taking care of coexistence >>>>> could use the database in near-real-time to iterate on the two >>>>> last messages to reduce the range of channels that some systems >>>>> may use once they know precisely what channels are being used in the area. >>>>> The PAWS protocol would carry >>> the >>>>> information back and forth but would not be involved in such >>> spectrum >>>>> use >>>>> optimization. >>>>> >>>>> Yours, >>>>> joel >>>>> >>>>> On 3/8/2012 1:09 PM, scott.probasco@nokia.com wrote: >>>>>> Hi Peter, >>>>>> >>>>>> Answers below. >>>>>> >>>>>> Kind Regards, >>>>>> Scott >>>>>> >>>>>> On 3/8/12 11:39 AM, "ext Peter Saint-Andre" >>>>> wrote: >>>>>> >>>>>>> Hi Scott, I have two clarifying questions: >>>>>>> >>>>>>> 1. Does the device know, when it receives the channel response, >>>>> which >>>>>>> channel it will actually use? >>>>>> Scott->This is all new and I am not aware of any existing >>>>> implementations. >>>>>> I would argue that the device must decide what channel(s) it >>>>>> will >>> use >>>>> when >>>>>> it receives the channel response. >>>>> [GC] Agree with Scott but this is only a portion of the >>> considerations. >>>>> If a >>>>> device was to operate on its own, this would be true but a >>>>> communication device usually implies at least 2 devices to >>>>> communicate. Hence, the choice of the channel to be used will need >>>>> to be negotiated between the two devices before a choice can be >>>>> made. The chosen channel will belong to the >>> set >>>>> of >>>>> available channels that is common to both devices. Remember that >>> some >>>>> channels may be available at one device and not at the other >>>>> because >>> of >>>>> their geolocation or other reason. Extending this concept to a >>>>> star network topology, the channel that will be selected by this >>>>> network will >>> have >>>>> to >>>>> belong to the set of channels that are available to all devices. >>> Each >>>>> device >>>>> will not be able to decide by itself which channel it wants to use. >>>>> >>>>> This is why in such a star topology, it makes sense that the slave >>>>> devices to a base station or access point be represented by the >>>>> base station acting as the master on their behalf to query the >>>>> database and receive the list of available channels (and/or >>>>> maximum EIRP per channel). It is then the responsibility of the >>>>> base station to identify the set of available channels that is >>>>> common for itself and all its slaves to decide on the >>> channel >>>>> that >>>>> the network will use. As you can see, in this case, there is no >>>>> need for each slave to receive its list of available channels. On >>>>> its own, it would not know what to do with it. The only thing that >>>>> needs to be sent >>> from >>>>> the >>>>> master device to its slaves is the resulting operating channel. >>>>> >>>>> I a more sophisticated operation, the master device may add one or >>>>> a few backup channels extracted from the common set of available >>>>> channel >>> to >>>>> the >>>>> message going to its slave so that if a change in channel >>> availability >>>>> occurs, an instantaneous switch to the next backup channel can be >>> made >>>>> without any further signaling, thus providing for a channel switch >>> that >>>>> is >>>>> transparent to the user. It is the scheme that has been included >>>>> in >>> the >>>>> IEEE >>>>> 802.22-2011 Standard. This is why I don't believe that PAWS should >>> get >>>>> involved in defining this signaling between the base station and >>>>> its slaves devices. >>>>>>> >>>>>>> 2. If the device then uses another channel or a different >>> channel, >>>>> does >>>>>>> it need to report that change to the database? >>>>>> Scott->My interpretation of section 3.18 is that the device can >>> only >>>>>> transmit within the upper& lower frequencies returned in the >>>>>> acknowledgment. I do not (quickly) find any reference in the >>>>> requirements >>>>>> to changing channels. Thus operationally it could be that the >>> channel >>>>>> request process must be repeated before the device can use a >>>>> different >>>>>> channel (frequencies). >>>>> [GC] If the process involves 2 messages, then, the device and its >>>>> associated devices could change channels at will as long as all >>>>> these channels belong to the set of available channel. However, if >>>>> the third message is added, it would make sense that the master >>>>> device reports to the database any channel change that would occur >>>>> to the database, otherwise, the status of >>> the >>>>> spectrum occupation would be wrong at any moment and would be >>> useless >>>>> for >>>>> the purpose of any spectrum usage optimization such as coexistence. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> Peter >>>>>>> >>>>>>> On 3/8/12 10:17 AM, scott.probasco@nokia.com wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> The point from Brian is very relevant: >>>>>>>> >>>>>>>> Channel request >>>>>>>> Channel response >>>>>>>> Channel acknowledgement >>>>>>>> >>>>>>>> What Ofcom does with the information in the acknowledgement >>>>>>>> does >>>>> not >>>>>>>> matter. As the regulator in UK, they write rules that must be >>>>> followed >>>>>>>> in >>>>>>>> order to operate a whitespace radio in the UK. I believe the >>> scope >>>>> of >>>>>>>> the >>>>>>>> WG must be focused on a working solution. If this is simple >>> channel >>>>>>>> request& response in one regulator's domain, PAWS can support >>>>> this. If >>>>>>>> it >>>>>>>> means a channel request, response and acknowledgement in >>>>>>>> another regulator's domain, PAWS can support this. As a >>>>>>>> participating >>>>> member of >>>>>>>> the work group, I believe the scope should be basic working >>>>> solution, >>>>>>>> not >>>>>>>> limited to a specific number of messages. >>>>>>>> >>>>>>>> Kind Regards, >>>>>>>> Scott >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 3/8/12 11:11 AM, "ext Zuniga, Juan Carlos" >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Peter, Nancy, >>>>>>>>> >>>>>>>>> I agree should design a protocol with the best of our current >>>>>>>>> knowledge, and that should be accounting for all the known >>>>>>>>> regulations at >>>>> present >>>>>>>>> time. We should not limit the scope with the purpose of >>> designing >>>>> a >>>>>>>>> protocol 'faster'. Our goal is not only to design a WSDB >>> protocol. >>>>> Our >>>>>>>>> goal is to design a WSDB protocol that is USEFUL to the >>> community. >>>>>>>>> >>>>>>>>> The charter does state that >>>>>>>>> >>>>>>>>> "...the group should also reach out to other potential >>>>>>>>> "customers" for a white space database access method and >>> consider >>>>> input >>>>>>>> >from regulatory entities that are involved in the >>>>>>>>> specification >>> of >>>>> the >>>>>>>>> rules for secondary use of spectrum in specific radio bands. " >>>>>>>>> >>>>>>>>> I think that is exactly what we are doing now. >>>>>>>>> >>>>>>>>> Regarding whether the types of requirements belong to #1 or >>>>>>>>> #2, >>> I >>>>>>>>> believe >>>>>>>>> it is more of #1 type, as the information to be exchanged >>>>>>>>> would >>> be >>>>>>>>> known >>>>>>>>> after the initial query/response. >>>>>>>>> >>>>>>>>> If we know it today, I see no reason why we should not work >>>>>>>>> on >>> it >>>>> in >>>>>>>>> the >>>>>>>>> first phase of the work. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Juan Carlos >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] >>>>>>>>>> On >>>>> Behalf >>>>>>>>>> Of >>>>>>>>>> Peter Saint-Andre >>>>>>>>>> Sent: Thursday, March 08, 2012 11:59 AM >>>>>>>>>> To: Nancy Bravin >>>>>>>>>> Cc: paws@ietf.org; johnny.dixon@bt.com; >>> chris.cheeseman@bt.com; >>>>> Pete >>>>>>>>>> Resnick >>>>>>>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- >>>>> usecases- >>>>>>>>>> rqmts-03: channel reporting >>>>>>>>>> >>>>>>>>>> Hi Nancy, >>>>>>>>>> >>>>>>>>>> You are absolutely right that different locales will have >>>>> different >>>>>>>>>> rules and requirements. We need to understand those, and >>>>>>>>>> work >>> to >>>>>>>>>> address >>>>>>>>>> them if possible (although we don't necessarily need to >>> address >>>>> them >>>>>>>>>> all >>>>>>>>>> at the same time). I see several kinds of requirements: >>>>>>>>>> >>>>>>>>>> 1. Some requirements might lead to features beyond the >>>>> query/response >>>>>>>>>> protocol we've envisioned so far. One example might be real- >>> time >>>>>>>>>> reporting about the channels that a device is actually using. >>> In >>>>> my >>>>>>>>>> opinion, it would be best to handle those in the next phase >>>>>>>>>> of >>>>> work, >>>>>>>>>> because as far as I can see they are outside the scope of >>>>>>>>>> our >>>>> charter. >>>>>>>>>> >>>>>>>>>> 2. Some requirements might be handled through by defining >>>>> additional >>>>>>>>>> fields that can be included in the query or response. We >>>>> definitely >>>>>>>>>> planned for that when working on the charter with the IESG: >>>>>>>>>> >>>>>>>>>> In addition, the particular >>>>>>>>>> data exchanged between a device and a database might >>>>>>>>>> depend >>> on >>>>> the >>>>>>>>>> ranges of radio spectrum that are to be used, the >>> requirements >>>>> of >>>>>>>>>> the >>>>>>>>>> database operators and their governing regulations, and >>> other >>>>>>>>>> factors. >>>>>>>>>> Therefore, the database access method and the >>> query/response >>>>> data >>>>>>>>>> formats that are exchanged using that method need to be >>>>> designed >>>>> for >>>>>>>>>> extensibility rather than being tied to any specific >>> spectrum, >>>>>>>>>> country, or phy/mac/air interface. >>>>>>>>>> >>>>>>>>>> It's unclear to me right now if the Ofcom requirement fits >>> into >>>>> #1 or >>>>>>>>>> #2, which is why we're having this discussion. :) >>>>>>>>>> >>>>>>>>>> Peter >>>>>>>>>> >>>>>>>>>> On 3/7/12 8:17 PM, Nancy Bravin wrote: >>>>>>>>>>> Peter and all, >>>>>>>>>>> >>>>>>>>>>> I agree that it is important to revisit now, so that in the >>>>> future, >>>>>>>>>>> it will be easy to align things in their proper place. >>>>>>>>>>> Every >>>>> country >>>>>>>>>>> may have different regulations, spectrum, policy and what >>>>>>>>>>> responsibility is in the domain of the system, and what >>>>>>>>>>> comes >>>>> under >>>>>>>>>>> the PAWS charter is important. Maybe some separation might >>> be >>>>>>>>>>> possible, and dividing and clarifying issues now will help >>>>>>>>>>> in >>>>> the >>>>>>>>>>> future. Certainly it seems that the FCC may change some >>> rules, >>>>> and >>>>>>>>>>> we know that Ofcom is not yet finished with their >>> regulations. >>>>> Canada >>>>>>>>>>> has their own, and other countries are working on this as >>> well. >>>>> Just >>>>>>>>>>> a thought...Sharing is a realistic goal...as is off >>> loading... >>>>> Or you >>>>>>>>>>> slim line and every 6 months decide what to incorporate in >>> the >>>>>>>>>>> protocol based on new information, new ideas, new >>>>>>>>>>> innovation >>> new >>>>>>>>>>> regulations and maybe spend more time than you could if >>>>> addressed >>>>>>>>>>> now. >>>>>>>>>>> >>>>>>>>>>> That way you leave the door open and outside of referencing >>> what >>>>> is >>>>>>>>>>> known today, by referencing regulations i.e. Ofcom, FCC, >>>>> Industry >>>>>>>>>>> Canada etc as of XX-XX-XXXX date. Out of scope not >>>>>>>>>>> something >>> we >>>>> know >>>>>>>>>>> enough about to say at this point, In my opinion. >>>>>>>>>>> >>>>>>>>>>> My 2 cents.. >>>>>>>>>>> >>>>>>>>>>> Sincerely, Nancy >>>>>>>>>>> >>>>>>>>>>> On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> As your responsible Area Director (until March 28, when >>>>>>>>>>>> Pete Resnick will take over from me), I have reviewed this >>> thread. >>>>>>>>>>>> >>>>>>>>>>>> In my opinion (I am happy to be proven wrong), this new >>>>> requirement >>>>>>>>>>>> goes beyond what the charter defined as the scope of this >>>>> working >>>>>>>>>>>> group, which was to enable a device to discover the white >>> space >>>>>>>>>>>> available to it in its current location. Reporting usage >>> back >>>>> to >>>>>>>>>>>> the database is simply not mentioned in the charter. >>>>>>>>>>>> >>>>>>>>>>>> Earlier in this thread, Andy Sago wrote: >>>>>>>>>>>> >>>>>>>>>>>> There's no language I can find in the charter that >>> explicitly >>>>> puts >>>>>>>>>>>> this out of scope. >>>>>>>>>>>> >>>>>>>>>>>> An IETF charter defines what the working group shall work >>> on. >>>>> Many >>>>>>>>>>>> interesting features could be developed here. However, it >>>>>>>>>>>> is >>>>> not >>>>>>>>>>>> the job of the charter to mention explicitly that each of >>> those >>>>>>>>>>>> interesting features is out of scope. >>>>>>>>>>>> >>>>>>>>>>>> The charter does say: >>>>>>>>>>>> >>>>>>>>>>>> Once the device learns of the available white space (e.g., >>> in a >>>>> TV >>>>>>>>>>>> white space implementation, the list of available channels >>> at >>>>> that >>>>>>>>>>>> location), it can then select one of the bands from the >>>>>>>>>>>> list >>>>> and >>>>>>>>>>>> begin to transmit and receive on the selected band. >>>>>>>>>>>> >>>>>>>>>>>> This text might have assumed that no further communication >>> or >>>>>>>>>>>> authorization was required in order to select one of the >>> bands >>>>> from >>>>>>>>>>>> the list and then transmit/receive. Perhaps that >>>>>>>>>>>> assumption >>> was >>>>>>>>>>>> mistaken. If so, it would be good to have a discussion >>>>>>>>>>>> about >>>>> that, >>>>>>>>>>>> so we can determine if we need to revisit the assumptions >>>>>>>>>>>> we >>>>> made >>>>>>>>>>>> early on. If in fact we made some faulty or limited >>>>> assumptions, >>>>>>>>>>>> then let's get that out in the open. >>>>>>>>>>>> >>>>>>>>>>>> Peter >>>>>>>>>>>> >>>>>>>>>>>> On 3/7/12 9:40 AM, Rosen, Brian wrote: >>>>>>>>>>>>> I'd also suggest that >>> our >>>>>>>>>>>>> charter limitation is really support for sharing of >>> whitespace >>>>> by >>>>>>>>>>>>> whitespace devices. Reporting what you use is not >>>>>>>>>>>>> sharing, >>>>> it's >>>>>>>>>>>>> just data gathering. >>>>>>>>>>>>> >>>>>>>>>>>>> The point of excluding sharing was to eliminate the >>>>> complexities >>>>>>>>>>>>> of what constituted fairness, and what kinds of >>> communication >>>>>>>>>>>>> might be needed between databases, where more than one >>> could >>>>>>>>>>>>> supply available whitespace in a band. This doesn't have >>> any >>>>> of >>>>>>>>>>>>> those issues, As long as it's just sending information, I >>>>> don't >>>>>>>>>>>>> have a problem. Once the database is supposed to do >>> anything >>>>>>>>>>>>> with it that involves changing what spectrum it reports, >>> then >>>>> I >>>>>>>>>>>>> think we cross the line. >>>>>>>>>>>>> >>>>>>>>>>>>> Brian >>>>>>>>>>>>> >>>>>>>>>>>>> On Mar 6, 2012, at 12:28 PM, >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Joel >>>>>>>>>>>>>> >>>>>>>>>>>>>> Indeed, the regulator has not described the process or >>>>> provided >>>>>>>>>>>>>> a flow diagram, so there may be some wrinkles, but we >>>>>>>>>>>>>> need >>> to >>>>>>>>>>>>>> provide for their intent. To answer your question, the >>>>> channels >>>>>>>>>>>>>> that the master will use are sent in a separate message >>>>>>>>>>>>>> (described in P.12 ter), that occurs after the master >>>>> receives >>>>>>>>>>>>>> the response to its channel request, but before the >>>>>>>>>>>>>> master >>>>> can >>>>>>>>>>>>>> transmit. At this point, it knows what channels are >>>>> available, >>>>>>>>>>>>>> and which one it will use. As far as the slaves are >>>>> concerned, >>>>>>>>>>>>>> as they associate, the master will need to gather their >>>>> details >>>>>>>>>>>>>> and send further channel usage messages to the database >>>>>>>>>>>>>> on their behalf. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards >>>>>>>>>>>>>> >>>>>>>>>>>>>> Andy >>>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- From: paws-bounces@ietf.org >>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] On Behalf Of Joel M. >>> Halpern >>>>>>>>>>>>>> Sent: 06 March 2012 17:05 To: scott.probasco@nokia.com >> Cc: >>>>>>>>>>>>>> paws@ietf.org; Cheeseman,CJ,Chris,COD R; >>> Dixon,JS,Johnny,COD >>>>> R >>>>>>>>>>>>>> Subject: Re: [paws] WGLC for >>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel >>>>>>>>>>>>>> reporting >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ahh. I think I see where the request and my >>>>>>>>>>>>>> understanding divurge. If the idea here is that the >>>>>>>>>>>>>> master must provide, >>> in >>>>>>>>>>>>>> the request, an indication of what channels it expects >>>>>>>>>>>>>> to >>>>> use, >>>>>>>>>>>>>> I can at least understand that. I will return to >>> technical >>>>>>>>>>>>>> concerns in a moment. >>>>>>>>>>>>>> >>>>>>>>>>>>>> However, when you say "provide channel usage >>>>>>>>>>>>>> information, >>> in >>>>>>>>>>>>>> order to evaluate interference", what that says to me is >>>>>>>>>>>>>> providing, during operation, information as to what >>> channels >>>>>>>>>>>>>> are being used, and at what power levels. That is what >>> would >>>>>>>>>>>>>> be needed to analyze actual interference effects. And >>>>>>>>>>>>>> that >>> is >>>>>>>>>>>>>> out of scope as I understand our scope. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I do see a technical difficulty with having the master >>>>> provide, >>>>>>>>>>>>>> as part of either registering or requesting spectrum >>>>>>>>>>>>>> information, what channels it intends to use. It >>>>>>>>>>>>>> doesn;t >>>>> know >>>>>>>>>>>>>> what channels it intends to use. It intends to use some >>>>> number >>>>>>>>>>>>>> of available channels. It will figure out which ones >>>>>>>>>>>>>> when >>> it >>>>>>>>>>>>>> is told what is available. How can it send that >>> information >>>>> in >>>>>>>>>>>>>> the request? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There is a similarity here with device ID. In context >>>>>>>>>>>>>>> of >>>>> PAWS >>>>>>>>>>>>>>> we are not concerned with why a device ID is required >>>>>>>>>>>>>>> by >>> a >>>>>>>>>>>>>>> regulator, we accept it is a requirement from a >>>>>>>>>>>>>>> regulator >>>>> and >>>>>>>>>>>>>>> include it to the protocol. Ofcom identifies in 3.18& >>> 3.19 >>>>>>>>>>>>>>> that channel usage information is required and thus we >>> need >>>>>>>>>>>>>>> to include this information. Since the master must >>> provide >>>>>>>>>>>>>>> this information prior to transmitting, PAWS will not >>>>>>>>>>>>>>> function in the UK without this information and thus I >>>>>>>>>>>>>>> believe channel usage information is integral to the >>> channel >>>>>>>>>>>>>>> request& response messaging. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Kind Regards, Scott >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 3/6/12 10:30 AM, "ext Joel M. >>>>>>>>>>>>>>> Halpern" wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I would draw a distinction. Ofcom regulations about >>>>>>>>>>>>>>>> whitespace requests are very much relevant. Ofcom >>>>>>>>>>>>>>>> regulations about notification of dynamic behavior >>> (which >>>>>>>>>>>>>>>> spectrum is being used) are not in scope as I >>>>>>>>>>>>>>>> understand the earlier discussions, particularly the >>>>>>>>>>>>>>>> chartering discussions. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The ofcom requirements are very much relevant to the >>>>>>>>>>>>>>>>> scope of the PAWS WG. The only other regulatory >>>>>>>>>>>>>>>>> requirements that we have today is the FCC. Ofcom >>>>>>>>>>>>>>>>> requirements are a good addition to the set. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -Raj >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 3/6/12 10:03 AM, "ext >>>>>>>>>>>>>>>>> andy.sago@bt.com" wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi Joel >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> There's no language I can find in the charter that >>>>>>>>>>>>>>>>>> explicitly puts this out of scope. On the other >>>>>>>>>>>>>>>>>> hand, the charter says that the group will "consider >>>>>>>>>>>>>>>>>> input from regulatory entities", and this is one of >>>>>>>>>>>>>>>>>> the requirements from Ofcom that they have just >> published. >>>>>>>>>>>>>>>>>> The protocol will be worthless for the UK if it >>>>>>>>>>>>>>>>>> omits some requirements. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Andy >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -----Original Message----- From: Joel M. Halpern >>>>>>>>>>>>>>>>>> [mailto:jmh@joelhalpern.com] Sent: 06 March 2012 >>>>>>>>>>>>>>>>>> 15:53 >>>>>>>>>>>>>>>>>> To: Sago,AJ,Andy,COD R Cc: paws@ietf.org; >>>>>>>>>>>>>>>>>> Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for >>>>>>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: >>> channel >>>>>>>>>>>>>>>>>> reporting >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> As I understand, the information you are asking for >>>>>>>>>>>>>>>>>> is explicitly out of scope for the working group. >>>>>>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >>>>>>>>>>>>>>>>>>> All >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Comparing the draft with the Ofcom requirements at >>>>>>>>>>>>>>>>>>> http://www.cept.org/Documents/se- >>>>>>>>>> 43/4161/SE43(12)Info03_Draft-UK-r >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>> egul >>>>>>>>>>>>>>>>>>> atory-requirements-for-white-space-devices-in-the- >>> UHF- >>>>> TV- >>>>>>>>>> band, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>> I believe the WG draft is deficient in the area of reporting >>>>>>>>>>>>>>>>>>> frequencies and powers actually used by masters and >>>>>>>>>>>>>>>>>>> slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom >>>>>>>>>>>>>>>>>>> intends to collect this data to assesses the impact >>>>>>>>>>>>>>>>>>> of aggregate interference into other services. It >>>>>>>>>>>>>>>>>>> would also provide usage information (frequency in >>>>>>>>>>>>>>>>>>> use) that would inform the operation of a kill >>>>>>>>>>>>>>>>>>> switch capability. I suggest this deficiency can be >>>>>>>>>>>>>>>>>>> remedied with the following changes: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> New P requirements (probably best placed following >>>>>>>>>>>>>>>>>>> P.12): >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> P.12bis: The protocol MUST support a channel usage >>>>>>>>>>>>>>>>>>> message from the slave device to the master device. >>>>>>>>>>>>>>>>>>> The channel usage message MUST include parameters >>>>>>>>>>>>>>>>>>> as required by local regulatory requirement. These >>>>>>>>>>>>>>>>>>> parameters MAY include device ID, manufacturer's >>>>>>>>>>>>>>>>>>> serial number, channel usage and power level >>>>>>>>>>>>>>>>>>> information. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> P.12ter: The protocol MUST support a channel usage >>>>>>>>>>>>>>>>>>> message from the master device to the database. >>>>>>>>>>>>>>>>>>> The channel usage message MUST include parameters >>>>>>>>>>>>>>>>>>> as required by local regulatory requirement for the >>>>>>>>>>>>>>>>>>> master and its associated slaves. These parameters >>>>>>>>>>>>>>>>>>> MAY include device ID, manufacturer's serial >>>>>>>>>>>>>>>>>>> number, channel usage and power level information. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> P.12qua: The protocol MUST support a channel usage >>>>>>>>>>>>>>>>>>> message acknowledgement. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> New O requirements (probably best placed following >>>>>>>>>>>>>>>>>>> O13): >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> O.13bis: According to local regulatory policy, >>>>>>>>>>>>>>>>>>> after connecting to a master device's radio network >>>>>>>>>>>>>>>>>>> a slave device MAY inform the master device of the >>>>>>>>>>>>>>>>>>> actual channel usage. The slave MUST include >>>>>>>>>>>>>>>>>>> parameters required by local regulatory policy, e.g. >>>>>>>>>>>>>>>>>>> device ID, manufacturer's serial number, channel >>>>>>>>>>>>>>>>>>> usage and power level information. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> O.13ter: According to local regulatory policy, a >>>>>>>>>>>>>>>>>>> master device MAY inform the database of the actual >>>>>>>>>>>>>>>>>>> channel usage of the master and its slaves. The >>>>>>>>>>>>>>>>>>> master MUST include parameters required by local >>>>>>>>>>>>>>>>>>> regulatory policy, e.g. device ID, manufacturer's >>>>>>>>>>>>>>>>>>> serial number, channel usage and power level >>>>>>>>>>>>>>>>>>> information of the master and its slaves. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> New steps could be introduced into one or more use >>>>>>>>>>>>>>>>>>> cases to cover these Ofcom requirements, e.g. new >>>>>>>>>>>>>>>>>>> steps 6bis and 9bis in the hotspot use case at >>>>>>>>>>>>>>>>>>> 4.2.1: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 6bis. Prior to initiating transmission, if required >>>>>>>>>>>>>>>>>>> by local regulation, the master/AP informs the >>>>>>>>>>>>>>>>>>> database of the channel and power level it has >>>>>>>>>>>>>>>>>>> chosen. This is repeated for each slave that >>>>>>>>>>>>>>>>>>> associated with the master. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 9bis. Prior to initiating transmission, if required >>>>>>>>>>>>>>>>>>> by local regulation, the slave informs the >>>>>>>>>>>>>>>>>>> master/AP of the channel and power level it has >>>>>>>>>>>>>>>>>>> chosen, and the master/AP relays this information >>>>>>>>>>>>>>>>>>> to the >> database. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> - end of new text - >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> For information, for those not accessing the url in >>>>>>>>>>>>>>>>>>> the first paragraph of this email, the full Ofcom >>>>>>>>>>>>>>>>>>> requirements leading to this new PAWS text are as >>>>>>>>>>>>>>>>>>> follows: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 3.18 After receiving instructions from a WSDB in >>>>>>>>>>>>>>>>>>> relation to the maximum permitted EIRPs over the >>>>>>>>>>>>>>>>>>> DTT channels, and prior to initiating transmissions >>>>>>>>>>>>>>>>>>> within the UHF TV band, a master WSD must >>>>>>>>>>>>>>>>>>> communicate to the WSDB the following information: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 3.18.1 The lower and upper frequency boundaries^13 >>>>>>>>>>>>>>>>>>> of the in-block emissions of the master WSD, and >>>>>>>>>>>>>>>>>>> those of the in-block emissions of its associated >>>>>>>>>>>>>>>>>>> slaves. A lower frequency will be specified as (470 >>>>>>>>>>>>>>>>>>> + 8k + >>>>>>>>>>>>>>>>>>> 0.2n) MHz, with the corresponding upper frequency >>>>>>>>>>>>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3?4 k >> 3?4 >>>>>>>>>>>>>>>>>>> 39, 0 3?4 n 3?4 39, 1 3?4 m 3?4 40, and n< m. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 3.18.2 The maximum in-block EIRP spectral densities >>>>>>>>>>>>>>>>>>> (in dBm/(0.2 MHz)) that the master WSD, and its >>>>>>>>>>>>>>>>>>> associated slaves, actually radiate between each >>>>>>>>>>>>>>>>>>> reported lower frequency boundary and its >>>>>>>>>>>>>>>>>>> corresponding upper frequency boundary. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Footnote 13 states: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The use of upper and lower frequency boundaries >>>>>>>>>>>>>>>>>>> (defined over a 200 kHz raster) allows a WSDB to >>>>>>>>>>>>>>>>>>> collect more granular information with regards to >>>>>>>>>>>>>>>>>>> the usage of the frequency resource by narrowband >>>>>>>>>>>>>>>>>>> WSD technologies. The upper and lower frequencies >>>>>>>>>>>>>>>>>>> of a boundary pair do not straddle a DTT channel >> boundary. >>>>>>>>>>>>>>>>>>> Note that a WSD may transmit over multiple, >>>>>>>>>>>>>>>>>>> non-contiguous, whole DTT channels or fractions of >>>>>>>>>>>>>>>>>>> DTT channels. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 3.19 A master WSD must be able to receive the >>>>>>>>>>>>>>>>>>> following information^14 from a WSDB: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in the >>>>>>>>>>>>>>>>>>> context of 3.18, that the reported information on >>>>>>>>>>>>>>>>>>> the DTT channels and EIRP spectral densities >>>>>>>>>>>>>>>>>>> actually used by the master and slave WSDs were >>>>>>>>>>>>>>>>>>> received successfully by the WSDB^18 ]. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Footnote 14 states: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 14 While the communication of some of this >>>>>>>>>>>>>>>>>>> information from a WSDB to a master WSD is >>>>>>>>>>>>>>>>>>> optional, master WSDs must be able to receive and >>>>>>>>>>>>>>>>>>> interpret these. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Footnote 18 states: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 18 This forms part of a handshake protocol and may >>>>>>>>>>>>>>>>>>> be an area where industry could harmonise without >>>>>>>>>>>>>>>>>>> the need for an explicit requirement in the >> regulations. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Andy >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> *From:*paws-bounces@ietf.org >>>>>>>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] *On Behalf Of >>>>>>>>>>>>>>>>>>> *Gabor.Bajko@nokia.com *Sent:* 05 March 2012 19:46 >>>>>>>>>>>>>>>>>>> *To:* paws@ietf.org *Subject:* [paws] WGLC for >>>>>>>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The authors of the use cases and requirements draft >>>>>>>>>>>>>>>>>>> have just posted a new version of the draft and >>>>>>>>>>>>>>>>>>> indicated that there are no unresolved >>>>>>>>>>>>>>>>>>> comments/issues they are aware of. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Therefore, I'd like to initiate a WG Last Call for >>>>>>>>>>>>>>>>>>> comments on >>>>>>>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-paws >>>>>>>>>>>>>>>>>>> - >>>>> problem- >>>>>>>>>> stmt-u >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>> seca >>>>>>>>>>>>>>>>>>> ses-rqmts-03.txt >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Please review the draft and send your comments to >>>>>>>>>>>>>>>>>>> the list by March 20th, 2012. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> If you review the draft and have no comments, send >>>>>>>>>>>>>>>>>>> a note to the list that the draft is good as it is, >>>>>>>>>>>>>>>>>>> we need these notes as much as we need the actual >>>>>>>>>>>>>>>>>>> comments. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, Gabor >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> paws mailing list >>>>>> paws@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>> >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>>> >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>> _______________________________________________ >>>> 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 >> >> ________________________________ >> >> *********************************************************************** >> * >> ****************************************** >> For more information visit www.ofcom.org.uk >> >> This email (and any attachments) is confidential and intended for the >> use of the addressee only. >> >> If you have received this email in error please notify the originator >> of the message and delete it from your system. >> >> This email has been scanned for viruses. However, you open any >> attachments at your own risk. >> >> Any views expressed in this message are those of the individual sender >> and do not represent the views or opinions of Ofcom unless expressly >> stated otherwise. >> *********************************************************************** >> * >> ****************************************** >> _______________________________________________ >> 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 Andrew.Gowans@ofcom.org.uk Fri Mar 9 08:07:20 2012 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 2B57A21F8716 for ; Fri, 9 Mar 2012 08:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.971 X-Spam-Level: X-Spam-Status: No, score=-0.971 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=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 pSfmFzbdSoBX for ; Fri, 9 Mar 2012 08:07:17 -0800 (PST) Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.242]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF9521F8710 for ; Fri, 9 Mar 2012 08:07:16 -0800 (PST) Received: from [85.158.143.99:34236] by server-1.bemta-4.messagelabs.com id 6C/FD-20925-2BA2A5F4; Fri, 09 Mar 2012 16:07:14 +0000 X-Env-Sender: Andrew.Gowans@ofcom.org.uk X-Msg-Ref: server-12.tower-216.messagelabs.com!1331309234!13216049!1 X-Originating-IP: [194.33.160.65] X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1028 invoked from network); 9 Mar 2012 16:07:14 -0000 Received: from unknown (HELO WOK-INTRA-EDG02.intra.ofcom.local) (194.33.160.65) by server-12.tower-216.messagelabs.com with AES128-SHA encrypted SMTP; 9 Mar 2012 16:07:14 -0000 Received: from WOK-INTRA-EXC01.intra.ofcom.local (10.130.130.67) by WOK-INTRA-EDG02.intra.ofcom.local (10.130.239.20) with Microsoft SMTP Server (TLS) id 14.1.289.1; Fri, 9 Mar 2012 16:07:13 +0000 Received: from WOK-INTRA-EXC02.intra.ofcom.local ([fe80::550e:933d:224e:6a19]) by WOK-INTRA-EXC01.intra.ofcom.local ([fe80::f0b6:2506:a722:c58b%15]) with mapi id 14.01.0289.001; Fri, 9 Mar 2012 16:03:59 +0000 From: Andrew Gowans To: "chris.cheeseman@bt.com" , "paul@marvell.com" , "sdas@appcomsci.com" , Siew Yoon Tan , "JuanCarlos.Zuniga@InterDigital.com" , "Basavaraj.Patil@nokia.com" , "gerald.chouinard@sympatico.ca" , "jmh@joelhalpern.com" , "scott.probasco@nokia.com" Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting Thread-Index: AQHM/ZcTdM2L+zQcUUapw3A7HAeEzZZhOcUAgACcqQCAAEbdIA== Date: Fri, 9 Mar 2012 16:03:58 +0000 Message-ID: <9983D74B649EED43B27BF353837B20C57D94596B@WOK-INTRA-EXC02.intra.ofcom.local> References: , <7BAC95F5A7E67643AAFB2C31BEE662D0157A034B37@SC-VEXCH2.marvell.com> 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.131.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 09 Mar 2012 08:07:53 -0800 Cc: "paws@ietf.org" , "presnick@qualcomm.com" , Reza Karimi , "johnny.dixon@bt.com" Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 16:07:20 -0000 All I agree with Chris, the aim of the return information is to collect the= max power levels and channels/frequency ranges that the master and its ass= ociated slaves are using. This information in con-junction with the other i= nformation collected (e.g. technology ID) may be used to estimate the inter= ference potential to the incumbent services in any given area. There is no= intention here to have the device indicate to the WSDB its configuration a= t any given instant. Regards Andy -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of chr= is.cheeseman@bt.com Sent: 09 March 2012 11:36 To: paul@marvell.com; sdas@appcomsci.com; Siew Yoon Tan; JuanCarlos.Zuniga@= InterDigital.com; Basavaraj.Patil@nokia.com; gerald.chouinard@sympatico.ca;= jmh@joelhalpern.com; scott.probasco@nokia.com Cc: paws@ietf.org; presnick@qualcomm.com; Reza Karimi; johnny.dixon@bt.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03= :channel reporting Hi My reading of the UK regulatory requirements that Ofcom has made available = is that the Acknowledgement message that must be communicated back to the d= atabase from the white space device is simply the frequency range (or range= s) and maximum eirp density that the device intends to use (a subset of wha= t it would have been offered by the database). I don't believe there is any= intent to limit modulation schemes etc. as part of this exchange. This see= ms a relatively straightforward requirement and the PAWS protocol should ac= commodate this if it is to be relevant for the UK regulatory environment. Regards, Chris -----Original Message----- From: Paul Lambert [mailto:paul@marvell.com] Sent: 09 March 2012 02:15 To: Das, Subir; 'Siew Yoon Tan'; Zuniga, Juan Carlos; Basavaraj.Patil@nokia= .com; gerald.chouinard@sympatico.ca; jmh@joelhalpern.com; scott.probasco@no= kia.com Cc: paws@ietf.org; presnick@qualcomm.com; Reza Karimi; Dixon,JS,Johnny,COD = R; Cheeseman,CJ,Chris,COD R Subject: RE: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03= :channel reporting >I have a question here. Is it really an acknowledgement or we would >like to see a kind of notification message that includes channel, and >other parameters? What if it's multiple channels? What happens if the device adapts and chan= ges between modulation technique or bandwidth? Does every change over the = air need to be indicated to the GDB? This Channel acknowledgement does not seem useful and would limit real worl= d behaviors (like channel and modulation adaptation). If viewed as a potential regulatory requirement - does this imply we need t= o parameterize the protocol to have different behaviors in different region= s? Paul > >Regards, >_Subir > >-----Original Message----- >From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >Siew Yoon Tan >Sent: Thursday, March 08, 2012 4:06 PM >To: Zuniga, Juan Carlos; Basavaraj.Patil@nokia.com; >gerald.chouinard@sympatico.ca; jmh@joelhalpern.com; >scott.probasco@nokia.com >Cc: paws@ietf.org; presnick@qualcomm.com; Reza Karimi; >johnny.dixon@bt.com; chris.cheeseman@bt.com >Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >rqmts-03:channel reporting > >Dear All, > >Regarding Ofcom's requirement to have a return channel as part of the >protocol between the WSD and WSDB, I would like to confirm to following >sequence of messaging > >Channel request >Channel response >Channel acknowledgement > >which was raised in an earlier email to this list. > >Our view is that it would be beneficial to define the protocol between >WSD and WSDB that supports this requirement even though how the >information could be used is still subject to discussion in the UK. > > >Best regards, > >Siew Yoon > > >________________________________________ >From: paws-bounces@ietf.org [paws-bounces@ietf.org] on behalf of >Zuniga, Juan Carlos [JuanCarlos.Zuniga@InterDigital.com] >Sent: 08 March 2012 20:41 >To: Basavaraj.Patil@nokia.com; gerald.chouinard@sympatico.ca; >jmh@joelhalpern.com; scott.probasco@nokia.com >Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >chris.cheeseman@bt.com >Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >rqmts-03:channel reporting > >Hi Raj, > >I was reusing the language used from Gerald (which I know is familiar >to people working on IEEE 802 WS groups): > >>> [GC] You got it. This would be useless for spectrum regulators. One >>> should realize that, from the spectrum regulator's point of view, >>> the second and third messages could be iterated upon to optimize the >>> spectrum use. >>> Knowing >>> what channels the systems in an area are using, the spectrum >>> regulators and/or other entities such as those taking care of >>> coexistence could use the database in near-real-time to iterate on >>> the two last messages to reduce the range of channels that some >>> systems may use once they know precisely what channels are being >>> used in the area. The PAWS protocol would carry the information back >>> and forth but would not be involved in such spectrum use optimization. > >Having said that, I have no issue sticking to the WSDB terminology. I >like keeping things simple :) > >JC > >> -----Original Message----- >> From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] >> Sent: Thursday, March 08, 2012 3:33 PM >> To: Zuniga, Juan Carlos; gerald.chouinard@sympatico.ca; >> jmh@joelhalpern.com; scott.probasco@nokia.com >> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >> chris.cheeseman@bt.com >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >> rqmts-03:channel reporting >> >> >> Hi JC, >> >> Where/why did the coexistence manager come into the picture? Your >> comment about "communicating back to the WSDB/coexistence manager" >> may result in further misunderstanding. If we simply stick to to WSDB >> I think we are okay. >> >> -Raj >> >> On 3/8/12 2:25 PM, "ext Zuniga, Juan Carlos" >> wrote: >> >> >So, from Gerald and Andy's comments, it seems like from the point of >> view >> >of (at least) two regulatory entities it is important for the >> >protocol >> to >> >allow communicating back to the WSDB/coexistence manager the actual >> >channel usage after the first query is made. >> > >> >This is to me a very clear requirement. >> > >> >The actual messages/IEs that would carry this information should be >> >discussed as part of the solution document, and not the requirements. >> > >> >JC >> > >> >> -----Original Message----- >> >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >> >> Behalf >> Of >> >> Gerald Chouinard >> >> Sent: Thursday, March 08, 2012 1:59 PM >> >> To: 'Joel M. Halpern'; scott.probasco@nokia.com >> >> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >> >> chris.cheeseman@bt.com >> >> Subject: Re: [paws] WGLC for >> >> draft-ietf-paws-problem-stmt-usecases- >> >> rqmts-03:channel reporting >> >> >> >> Joel, Scott, >> >> >> >> Interesting discussion! See my comments in line below. >> >> >> >> Gerald >> >> >> >> -----Original Message----- >> >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >> >> Behalf >> Of >> >> Joel >> >> M. Halpern >> >> Sent: Thursday, 08 March, 2012 13:17 >> >> To: scott.probasco@nokia.com >> >> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >> >> chris.cheeseman@bt.com >> >> Subject: Re: [paws] WGLC for >> >> draft-ietf-paws-problem-stmt-usecases- >> >> rqmts-03: >> >> channel reporting >> >> >> >> So why won't the device simply say "I will use all of this?" >> >> [GC] This would defeat the purpose of the acknowledgement message. >> >> After all, that way it needs to do less work with the database. >> >> And >> it >> >> can change frequencies when it wants. >> >> Given that the stated goal of the Ofcom requriement was to be able >> to >> >> analyze interference effects, it seems that this will not actually >> lead >> >> to them getting what they want, even if it does comply with the >> >> regulations. >> >> [GC] You got it. This would be useless for spectrum regulators. >> >> One should realize that, from the spectrum regulator's point of >> >> view, the >> second >> >> and >> >> third messages could be iterated upon to optimize the spectrum use. >> >> Knowing >> >> what channels the systems in an area are using, the spectrum >> regulators >> >> and/or other entities such as those taking care of coexistence >> >> could use the database in near-real-time to iterate on the two >> >> last messages to reduce the range of channels that some systems >> >> may use once they know precisely what channels are being used in the = area. >> >> The PAWS protocol would carry >> the >> >> information back and forth but would not be involved in such >> spectrum >> >> use >> >> optimization. >> >> >> >> Yours, >> >> joel >> >> >> >> On 3/8/2012 1:09 PM, scott.probasco@nokia.com wrote: >> >> > Hi Peter, >> >> > >> >> > Answers below. >> >> > >> >> > Kind Regards, >> >> > Scott >> >> > >> >> > On 3/8/12 11:39 AM, "ext Peter Saint-Andre" >> >> wrote: >> >> > >> >> >> Hi Scott, I have two clarifying questions: >> >> >> >> >> >> 1. Does the device know, when it receives the channel response, >> >> which >> >> >> channel it will actually use? >> >> > Scott->This is all new and I am not aware of any existing >> >> implementations. >> >> > I would argue that the device must decide what channel(s) it >> >> > will >> use >> >> when >> >> > it receives the channel response. >> >> [GC] Agree with Scott but this is only a portion of the >> considerations. >> >> If a >> >> device was to operate on its own, this would be true but a >> >> communication device usually implies at least 2 devices to >> >> communicate. Hence, the choice of the channel to be used will need >> >> to be negotiated between the two devices before a choice can be >> >> made. The chosen channel will belong to the >> set >> >> of >> >> available channels that is common to both devices. Remember that >> some >> >> channels may be available at one device and not at the other >> >> because >> of >> >> their geolocation or other reason. Extending this concept to a >> >> star network topology, the channel that will be selected by this >> >> network will >> have >> >> to >> >> belong to the set of channels that are available to all devices. >> Each >> >> device >> >> will not be able to decide by itself which channel it wants to use. >> >> >> >> This is why in such a star topology, it makes sense that the slave >> >> devices to a base station or access point be represented by the >> >> base station acting as the master on their behalf to query the >> >> database and receive the list of available channels (and/or >> >> maximum EIRP per channel). It is then the responsibility of the >> >> base station to identify the set of available channels that is >> >> common for itself and all its slaves to decide on the >> channel >> >> that >> >> the network will use. As you can see, in this case, there is no >> >> need for each slave to receive its list of available channels. On >> >> its own, it would not know what to do with it. The only thing that >> >> needs to be sent >> from >> >> the >> >> master device to its slaves is the resulting operating channel. >> >> >> >> I a more sophisticated operation, the master device may add one or >> >> a few backup channels extracted from the common set of available >> >> channel >> to >> >> the >> >> message going to its slave so that if a change in channel >> availability >> >> occurs, an instantaneous switch to the next backup channel can be >> made >> >> without any further signaling, thus providing for a channel switch >> that >> >> is >> >> transparent to the user. It is the scheme that has been included >> >> in >> the >> >> IEEE >> >> 802.22-2011 Standard. This is why I don't believe that PAWS should >> get >> >> involved in defining this signaling between the base station and >> >> its slaves devices. >> >> >> >> >> >> 2. If the device then uses another channel or a different >> channel, >> >> does >> >> >> it need to report that change to the database? >> >> > Scott->My interpretation of section 3.18 is that the device can >> only >> >> > transmit within the upper& lower frequencies returned in the >> >> > acknowledgment. I do not (quickly) find any reference in the >> >> requirements >> >> > to changing channels. Thus operationally it could be that the >> channel >> >> > request process must be repeated before the device can use a >> >> different >> >> > channel (frequencies). >> >> [GC] If the process involves 2 messages, then, the device and its >> >> associated devices could change channels at will as long as all >> >> these channels belong to the set of available channel. However, if >> >> the third message is added, it would make sense that the master >> >> device reports to the database any channel change that would occur >> >> to the database, otherwise, the status of >> the >> >> spectrum occupation would be wrong at any moment and would be >> useless >> >> for >> >> the purpose of any spectrum usage optimization such as coexistence. >> >> >> >> >> >> Thanks! >> >> >> >> >> >> Peter >> >> >> >> >> >> On 3/8/12 10:17 AM, scott.probasco@nokia.com wrote: >> >> >>> Hi, >> >> >>> >> >> >>> The point from Brian is very relevant: >> >> >>> >> >> >>> Channel request >> >> >>> Channel response >> >> >>> Channel acknowledgement >> >> >>> >> >> >>> What Ofcom does with the information in the acknowledgement >> >> >>> does >> >> not >> >> >>> matter. As the regulator in UK, they write rules that must be >> >> followed >> >> >>> in >> >> >>> order to operate a whitespace radio in the UK. I believe the >> scope >> >> of >> >> >>> the >> >> >>> WG must be focused on a working solution. If this is simple >> channel >> >> >>> request& response in one regulator's domain, PAWS can support >> >> this. If >> >> >>> it >> >> >>> means a channel request, response and acknowledgement in >> >> >>> another regulator's domain, PAWS can support this. As a >> >> >>> participating >> >> member of >> >> >>> the work group, I believe the scope should be basic working >> >> solution, >> >> >>> not >> >> >>> limited to a specific number of messages. >> >> >>> >> >> >>> Kind Regards, >> >> >>> Scott >> >> >>> >> >> >>> >> >> >>> >> >> >>> On 3/8/12 11:11 AM, "ext Zuniga, Juan Carlos" >> >> >>> wrote: >> >> >>> >> >> >>>> Peter, Nancy, >> >> >>>> >> >> >>>> I agree should design a protocol with the best of our current >> >> >>>> knowledge, and that should be accounting for all the known >> >> >>>> regulations at >> >> present >> >> >>>> time. We should not limit the scope with the purpose of >> designing >> >> a >> >> >>>> protocol 'faster'. Our goal is not only to design a WSDB >> protocol. >> >> Our >> >> >>>> goal is to design a WSDB protocol that is USEFUL to the >> community. >> >> >>>> >> >> >>>> The charter does state that >> >> >>>> >> >> >>>> "...the group should also reach out to other potential >> >> >>>> "customers" for a white space database access method and >> consider >> >> input >> >> >>> >from regulatory entities that are involved in the >> >> >>> >specification >> of >> >> the >> >> >>>> rules for secondary use of spectrum in specific radio bands. " >> >> >>>> >> >> >>>> I think that is exactly what we are doing now. >> >> >>>> >> >> >>>> Regarding whether the types of requirements belong to #1 or >> >> >>>> #2, >> I >> >> >>>> believe >> >> >>>> it is more of #1 type, as the information to be exchanged >> >> >>>> would >> be >> >> >>>> known >> >> >>>> after the initial query/response. >> >> >>>> >> >> >>>> If we know it today, I see no reason why we should not work >> >> >>>> on >> it >> >> in >> >> >>>> the >> >> >>>> first phase of the work. >> >> >>>> >> >> >>>> Regards, >> >> >>>> >> >> >>>> Juan Carlos >> >> >>>> >> >> >>>>> -----Original Message----- >> >> >>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] >> >> >>>>> On >> >> Behalf >> >> >>>>> Of >> >> >>>>> Peter Saint-Andre >> >> >>>>> Sent: Thursday, March 08, 2012 11:59 AM >> >> >>>>> To: Nancy Bravin >> >> >>>>> Cc: paws@ietf.org; johnny.dixon@bt.com; >> chris.cheeseman@bt.com; >> >> Pete >> >> >>>>> Resnick >> >> >>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- >> >> usecases- >> >> >>>>> rqmts-03: channel reporting >> >> >>>>> >> >> >>>>> Hi Nancy, >> >> >>>>> >> >> >>>>> You are absolutely right that different locales will have >> >> different >> >> >>>>> rules and requirements. We need to understand those, and >> >> >>>>> work >> to >> >> >>>>> address >> >> >>>>> them if possible (although we don't necessarily need to >> address >> >> them >> >> >>>>> all >> >> >>>>> at the same time). I see several kinds of requirements: >> >> >>>>> >> >> >>>>> 1. Some requirements might lead to features beyond the >> >> query/response >> >> >>>>> protocol we've envisioned so far. One example might be real- >> time >> >> >>>>> reporting about the channels that a device is actually using. >> In >> >> my >> >> >>>>> opinion, it would be best to handle those in the next phase >> >> >>>>> of >> >> work, >> >> >>>>> because as far as I can see they are outside the scope of >> >> >>>>> our >> >> charter. >> >> >>>>> >> >> >>>>> 2. Some requirements might be handled through by defining >> >> additional >> >> >>>>> fields that can be included in the query or response. We >> >> definitely >> >> >>>>> planned for that when working on the charter with the IESG: >> >> >>>>> >> >> >>>>> In addition, the particular >> >> >>>>> data exchanged between a device and a database might >> >> >>>>> depend >> on >> >> the >> >> >>>>> ranges of radio spectrum that are to be used, the >> requirements >> >> of >> >> >>>>> the >> >> >>>>> database operators and their governing regulations, and >> other >> >> >>>>> factors. >> >> >>>>> Therefore, the database access method and the >> query/response >> >> data >> >> >>>>> formats that are exchanged using that method need to be >> >> designed >> >> for >> >> >>>>> extensibility rather than being tied to any specific >> spectrum, >> >> >>>>> country, or phy/mac/air interface. >> >> >>>>> >> >> >>>>> It's unclear to me right now if the Ofcom requirement fits >> into >> >> #1 or >> >> >>>>> #2, which is why we're having this discussion. :) >> >> >>>>> >> >> >>>>> Peter >> >> >>>>> >> >> >>>>> On 3/7/12 8:17 PM, Nancy Bravin wrote: >> >> >>>>>> Peter and all, >> >> >>>>>> >> >> >>>>>> I agree that it is important to revisit now, so that in the >> >> future, >> >> >>>>>> it will be easy to align things in their proper place. >> >> >>>>>> Every >> >> country >> >> >>>>>> may have different regulations, spectrum, policy and what >> >> >>>>>> responsibility is in the domain of the system, and what >> >> >>>>>> comes >> >> under >> >> >>>>>> the PAWS charter is important. Maybe some separation might >> be >> >> >>>>>> possible, and dividing and clarifying issues now will help >> >> >>>>>> in >> >> the >> >> >>>>>> future. Certainly it seems that the FCC may change some >> rules, >> >> and >> >> >>>>>> we know that Ofcom is not yet finished with their >> regulations. >> >> Canada >> >> >>>>>> has their own, and other countries are working on this as >> well. >> >> Just >> >> >>>>>> a thought...Sharing is a realistic goal...as is off >> loading... >> >> Or you >> >> >>>>>> slim line and every 6 months decide what to incorporate in >> the >> >> >>>>>> protocol based on new information, new ideas, new >> >> >>>>>> innovation >> new >> >> >>>>>> regulations and maybe spend more time than you could if >> >> addressed >> >> >>>>>> now. >> >> >>>>>> >> >> >>>>>> That way you leave the door open and outside of referencing >> what >> >> is >> >> >>>>>> known today, by referencing regulations i.e. Ofcom, FCC, >> >> Industry >> >> >>>>>> Canada etc as of XX-XX-XXXX date. Out of scope not >> >> >>>>>> something >> we >> >> know >> >> >>>>>> enough about to say at this point, In my opinion. >> >> >>>>>> >> >> >>>>>> My 2 cents.. >> >> >>>>>> >> >> >>>>>> Sincerely, Nancy >> >> >>>>>> >> >> >>>>>> On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote: >> >> >>>>>> >> >> >>>>>>> >> >> >>>>>>> >> >> >>>>>>> As your responsible Area Director (until March 28, when >> >> >>>>>>> Pete Resnick will take over from me), I have reviewed this >> thread. >> >> >>>>>>> >> >> >>>>>>> In my opinion (I am happy to be proven wrong), this new >> >> requirement >> >> >>>>>>> goes beyond what the charter defined as the scope of this >> >> working >> >> >>>>>>> group, which was to enable a device to discover the white >> space >> >> >>>>>>> available to it in its current location. Reporting usage >> back >> >> to >> >> >>>>>>> the database is simply not mentioned in the charter. >> >> >>>>>>> >> >> >>>>>>> Earlier in this thread, Andy Sago wrote: >> >> >>>>>>> >> >> >>>>>>> There's no language I can find in the charter that >> explicitly >> >> puts >> >> >>>>>>> this out of scope. >> >> >>>>>>> >> >> >>>>>>> An IETF charter defines what the working group shall work >> on. >> >> Many >> >> >>>>>>> interesting features could be developed here. However, it >> >> >>>>>>> is >> >> not >> >> >>>>>>> the job of the charter to mention explicitly that each of >> those >> >> >>>>>>> interesting features is out of scope. >> >> >>>>>>> >> >> >>>>>>> The charter does say: >> >> >>>>>>> >> >> >>>>>>> Once the device learns of the available white space (e.g., >> in a >> >> TV >> >> >>>>>>> white space implementation, the list of available channels >> at >> >> that >> >> >>>>>>> location), it can then select one of the bands from the >> >> >>>>>>> list >> >> and >> >> >>>>>>> begin to transmit and receive on the selected band. >> >> >>>>>>> >> >> >>>>>>> This text might have assumed that no further communication >> or >> >> >>>>>>> authorization was required in order to select one of the >> bands >> >> from >> >> >>>>>>> the list and then transmit/receive. Perhaps that >> >> >>>>>>> assumption >> was >> >> >>>>>>> mistaken. If so, it would be good to have a discussion >> >> >>>>>>> about >> >> that, >> >> >>>>>>> so we can determine if we need to revisit the assumptions >> >> >>>>>>> we >> >> made >> >> >>>>>>> early on. If in fact we made some faulty or limited >> >> assumptions, >> >> >>>>>>> then let's get that out in the open. >> >> >>>>>>> >> >> >>>>>>> Peter >> >> >>>>>>> >> >> >>>>>>> On 3/7/12 9:40 AM, Rosen, Brian wrote: >> >> >>>>>>>> I'd also suggest that >> our >> >> >>>>>>>> charter limitation is really support for sharing of >> whitespace >> >> by >> >> >>>>>>>> whitespace devices. Reporting what you use is not >> >> >>>>>>>> sharing, >> >> it's >> >> >>>>>>>> just data gathering. >> >> >>>>>>>> >> >> >>>>>>>> The point of excluding sharing was to eliminate the >> >> complexities >> >> >>>>>>>> of what constituted fairness, and what kinds of >> communication >> >> >>>>>>>> might be needed between databases, where more than one >> could >> >> >>>>>>>> supply available whitespace in a band. This doesn't have >> any >> >> of >> >> >>>>>>>> those issues, As long as it's just sending information, I >> >> don't >> >> >>>>>>>> have a problem. Once the database is supposed to do >> anything >> >> >>>>>>>> with it that involves changing what spectrum it reports, >> then >> >> I >> >> >>>>>>>> think we cross the line. >> >> >>>>>>>> >> >> >>>>>>>> Brian >> >> >>>>>>>> >> >> >>>>>>>> On Mar 6, 2012, at 12:28 PM, >> >> >>>>>>>> wrote: >> >> >>>>>>>> >> >> >>>>>>>>> Joel >> >> >>>>>>>>> >> >> >>>>>>>>> Indeed, the regulator has not described the process or >> >> provided >> >> >>>>>>>>> a flow diagram, so there may be some wrinkles, but we >> >> >>>>>>>>> need >> to >> >> >>>>>>>>> provide for their intent. To answer your question, the >> >> channels >> >> >>>>>>>>> that the master will use are sent in a separate message >> >> >>>>>>>>> (described in P.12 ter), that occurs after the master >> >> receives >> >> >>>>>>>>> the response to its channel request, but before the >> >> >>>>>>>>> master >> >> can >> >> >>>>>>>>> transmit. At this point, it knows what channels are >> >> available, >> >> >>>>>>>>> and which one it will use. As far as the slaves are >> >> concerned, >> >> >>>>>>>>> as they associate, the master will need to gather their >> >> details >> >> >>>>>>>>> and send further channel usage messages to the database >> >> >>>>>>>>> on their behalf. >> >> >>>>>>>>> >> >> >>>>>>>>> Regards >> >> >>>>>>>>> >> >> >>>>>>>>> Andy >> >> >>>>>>>>> >> >> >>>>>>>>> -----Original Message----- From: paws-bounces@ietf.org >> >> >>>>>>>>> [mailto:paws-bounces@ietf.org] On Behalf Of Joel M. >> Halpern >> >> >>>>>>>>> Sent: 06 March 2012 17:05 To: scott.probasco@nokia.com >Cc: >> >> >>>>>>>>> paws@ietf.org; Cheeseman,CJ,Chris,COD R; >> Dixon,JS,Johnny,COD >> >> R >> >> >>>>>>>>> Subject: Re: [paws] WGLC for >> >> >>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel >> >> >>>>>>>>> reporting >> >> >>>>>>>>> >> >> >>>>>>>>> Ahh. I think I see where the request and my >> >> >>>>>>>>> understanding divurge. If the idea here is that the >> >> >>>>>>>>> master must provide, >> in >> >> >>>>>>>>> the request, an indication of what channels it expects >> >> >>>>>>>>> to >> >> use, >> >> >>>>>>>>> I can at least understand that. I will return to >> technical >> >> >>>>>>>>> concerns in a moment. >> >> >>>>>>>>> >> >> >>>>>>>>> However, when you say "provide channel usage >> >> >>>>>>>>> information, >> in >> >> >>>>>>>>> order to evaluate interference", what that says to me is >> >> >>>>>>>>> providing, during operation, information as to what >> channels >> >> >>>>>>>>> are being used, and at what power levels. That is what >> would >> >> >>>>>>>>> be needed to analyze actual interference effects. And >> >> >>>>>>>>> that >> is >> >> >>>>>>>>> out of scope as I understand our scope. >> >> >>>>>>>>> >> >> >>>>>>>>> I do see a technical difficulty with having the master >> >> provide, >> >> >>>>>>>>> as part of either registering or requesting spectrum >> >> >>>>>>>>> information, what channels it intends to use. It >> >> >>>>>>>>> doesn;t >> >> know >> >> >>>>>>>>> what channels it intends to use. It intends to use some >> >> number >> >> >>>>>>>>> of available channels. It will figure out which ones >> >> >>>>>>>>> when >> it >> >> >>>>>>>>> is told what is available. How can it send that >> information >> >> in >> >> >>>>>>>>> the request? >> >> >>>>>>>>> >> >> >>>>>>>>> Yours, Joel >> >> >>>>>>>>> >> >> >>>>>>>>> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: >> >> >>>>>>>>>> Hi, >> >> >>>>>>>>>> >> >> >>>>>>>>>> There is a similarity here with device ID. In context >> >> >>>>>>>>>> of >> >> PAWS >> >> >>>>>>>>>> we are not concerned with why a device ID is required >> >> >>>>>>>>>> by >> a >> >> >>>>>>>>>> regulator, we accept it is a requirement from a >> >> >>>>>>>>>> regulator >> >> and >> >> >>>>>>>>>> include it to the protocol. Ofcom identifies in 3.18& >> 3.19 >> >> >>>>>>>>>> that channel usage information is required and thus we >> need >> >> >>>>>>>>>> to include this information. Since the master must >> provide >> >> >>>>>>>>>> this information prior to transmitting, PAWS will not >> >> >>>>>>>>>> function in the UK without this information and thus I >> >> >>>>>>>>>> believe channel usage information is integral to the >> channel >> >> >>>>>>>>>> request& response messaging. >> >> >>>>>>>>>> >> >> >>>>>>>>>> Kind Regards, Scott >> >> >>>>>>>>>> >> >> >>>>>>>>>> >> >> >>>>>>>>>> On 3/6/12 10:30 AM, "ext Joel M. >> >> >>>>>>>>>> Halpern" wrote: >> >> >>>>>>>>>> >> >> >>>>>>>>>>> I would draw a distinction. Ofcom regulations about >> >> >>>>>>>>>>> whitespace requests are very much relevant. Ofcom >> >> >>>>>>>>>>> regulations about notification of dynamic behavior >> (which >> >> >>>>>>>>>>> spectrum is being used) are not in scope as I >> >> >>>>>>>>>>> understand the earlier discussions, particularly the >> >> >>>>>>>>>>> chartering discussions. >> >> >>>>>>>>>>> >> >> >>>>>>>>>>> Yours, Joel >> >> >>>>>>>>>>> >> >> >>>>>>>>>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: >> >> >>>>>>>>>>>> >> >> >>>>>>>>>>>> The ofcom requirements are very much relevant to the >> >> >>>>>>>>>>>> scope of the PAWS WG. The only other regulatory >> >> >>>>>>>>>>>> requirements that we have today is the FCC. Ofcom >> >> >>>>>>>>>>>> requirements are a good addition to the set. >> >> >>>>>>>>>>>> >> >> >>>>>>>>>>>> -Raj >> >> >>>>>>>>>>>> >> >> >>>>>>>>>>>> On 3/6/12 10:03 AM, "ext >> >> >>>>>>>>>>>> andy.sago@bt.com" wrote: >> >> >>>>>>>>>>>> >> >> >>>>>>>>>>>>> Hi Joel >> >> >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> There's no language I can find in the charter that >> >> >>>>>>>>>>>>> explicitly puts this out of scope. On the other >> >> >>>>>>>>>>>>> hand, the charter says that the group will "consider >> >> >>>>>>>>>>>>> input from regulatory entities", and this is one of >> >> >>>>>>>>>>>>> the requirements from Ofcom that they have just >published. >> >> >>>>>>>>>>>>> The protocol will be worthless for the UK if it >> >> >>>>>>>>>>>>> omits some requirements. >> >> >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> Regards >> >> >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> Andy >> >> >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> -----Original Message----- From: Joel M. Halpern >> >> >>>>>>>>>>>>> [mailto:jmh@joelhalpern.com] Sent: 06 March 2012 >> >> >>>>>>>>>>>>> 15:53 >> >> >>>>>>>>>>>>> To: Sago,AJ,Andy,COD R Cc: paws@ietf.org; >> >> >>>>>>>>>>>>> Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for >> >> >>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: >> channel >> >> >>>>>>>>>>>>> reporting >> >> >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> As I understand, the information you are asking for >> >> >>>>>>>>>>>>> is explicitly out of scope for the working group. >> >> >>>>>>>>>>>>> Yours, Joel >> >> >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >> >> >>>>>>>>>>>>>> All >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Comparing the draft with the Ofcom requirements at >> >> >>>>>>>>>>>>>> http://www.cept.org/Documents/se- >> >> >>>>> 43/4161/SE43(12)Info03_Draft-UK-r >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> >>>>> egul >> >> >>>>>>>>>>>>>> atory-requirements-for-white-space-devices-in-the- >> UHF- >> >> TV- >> >> >>>>> band, >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> >>>>> I believe the WG draft is deficient in the area of reporting >> >> >>>>>>>>>>>>>> frequencies and powers actually used by masters and >> >> >>>>>>>>>>>>>> slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom >> >> >>>>>>>>>>>>>> intends to collect this data to assesses the impact >> >> >>>>>>>>>>>>>> of aggregate interference into other services. It >> >> >>>>>>>>>>>>>> would also provide usage information (frequency in >> >> >>>>>>>>>>>>>> use) that would inform the operation of a kill >> >> >>>>>>>>>>>>>> switch capability. I suggest this deficiency can be >> >> >>>>>>>>>>>>>> remedied with the following changes: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> New P requirements (probably best placed following >> >> >>>>>>>>>>>>>> P.12): >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> P.12bis: The protocol MUST support a channel usage >> >> >>>>>>>>>>>>>> message from the slave device to the master device. >> >> >>>>>>>>>>>>>> The channel usage message MUST include parameters >> >> >>>>>>>>>>>>>> as required by local regulatory requirement. These >> >> >>>>>>>>>>>>>> parameters MAY include device ID, manufacturer's >> >> >>>>>>>>>>>>>> serial number, channel usage and power level >> >> >>>>>>>>>>>>>> information. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> P.12ter: The protocol MUST support a channel usage >> >> >>>>>>>>>>>>>> message from the master device to the database. >> >> >>>>>>>>>>>>>> The channel usage message MUST include parameters >> >> >>>>>>>>>>>>>> as required by local regulatory requirement for the >> >> >>>>>>>>>>>>>> master and its associated slaves. These parameters >> >> >>>>>>>>>>>>>> MAY include device ID, manufacturer's serial >> >> >>>>>>>>>>>>>> number, channel usage and power level information. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> P.12qua: The protocol MUST support a channel usage >> >> >>>>>>>>>>>>>> message acknowledgement. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> New O requirements (probably best placed following >> >> >>>>>>>>>>>>>> O13): >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> O.13bis: According to local regulatory policy, >> >> >>>>>>>>>>>>>> after connecting to a master device's radio network >> >> >>>>>>>>>>>>>> a slave device MAY inform the master device of the >> >> >>>>>>>>>>>>>> actual channel usage. The slave MUST include >> >> >>>>>>>>>>>>>> parameters required by local regulatory policy, e.g. >> >> >>>>>>>>>>>>>> device ID, manufacturer's serial number, channel >> >> >>>>>>>>>>>>>> usage and power level information. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> O.13ter: According to local regulatory policy, a >> >> >>>>>>>>>>>>>> master device MAY inform the database of the actual >> >> >>>>>>>>>>>>>> channel usage of the master and its slaves. The >> >> >>>>>>>>>>>>>> master MUST include parameters required by local >> >> >>>>>>>>>>>>>> regulatory policy, e.g. device ID, manufacturer's >> >> >>>>>>>>>>>>>> serial number, channel usage and power level >> >> >>>>>>>>>>>>>> information of the master and its slaves. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> New steps could be introduced into one or more use >> >> >>>>>>>>>>>>>> cases to cover these Ofcom requirements, e.g. new >> >> >>>>>>>>>>>>>> steps 6bis and 9bis in the hotspot use case at >> >> >>>>>>>>>>>>>> 4.2.1: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 6bis. Prior to initiating transmission, if required >> >> >>>>>>>>>>>>>> by local regulation, the master/AP informs the >> >> >>>>>>>>>>>>>> database of the channel and power level it has >> >> >>>>>>>>>>>>>> chosen. This is repeated for each slave that >> >> >>>>>>>>>>>>>> associated with the master. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 9bis. Prior to initiating transmission, if required >> >> >>>>>>>>>>>>>> by local regulation, the slave informs the >> >> >>>>>>>>>>>>>> master/AP of the channel and power level it has >> >> >>>>>>>>>>>>>> chosen, and the master/AP relays this information >> >> >>>>>>>>>>>>>> to the >database. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> - end of new text - >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> For information, for those not accessing the url in >> >> >>>>>>>>>>>>>> the first paragraph of this email, the full Ofcom >> >> >>>>>>>>>>>>>> requirements leading to this new PAWS text are as >> >> >>>>>>>>>>>>>> follows: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 3.18 After receiving instructions from a WSDB in >> >> >>>>>>>>>>>>>> relation to the maximum permitted EIRPs over the >> >> >>>>>>>>>>>>>> DTT channels, and prior to initiating transmissions >> >> >>>>>>>>>>>>>> within the UHF TV band, a master WSD must >> >> >>>>>>>>>>>>>> communicate to the WSDB the following information: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 3.18.1 The lower and upper frequency boundaries^13 >> >> >>>>>>>>>>>>>> of the in-block emissions of the master WSD, and >> >> >>>>>>>>>>>>>> those of the in-block emissions of its associated >> >> >>>>>>>>>>>>>> slaves. A lower frequency will be specified as (470 >> >> >>>>>>>>>>>>>> + 8k + >> >> >>>>>>>>>>>>>> 0.2n) MHz, with the corresponding upper frequency >> >> >>>>>>>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3?4 k >3?4 >> >> >>>>>>>>>>>>>> 39, 0 3?4 n 3?4 39, 1 3?4 m 3?4 40, and n< m. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 3.18.2 The maximum in-block EIRP spectral densities >> >> >>>>>>>>>>>>>> (in dBm/(0.2 MHz)) that the master WSD, and its >> >> >>>>>>>>>>>>>> associated slaves, actually radiate between each >> >> >>>>>>>>>>>>>> reported lower frequency boundary and its >> >> >>>>>>>>>>>>>> corresponding upper frequency boundary. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Footnote 13 states: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> The use of upper and lower frequency boundaries >> >> >>>>>>>>>>>>>> (defined over a 200 kHz raster) allows a WSDB to >> >> >>>>>>>>>>>>>> collect more granular information with regards to >> >> >>>>>>>>>>>>>> the usage of the frequency resource by narrowband >> >> >>>>>>>>>>>>>> WSD technologies. The upper and lower frequencies >> >> >>>>>>>>>>>>>> of a boundary pair do not straddle a DTT channel >boundary. >> >> >>>>>>>>>>>>>> Note that a WSD may transmit over multiple, >> >> >>>>>>>>>>>>>> non-contiguous, whole DTT channels or fractions of >> >> >>>>>>>>>>>>>> DTT channels. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 3.19 A master WSD must be able to receive the >> >> >>>>>>>>>>>>>> following information^14 from a WSDB: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in the >> >> >>>>>>>>>>>>>> context of 3.18, that the reported information on >> >> >>>>>>>>>>>>>> the DTT channels and EIRP spectral densities >> >> >>>>>>>>>>>>>> actually used by the master and slave WSDs were >> >> >>>>>>>>>>>>>> received successfully by the WSDB^18 ]. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Footnote 14 states: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 14 While the communication of some of this >> >> >>>>>>>>>>>>>> information from a WSDB to a master WSD is >> >> >>>>>>>>>>>>>> optional, master WSDs must be able to receive and >> >> >>>>>>>>>>>>>> interpret these. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Footnote 18 states: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 18 This forms part of a handshake protocol and may >> >> >>>>>>>>>>>>>> be an area where industry could harmonise without >> >> >>>>>>>>>>>>>> the need for an explicit requirement in the >regulations. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Regards >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Andy >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> *From:*paws-bounces@ietf.org >> >> >>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] *On Behalf Of >> >> >>>>>>>>>>>>>> *Gabor.Bajko@nokia.com *Sent:* 05 March 2012 19:46 >> >> >>>>>>>>>>>>>> *To:* paws@ietf.org *Subject:* [paws] WGLC for >> >> >>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> The authors of the use cases and requirements draft >> >> >>>>>>>>>>>>>> have just posted a new version of the draft and >> >> >>>>>>>>>>>>>> indicated that there are no unresolved >> >> >>>>>>>>>>>>>> comments/issues they are aware of. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Therefore, I'd like to initiate a WG Last Call for >> >> >>>>>>>>>>>>>> comments on >> >> >>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-paws >> >> >>>>>>>>>>>>>> - >> >> problem- >> >> >>>>> stmt-u >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> >>>>> seca >> >> >>>>>>>>>>>>>> ses-rqmts-03.txt >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Please review the draft and send your comments to >> >> >>>>>>>>>>>>>> the list by March 20th, 2012. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> If you review the draft and have no comments, send >> >> >>>>>>>>>>>>>> a note to the list that the draft is good as it is, >> >> >>>>>>>>>>>>>> we need these notes as much as we need the actual >> >> >>>>>>>>>>>>>> comments. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Thanks, Gabor >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> > >> >> > _______________________________________________ >> >> > paws mailing list >> >> > paws@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/paws >> >> > >> >> _______________________________________________ >> >> paws mailing list >> >> paws@ietf.org >> >> https://www.ietf.org/mailman/listinfo/paws >> >> >> >> _______________________________________________ >> >> paws mailing list >> >> paws@ietf.org >> >> https://www.ietf.org/mailman/listinfo/paws >> >_______________________________________________ >> >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 > >________________________________ > >*********************************************************************** >* >****************************************** >For more information visit www.ofcom.org.uk > >This email (and any attachments) is confidential and intended for the >use of the addressee only. > >If you have received this email in error please notify the originator >of the message and delete it from your system. > >This email has been scanned for viruses. However, you open any >attachments at your own risk. > >Any views expressed in this message are those of the individual sender >and do not represent the views or opinions of Ofcom unless expressly >stated otherwise. >*********************************************************************** >* >****************************************** >_______________________________________________ >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 ________________________________ ***************************************************************************= *************************************** 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. ***************************************************************************= *************************************** From Gabor.Bajko@nokia.com Fri Mar 9 08:15:05 2012 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 571D621F8686 for ; Fri, 9 Mar 2012 08:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.625 X-Spam-Level: X-Spam-Status: No, score=-3.625 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4, 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 h4rThnzIB1eW for ; Fri, 9 Mar 2012 08:15:02 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 485D021F85E6 for ; Fri, 9 Mar 2012 08:15:00 -0800 (PST) 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 q29GEwgv009840 for ; Fri, 9 Mar 2012 18:14:58 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 18:14:57 +0200 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.157]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0355.003; Fri, 9 Mar 2012 17:14:56 +0100 From: To: Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting Thread-Index: AQHM/ZcWE2wXdG2HTUy1x0wfYncSB5ZhKQIAgACcqACAAErcAIAAEpRg Date: Fri, 9 Mar 2012 16:14:56 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601E1DF4C@008-AM1MPN1-006.mgdnok.nokia.com> References: , <7BAC95F5A7E67643AAFB2C31BEE662D0157A034B37@SC-VEXCH2.marvell.com> <9983D74B649EED43B27BF353837B20C57D94596B@WOK-INTRA-EXC02.intra.ofcom.local> In-Reply-To: <9983D74B649EED43B27BF353837B20C57D94596B@WOK-INTRA-EXC02.intra.ofcom.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.21.95.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Mar 2012 16:14:57.0851 (UTC) FILETIME=[C58230B0:01CCFE0F] X-Nokia-AV: Clean Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 16:15:05 -0000 This mail thread has a dozen recipients in the To: and CC: fields and the i= etf mail system is complaining about that, requiring me to manually authori= ze each and every email. May I ask you all to refrain from using the 'reply-all' button when replyin= g to these emails, and send your reply simply to 'paws@ietf.org'? Thanks, Gabor -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Andrew Gowans Sent: Friday, March 09, 2012 8:04 AM To: chris.cheeseman@bt.com; paul@marvell.com; sdas@appcomsci.com; Siew Yoon= Tan; JuanCarlos.Zuniga@InterDigital.com; Patil Basavaraj (Nokia-CIC/Dallas= ); gerald.chouinard@sympatico.ca; jmh@joelhalpern.com; Probasco Scott (Noki= a-CIC/Dallas) Cc: paws@ietf.org; presnick@qualcomm.com; Reza Karimi; johnny.dixon@bt.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03= :channel reporting All I agree with Chris, the aim of the return information is to collect the= max power levels and channels/frequency ranges that the master and its ass= ociated slaves are using. This information in con-junction with the other i= nformation collected (e.g. technology ID) may be used to estimate the inter= ference potential to the incumbent services in any given area. There is no= intention here to have the device indicate to the WSDB its configuration a= t any given instant. Regards Andy -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of chr= is.cheeseman@bt.com Sent: 09 March 2012 11:36 To: paul@marvell.com; sdas@appcomsci.com; Siew Yoon Tan; JuanCarlos.Zuniga@= InterDigital.com; Basavaraj.Patil@nokia.com; gerald.chouinard@sympatico.ca;= jmh@joelhalpern.com; scott.probasco@nokia.com Cc: paws@ietf.org; presnick@qualcomm.com; Reza Karimi; johnny.dixon@bt.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03= :channel reporting Hi My reading of the UK regulatory requirements that Ofcom has made available = is that the Acknowledgement message that must be communicated back to the d= atabase from the white space device is simply the frequency range (or range= s) and maximum eirp density that the device intends to use (a subset of wha= t it would have been offered by the database). I don't believe there is any= intent to limit modulation schemes etc. as part of this exchange. This see= ms a relatively straightforward requirement and the PAWS protocol should ac= commodate this if it is to be relevant for the UK regulatory environment. Regards, Chris -----Original Message----- From: Paul Lambert [mailto:paul@marvell.com] Sent: 09 March 2012 02:15 To: Das, Subir; 'Siew Yoon Tan'; Zuniga, Juan Carlos; Basavaraj.Patil@nokia= .com; gerald.chouinard@sympatico.ca; jmh@joelhalpern.com; scott.probasco@no= kia.com Cc: paws@ietf.org; presnick@qualcomm.com; Reza Karimi; Dixon,JS,Johnny,COD = R; Cheeseman,CJ,Chris,COD R Subject: RE: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03= :channel reporting >I have a question here. Is it really an acknowledgement or we would=20 >like to see a kind of notification message that includes channel, and=20 >other parameters? What if it's multiple channels? What happens if the device adapts and chan= ges between modulation technique or bandwidth? Does every change over the = air need to be indicated to the GDB? This Channel acknowledgement does not seem useful and would limit real worl= d behaviors (like channel and modulation adaptation). If viewed as a potential regulatory requirement - does this imply we need t= o parameterize the protocol to have different behaviors in different region= s? Paul > >Regards, >_Subir > >-----Original Message----- >From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of=20 >Siew Yoon Tan >Sent: Thursday, March 08, 2012 4:06 PM >To: Zuniga, Juan Carlos; Basavaraj.Patil@nokia.com;=20 >gerald.chouinard@sympatico.ca; jmh@joelhalpern.com;=20 >scott.probasco@nokia.com >Cc: paws@ietf.org; presnick@qualcomm.com; Reza Karimi;=20 >johnny.dixon@bt.com; chris.cheeseman@bt.com >Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >rqmts-03:channel reporting > >Dear All, > >Regarding Ofcom's requirement to have a return channel as part of the=20 >protocol between the WSD and WSDB, I would like to confirm to following=20 >sequence of messaging > >Channel request >Channel response >Channel acknowledgement > >which was raised in an earlier email to this list. > >Our view is that it would be beneficial to define the protocol between=20 >WSD and WSDB that supports this requirement even though how the=20 >information could be used is still subject to discussion in the UK. > > >Best regards, > >Siew Yoon > > >________________________________________ >From: paws-bounces@ietf.org [paws-bounces@ietf.org] on behalf of=20 >Zuniga, Juan Carlos [JuanCarlos.Zuniga@InterDigital.com] >Sent: 08 March 2012 20:41 >To: Basavaraj.Patil@nokia.com; gerald.chouinard@sympatico.ca;=20 >jmh@joelhalpern.com; scott.probasco@nokia.com >Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com;=20 >chris.cheeseman@bt.com >Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >rqmts-03:channel reporting > >Hi Raj, > >I was reusing the language used from Gerald (which I know is familiar=20 >to people working on IEEE 802 WS groups): > >>> [GC] You got it. This would be useless for spectrum regulators. One=20 >>> should realize that, from the spectrum regulator's point of view,=20 >>> the second and third messages could be iterated upon to optimize the=20 >>> spectrum use. >>> Knowing >>> what channels the systems in an area are using, the spectrum=20 >>> regulators and/or other entities such as those taking care of=20 >>> coexistence could use the database in near-real-time to iterate on=20 >>> the two last messages to reduce the range of channels that some=20 >>> systems may use once they know precisely what channels are being=20 >>> used in the area. The PAWS protocol would carry the information back=20 >>> and forth but would not be involved in such spectrum use optimization. > >Having said that, I have no issue sticking to the WSDB terminology. I=20 >like keeping things simple :) > >JC > >> -----Original Message----- >> From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] >> Sent: Thursday, March 08, 2012 3:33 PM >> To: Zuniga, Juan Carlos; gerald.chouinard@sympatico.ca;=20 >> jmh@joelhalpern.com; scott.probasco@nokia.com >> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com;=20 >> chris.cheeseman@bt.com >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >> rqmts-03:channel reporting >> >> >> Hi JC, >> >> Where/why did the coexistence manager come into the picture? Your=20 >> comment about "communicating back to the WSDB/coexistence manager" >> may result in further misunderstanding. If we simply stick to to WSDB=20 >> I think we are okay. >> >> -Raj >> >> On 3/8/12 2:25 PM, "ext Zuniga, Juan Carlos" >> wrote: >> >> >So, from Gerald and Andy's comments, it seems like from the point of >> view >> >of (at least) two regulatory entities it is important for the=20 >> >protocol >> to >> >allow communicating back to the WSDB/coexistence manager the actual=20 >> >channel usage after the first query is made. >> > >> >This is to me a very clear requirement. >> > >> >The actual messages/IEs that would carry this information should be=20 >> >discussed as part of the solution document, and not the requirements. >> > >> >JC >> > >> >> -----Original Message----- >> >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On=20 >> >> Behalf >> Of >> >> Gerald Chouinard >> >> Sent: Thursday, March 08, 2012 1:59 PM >> >> To: 'Joel M. Halpern'; scott.probasco@nokia.com >> >> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com;=20 >> >> chris.cheeseman@bt.com >> >> Subject: Re: [paws] WGLC for >> >> draft-ietf-paws-problem-stmt-usecases- >> >> rqmts-03:channel reporting >> >> >> >> Joel, Scott, >> >> >> >> Interesting discussion! See my comments in line below. >> >> >> >> Gerald >> >> >> >> -----Original Message----- >> >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On=20 >> >> Behalf >> Of >> >> Joel >> >> M. Halpern >> >> Sent: Thursday, 08 March, 2012 13:17 >> >> To: scott.probasco@nokia.com >> >> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com;=20 >> >> chris.cheeseman@bt.com >> >> Subject: Re: [paws] WGLC for >> >> draft-ietf-paws-problem-stmt-usecases- >> >> rqmts-03: >> >> channel reporting >> >> >> >> So why won't the device simply say "I will use all of this?" >> >> [GC] This would defeat the purpose of the acknowledgement message. >> >> After all, that way it needs to do less work with the database. >> >> And >> it >> >> can change frequencies when it wants. >> >> Given that the stated goal of the Ofcom requriement was to be able >> to >> >> analyze interference effects, it seems that this will not actually >> lead >> >> to them getting what they want, even if it does comply with the=20 >> >> regulations. >> >> [GC] You got it. This would be useless for spectrum regulators. >> >> One should realize that, from the spectrum regulator's point of=20 >> >> view, the >> second >> >> and >> >> third messages could be iterated upon to optimize the spectrum use. >> >> Knowing >> >> what channels the systems in an area are using, the spectrum >> regulators >> >> and/or other entities such as those taking care of coexistence=20 >> >> could use the database in near-real-time to iterate on the two=20 >> >> last messages to reduce the range of channels that some systems=20 >> >> may use once they know precisely what channels are being used in the = area. >> >> The PAWS protocol would carry >> the >> >> information back and forth but would not be involved in such >> spectrum >> >> use >> >> optimization. >> >> >> >> Yours, >> >> joel >> >> >> >> On 3/8/2012 1:09 PM, scott.probasco@nokia.com wrote: >> >> > Hi Peter, >> >> > >> >> > Answers below. >> >> > >> >> > Kind Regards, >> >> > Scott >> >> > >> >> > On 3/8/12 11:39 AM, "ext Peter Saint-Andre" >> >> wrote: >> >> > >> >> >> Hi Scott, I have two clarifying questions: >> >> >> >> >> >> 1. Does the device know, when it receives the channel response, >> >> which >> >> >> channel it will actually use? >> >> > Scott->This is all new and I am not aware of any existing >> >> implementations. >> >> > I would argue that the device must decide what channel(s) it=20 >> >> > will >> use >> >> when >> >> > it receives the channel response. >> >> [GC] Agree with Scott but this is only a portion of the >> considerations. >> >> If a >> >> device was to operate on its own, this would be true but a=20 >> >> communication device usually implies at least 2 devices to=20 >> >> communicate. Hence, the choice of the channel to be used will need=20 >> >> to be negotiated between the two devices before a choice can be=20 >> >> made. The chosen channel will belong to the >> set >> >> of >> >> available channels that is common to both devices. Remember that >> some >> >> channels may be available at one device and not at the other=20 >> >> because >> of >> >> their geolocation or other reason. Extending this concept to a=20 >> >> star network topology, the channel that will be selected by this=20 >> >> network will >> have >> >> to >> >> belong to the set of channels that are available to all devices. >> Each >> >> device >> >> will not be able to decide by itself which channel it wants to use. >> >> >> >> This is why in such a star topology, it makes sense that the slave=20 >> >> devices to a base station or access point be represented by the=20 >> >> base station acting as the master on their behalf to query the=20 >> >> database and receive the list of available channels (and/or=20 >> >> maximum EIRP per channel). It is then the responsibility of the=20 >> >> base station to identify the set of available channels that is=20 >> >> common for itself and all its slaves to decide on the >> channel >> >> that >> >> the network will use. As you can see, in this case, there is no=20 >> >> need for each slave to receive its list of available channels. On=20 >> >> its own, it would not know what to do with it. The only thing that=20 >> >> needs to be sent >> from >> >> the >> >> master device to its slaves is the resulting operating channel. >> >> >> >> I a more sophisticated operation, the master device may add one or=20 >> >> a few backup channels extracted from the common set of available=20 >> >> channel >> to >> >> the >> >> message going to its slave so that if a change in channel >> availability >> >> occurs, an instantaneous switch to the next backup channel can be >> made >> >> without any further signaling, thus providing for a channel switch >> that >> >> is >> >> transparent to the user. It is the scheme that has been included=20 >> >> in >> the >> >> IEEE >> >> 802.22-2011 Standard. This is why I don't believe that PAWS should >> get >> >> involved in defining this signaling between the base station and=20 >> >> its slaves devices. >> >> >> >> >> >> 2. If the device then uses another channel or a different >> channel, >> >> does >> >> >> it need to report that change to the database? >> >> > Scott->My interpretation of section 3.18 is that the device can >> only >> >> > transmit within the upper& lower frequencies returned in the=20 >> >> > acknowledgment. I do not (quickly) find any reference in the >> >> requirements >> >> > to changing channels. Thus operationally it could be that the >> channel >> >> > request process must be repeated before the device can use a >> >> different >> >> > channel (frequencies). >> >> [GC] If the process involves 2 messages, then, the device and its=20 >> >> associated devices could change channels at will as long as all=20 >> >> these channels belong to the set of available channel. However, if=20 >> >> the third message is added, it would make sense that the master=20 >> >> device reports to the database any channel change that would occur=20 >> >> to the database, otherwise, the status of >> the >> >> spectrum occupation would be wrong at any moment and would be >> useless >> >> for >> >> the purpose of any spectrum usage optimization such as coexistence. >> >> >> >> >> >> Thanks! >> >> >> >> >> >> Peter >> >> >> >> >> >> On 3/8/12 10:17 AM, scott.probasco@nokia.com wrote: >> >> >>> Hi, >> >> >>> >> >> >>> The point from Brian is very relevant: >> >> >>> >> >> >>> Channel request >> >> >>> Channel response >> >> >>> Channel acknowledgement >> >> >>> >> >> >>> What Ofcom does with the information in the acknowledgement=20 >> >> >>> does >> >> not >> >> >>> matter. As the regulator in UK, they write rules that must be >> >> followed >> >> >>> in >> >> >>> order to operate a whitespace radio in the UK. I believe the >> scope >> >> of >> >> >>> the >> >> >>> WG must be focused on a working solution. If this is simple >> channel >> >> >>> request& response in one regulator's domain, PAWS can support >> >> this. If >> >> >>> it >> >> >>> means a channel request, response and acknowledgement in=20 >> >> >>> another regulator's domain, PAWS can support this. As a=20 >> >> >>> participating >> >> member of >> >> >>> the work group, I believe the scope should be basic working >> >> solution, >> >> >>> not >> >> >>> limited to a specific number of messages. >> >> >>> >> >> >>> Kind Regards, >> >> >>> Scott >> >> >>> >> >> >>> >> >> >>> >> >> >>> On 3/8/12 11:11 AM, "ext Zuniga, Juan Carlos" >> >> >>> wrote: >> >> >>> >> >> >>>> Peter, Nancy, >> >> >>>> >> >> >>>> I agree should design a protocol with the best of our current=20 >> >> >>>> knowledge, and that should be accounting for all the known=20 >> >> >>>> regulations at >> >> present >> >> >>>> time. We should not limit the scope with the purpose of >> designing >> >> a >> >> >>>> protocol 'faster'. Our goal is not only to design a WSDB >> protocol. >> >> Our >> >> >>>> goal is to design a WSDB protocol that is USEFUL to the >> community. >> >> >>>> >> >> >>>> The charter does state that >> >> >>>> >> >> >>>> "...the group should also reach out to other potential=20 >> >> >>>> "customers" for a white space database access method and >> consider >> >> input >> >> >>> >from regulatory entities that are involved in the=20 >> >> >>> >specification >> of >> >> the >> >> >>>> rules for secondary use of spectrum in specific radio bands. " >> >> >>>> >> >> >>>> I think that is exactly what we are doing now. >> >> >>>> >> >> >>>> Regarding whether the types of requirements belong to #1 or=20 >> >> >>>> #2, >> I >> >> >>>> believe >> >> >>>> it is more of #1 type, as the information to be exchanged=20 >> >> >>>> would >> be >> >> >>>> known >> >> >>>> after the initial query/response. >> >> >>>> >> >> >>>> If we know it today, I see no reason why we should not work=20 >> >> >>>> on >> it >> >> in >> >> >>>> the >> >> >>>> first phase of the work. >> >> >>>> >> >> >>>> Regards, >> >> >>>> >> >> >>>> Juan Carlos >> >> >>>> >> >> >>>>> -----Original Message----- >> >> >>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org]=20 >> >> >>>>> On >> >> Behalf >> >> >>>>> Of >> >> >>>>> Peter Saint-Andre >> >> >>>>> Sent: Thursday, March 08, 2012 11:59 AM >> >> >>>>> To: Nancy Bravin >> >> >>>>> Cc: paws@ietf.org; johnny.dixon@bt.com; >> chris.cheeseman@bt.com; >> >> Pete >> >> >>>>> Resnick >> >> >>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- >> >> usecases- >> >> >>>>> rqmts-03: channel reporting >> >> >>>>> >> >> >>>>> Hi Nancy, >> >> >>>>> >> >> >>>>> You are absolutely right that different locales will have >> >> different >> >> >>>>> rules and requirements. We need to understand those, and=20 >> >> >>>>> work >> to >> >> >>>>> address >> >> >>>>> them if possible (although we don't necessarily need to >> address >> >> them >> >> >>>>> all >> >> >>>>> at the same time). I see several kinds of requirements: >> >> >>>>> >> >> >>>>> 1. Some requirements might lead to features beyond the >> >> query/response >> >> >>>>> protocol we've envisioned so far. One example might be real- >> time >> >> >>>>> reporting about the channels that a device is actually using. >> In >> >> my >> >> >>>>> opinion, it would be best to handle those in the next phase=20 >> >> >>>>> of >> >> work, >> >> >>>>> because as far as I can see they are outside the scope of=20 >> >> >>>>> our >> >> charter. >> >> >>>>> >> >> >>>>> 2. Some requirements might be handled through by defining >> >> additional >> >> >>>>> fields that can be included in the query or response. We >> >> definitely >> >> >>>>> planned for that when working on the charter with the IESG: >> >> >>>>> >> >> >>>>> In addition, the particular >> >> >>>>> data exchanged between a device and a database might=20 >> >> >>>>> 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. >> >> >>>>> Therefore, the database access method and the >> query/response >> >> data >> >> >>>>> formats that are exchanged using that method need to be >> >> designed >> >> for >> >> >>>>> extensibility rather than being tied to any specific >> spectrum, >> >> >>>>> country, or phy/mac/air interface. >> >> >>>>> >> >> >>>>> It's unclear to me right now if the Ofcom requirement fits >> into >> >> #1 or >> >> >>>>> #2, which is why we're having this discussion. :) >> >> >>>>> >> >> >>>>> Peter >> >> >>>>> >> >> >>>>> On 3/7/12 8:17 PM, Nancy Bravin wrote: >> >> >>>>>> Peter and all, >> >> >>>>>> >> >> >>>>>> I agree that it is important to revisit now, so that in the >> >> future, >> >> >>>>>> it will be easy to align things in their proper place. >> >> >>>>>> Every >> >> country >> >> >>>>>> may have different regulations, spectrum, policy and what=20 >> >> >>>>>> responsibility is in the domain of the system, and what=20 >> >> >>>>>> comes >> >> under >> >> >>>>>> the PAWS charter is important. Maybe some separation might >> be >> >> >>>>>> possible, and dividing and clarifying issues now will help=20 >> >> >>>>>> in >> >> the >> >> >>>>>> future. Certainly it seems that the FCC may change some >> rules, >> >> and >> >> >>>>>> we know that Ofcom is not yet finished with their >> regulations. >> >> Canada >> >> >>>>>> has their own, and other countries are working on this as >> well. >> >> Just >> >> >>>>>> a thought...Sharing is a realistic goal...as is off >> loading... >> >> Or you >> >> >>>>>> slim line and every 6 months decide what to incorporate in >> the >> >> >>>>>> protocol based on new information, new ideas, new=20 >> >> >>>>>> innovation >> new >> >> >>>>>> regulations and maybe spend more time than you could if >> >> addressed >> >> >>>>>> now. >> >> >>>>>> >> >> >>>>>> That way you leave the door open and outside of referencing >> what >> >> is >> >> >>>>>> known today, by referencing regulations i.e. Ofcom, FCC, >> >> Industry >> >> >>>>>> Canada etc as of XX-XX-XXXX date. Out of scope not=20 >> >> >>>>>> something >> we >> >> know >> >> >>>>>> enough about to say at this point, In my opinion. >> >> >>>>>> >> >> >>>>>> My 2 cents.. >> >> >>>>>> >> >> >>>>>> Sincerely, Nancy >> >> >>>>>> >> >> >>>>>> On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote: >> >> >>>>>> >> >> >>>>>>> >> >> >>>>>>> >> >> >>>>>>> As your responsible Area Director (until March 28, when=20 >> >> >>>>>>> Pete Resnick will take over from me), I have reviewed this >> thread. >> >> >>>>>>> >> >> >>>>>>> In my opinion (I am happy to be proven wrong), this new >> >> requirement >> >> >>>>>>> goes beyond what the charter defined as the scope of this >> >> working >> >> >>>>>>> group, which was to enable a device to discover the white >> space >> >> >>>>>>> available to it in its current location. Reporting usage >> back >> >> to >> >> >>>>>>> the database is simply not mentioned in the charter. >> >> >>>>>>> >> >> >>>>>>> Earlier in this thread, Andy Sago wrote: >> >> >>>>>>> >> >> >>>>>>> There's no language I can find in the charter that >> explicitly >> >> puts >> >> >>>>>>> this out of scope. >> >> >>>>>>> >> >> >>>>>>> An IETF charter defines what the working group shall work >> on. >> >> Many >> >> >>>>>>> interesting features could be developed here. However, it=20 >> >> >>>>>>> is >> >> not >> >> >>>>>>> the job of the charter to mention explicitly that each of >> those >> >> >>>>>>> interesting features is out of scope. >> >> >>>>>>> >> >> >>>>>>> The charter does say: >> >> >>>>>>> >> >> >>>>>>> Once the device learns of the available white space (e.g., >> in a >> >> TV >> >> >>>>>>> white space implementation, the list of available channels >> at >> >> that >> >> >>>>>>> location), it can then select one of the bands from the=20 >> >> >>>>>>> list >> >> and >> >> >>>>>>> begin to transmit and receive on the selected band. >> >> >>>>>>> >> >> >>>>>>> This text might have assumed that no further communication >> or >> >> >>>>>>> authorization was required in order to select one of the >> bands >> >> from >> >> >>>>>>> the list and then transmit/receive. Perhaps that=20 >> >> >>>>>>> assumption >> was >> >> >>>>>>> mistaken. If so, it would be good to have a discussion=20 >> >> >>>>>>> about >> >> that, >> >> >>>>>>> so we can determine if we need to revisit the assumptions=20 >> >> >>>>>>> we >> >> made >> >> >>>>>>> early on. If in fact we made some faulty or limited >> >> assumptions, >> >> >>>>>>> then let's get that out in the open. >> >> >>>>>>> >> >> >>>>>>> Peter >> >> >>>>>>> >> >> >>>>>>> On 3/7/12 9:40 AM, Rosen, Brian wrote: >> >> >>>>>>>> I'd also suggest that >> our >> >> >>>>>>>> charter limitation is really support for sharing of >> whitespace >> >> by >> >> >>>>>>>> whitespace devices. Reporting what you use is not=20 >> >> >>>>>>>> sharing, >> >> it's >> >> >>>>>>>> just data gathering. >> >> >>>>>>>> >> >> >>>>>>>> The point of excluding sharing was to eliminate the >> >> complexities >> >> >>>>>>>> of what constituted fairness, and what kinds of >> communication >> >> >>>>>>>> might be needed between databases, where more than one >> could >> >> >>>>>>>> supply available whitespace in a band. This doesn't have >> any >> >> of >> >> >>>>>>>> those issues, As long as it's just sending information, I >> >> don't >> >> >>>>>>>> have a problem. Once the database is supposed to do >> anything >> >> >>>>>>>> with it that involves changing what spectrum it reports, >> then >> >> I >> >> >>>>>>>> think we cross the line. >> >> >>>>>>>> >> >> >>>>>>>> Brian >> >> >>>>>>>> >> >> >>>>>>>> On Mar 6, 2012, at 12:28 PM,=20 >> >> >>>>>>>> wrote: >> >> >>>>>>>> >> >> >>>>>>>>> Joel >> >> >>>>>>>>> >> >> >>>>>>>>> Indeed, the regulator has not described the process or >> >> provided >> >> >>>>>>>>> a flow diagram, so there may be some wrinkles, but we=20 >> >> >>>>>>>>> need >> to >> >> >>>>>>>>> provide for their intent. To answer your question, the >> >> channels >> >> >>>>>>>>> that the master will use are sent in a separate message=20 >> >> >>>>>>>>> (described in P.12 ter), that occurs after the master >> >> receives >> >> >>>>>>>>> the response to its channel request, but before the=20 >> >> >>>>>>>>> master >> >> can >> >> >>>>>>>>> transmit. At this point, it knows what channels are >> >> available, >> >> >>>>>>>>> and which one it will use. As far as the slaves are >> >> concerned, >> >> >>>>>>>>> as they associate, the master will need to gather their >> >> details >> >> >>>>>>>>> and send further channel usage messages to the database=20 >> >> >>>>>>>>> on their behalf. >> >> >>>>>>>>> >> >> >>>>>>>>> Regards >> >> >>>>>>>>> >> >> >>>>>>>>> Andy >> >> >>>>>>>>> >> >> >>>>>>>>> -----Original Message----- From: paws-bounces@ietf.org=20 >> >> >>>>>>>>> [mailto:paws-bounces@ietf.org] On Behalf Of Joel M. >> Halpern >> >> >>>>>>>>> Sent: 06 March 2012 17:05 To: scott.probasco@nokia.com >Cc: >> >> >>>>>>>>> paws@ietf.org; Cheeseman,CJ,Chris,COD R; >> Dixon,JS,Johnny,COD >> >> R >> >> >>>>>>>>> Subject: Re: [paws] WGLC for >> >> >>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel=20 >> >> >>>>>>>>> reporting >> >> >>>>>>>>> >> >> >>>>>>>>> Ahh. I think I see where the request and my=20 >> >> >>>>>>>>> understanding divurge. If the idea here is that the=20 >> >> >>>>>>>>> master must provide, >> in >> >> >>>>>>>>> the request, an indication of what channels it expects=20 >> >> >>>>>>>>> to >> >> use, >> >> >>>>>>>>> I can at least understand that. I will return to >> technical >> >> >>>>>>>>> concerns in a moment. >> >> >>>>>>>>> >> >> >>>>>>>>> However, when you say "provide channel usage=20 >> >> >>>>>>>>> information, >> in >> >> >>>>>>>>> order to evaluate interference", what that says to me is=20 >> >> >>>>>>>>> providing, during operation, information as to what >> channels >> >> >>>>>>>>> are being used, and at what power levels. That is what >> would >> >> >>>>>>>>> be needed to analyze actual interference effects. And=20 >> >> >>>>>>>>> that >> is >> >> >>>>>>>>> out of scope as I understand our scope. >> >> >>>>>>>>> >> >> >>>>>>>>> I do see a technical difficulty with having the master >> >> provide, >> >> >>>>>>>>> as part of either registering or requesting spectrum=20 >> >> >>>>>>>>> information, what channels it intends to use. It=20 >> >> >>>>>>>>> doesn;t >> >> know >> >> >>>>>>>>> what channels it intends to use. It intends to use some >> >> number >> >> >>>>>>>>> of available channels. It will figure out which ones=20 >> >> >>>>>>>>> when >> it >> >> >>>>>>>>> is told what is available. How can it send that >> information >> >> in >> >> >>>>>>>>> the request? >> >> >>>>>>>>> >> >> >>>>>>>>> Yours, Joel >> >> >>>>>>>>> >> >> >>>>>>>>> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: >> >> >>>>>>>>>> Hi, >> >> >>>>>>>>>> >> >> >>>>>>>>>> There is a similarity here with device ID. In context=20 >> >> >>>>>>>>>> of >> >> PAWS >> >> >>>>>>>>>> we are not concerned with why a device ID is required=20 >> >> >>>>>>>>>> by >> a >> >> >>>>>>>>>> regulator, we accept it is a requirement from a=20 >> >> >>>>>>>>>> regulator >> >> and >> >> >>>>>>>>>> include it to the protocol. Ofcom identifies in 3.18& >> 3.19 >> >> >>>>>>>>>> that channel usage information is required and thus we >> need >> >> >>>>>>>>>> to include this information. Since the master must >> provide >> >> >>>>>>>>>> this information prior to transmitting, PAWS will not=20 >> >> >>>>>>>>>> function in the UK without this information and thus I=20 >> >> >>>>>>>>>> believe channel usage information is integral to the >> channel >> >> >>>>>>>>>> request& response messaging. >> >> >>>>>>>>>> >> >> >>>>>>>>>> Kind Regards, Scott >> >> >>>>>>>>>> >> >> >>>>>>>>>> >> >> >>>>>>>>>> On 3/6/12 10:30 AM, "ext Joel M. >> >> >>>>>>>>>> Halpern" wrote: >> >> >>>>>>>>>> >> >> >>>>>>>>>>> I would draw a distinction. Ofcom regulations about=20 >> >> >>>>>>>>>>> whitespace requests are very much relevant. Ofcom=20 >> >> >>>>>>>>>>> regulations about notification of dynamic behavior >> (which >> >> >>>>>>>>>>> spectrum is being used) are not in scope as I=20 >> >> >>>>>>>>>>> understand the earlier discussions, particularly the=20 >> >> >>>>>>>>>>> chartering discussions. >> >> >>>>>>>>>>> >> >> >>>>>>>>>>> Yours, Joel >> >> >>>>>>>>>>> >> >> >>>>>>>>>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: >> >> >>>>>>>>>>>> >> >> >>>>>>>>>>>> The ofcom requirements are very much relevant to the=20 >> >> >>>>>>>>>>>> scope of the PAWS WG. The only other regulatory=20 >> >> >>>>>>>>>>>> requirements that we have today is the FCC. Ofcom=20 >> >> >>>>>>>>>>>> requirements are a good addition to the set. >> >> >>>>>>>>>>>> >> >> >>>>>>>>>>>> -Raj >> >> >>>>>>>>>>>> >> >> >>>>>>>>>>>> On 3/6/12 10:03 AM, "ext >> >> >>>>>>>>>>>> andy.sago@bt.com" wrote: >> >> >>>>>>>>>>>> >> >> >>>>>>>>>>>>> Hi Joel >> >> >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> There's no language I can find in the charter that=20 >> >> >>>>>>>>>>>>> explicitly puts this out of scope. On the other=20 >> >> >>>>>>>>>>>>> hand, the charter says that the group will "consider=20 >> >> >>>>>>>>>>>>> input from regulatory entities", and this is one of=20 >> >> >>>>>>>>>>>>> the requirements from Ofcom that they have just >published. >> >> >>>>>>>>>>>>> The protocol will be worthless for the UK if it=20 >> >> >>>>>>>>>>>>> omits some requirements. >> >> >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> Regards >> >> >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> Andy >> >> >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> -----Original Message----- From: Joel M. Halpern=20 >> >> >>>>>>>>>>>>> [mailto:jmh@joelhalpern.com] Sent: 06 March 2012 >> >> >>>>>>>>>>>>> 15:53 >> >> >>>>>>>>>>>>> To: Sago,AJ,Andy,COD R Cc: paws@ietf.org;=20 >> >> >>>>>>>>>>>>> Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for >> >> >>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: >> channel >> >> >>>>>>>>>>>>> reporting >> >> >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> As I understand, the information you are asking for=20 >> >> >>>>>>>>>>>>> is explicitly out of scope for the working group. >> >> >>>>>>>>>>>>> Yours, Joel >> >> >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >> >> >>>>>>>>>>>>>> All >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Comparing the draft with the Ofcom requirements at >> >> >>>>>>>>>>>>>> http://www.cept.org/Documents/se- >> >> >>>>> 43/4161/SE43(12)Info03_Draft-UK-r >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> >>>>> egul >> >> >>>>>>>>>>>>>> atory-requirements-for-white-space-devices-in-the- >> UHF- >> >> TV- >> >> >>>>> band, >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> >>>>> I believe the WG draft is deficient in the area of reporting >> >> >>>>>>>>>>>>>> frequencies and powers actually used by masters and=20 >> >> >>>>>>>>>>>>>> slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom=20 >> >> >>>>>>>>>>>>>> intends to collect this data to assesses the impact=20 >> >> >>>>>>>>>>>>>> of aggregate interference into other services. It=20 >> >> >>>>>>>>>>>>>> would also provide usage information (frequency in >> >> >>>>>>>>>>>>>> use) that would inform the operation of a kill=20 >> >> >>>>>>>>>>>>>> switch capability. I suggest this deficiency can be=20 >> >> >>>>>>>>>>>>>> remedied with the following changes: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> New P requirements (probably best placed following >> >> >>>>>>>>>>>>>> P.12): >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> P.12bis: The protocol MUST support a channel usage=20 >> >> >>>>>>>>>>>>>> message from the slave device to the master device. >> >> >>>>>>>>>>>>>> The channel usage message MUST include parameters=20 >> >> >>>>>>>>>>>>>> as required by local regulatory requirement. These=20 >> >> >>>>>>>>>>>>>> parameters MAY include device ID, manufacturer's=20 >> >> >>>>>>>>>>>>>> serial number, channel usage and power level=20 >> >> >>>>>>>>>>>>>> information. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> P.12ter: The protocol MUST support a channel usage=20 >> >> >>>>>>>>>>>>>> message from the master device to the database. >> >> >>>>>>>>>>>>>> The channel usage message MUST include parameters=20 >> >> >>>>>>>>>>>>>> as required by local regulatory requirement for the=20 >> >> >>>>>>>>>>>>>> master and its associated slaves. These parameters=20 >> >> >>>>>>>>>>>>>> MAY include device ID, manufacturer's serial=20 >> >> >>>>>>>>>>>>>> number, channel usage and power level information. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> P.12qua: The protocol MUST support a channel usage=20 >> >> >>>>>>>>>>>>>> message acknowledgement. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> New O requirements (probably best placed following >> >> >>>>>>>>>>>>>> O13): >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> O.13bis: According to local regulatory policy,=20 >> >> >>>>>>>>>>>>>> after connecting to a master device's radio network=20 >> >> >>>>>>>>>>>>>> a slave device MAY inform the master device of the=20 >> >> >>>>>>>>>>>>>> actual channel usage. The slave MUST include=20 >> >> >>>>>>>>>>>>>> parameters required by local regulatory policy, e.g. >> >> >>>>>>>>>>>>>> device ID, manufacturer's serial number, channel=20 >> >> >>>>>>>>>>>>>> usage and power level information. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> O.13ter: According to local regulatory policy, a=20 >> >> >>>>>>>>>>>>>> master device MAY inform the database of the actual=20 >> >> >>>>>>>>>>>>>> channel usage of the master and its slaves. The=20 >> >> >>>>>>>>>>>>>> master MUST include parameters required by local=20 >> >> >>>>>>>>>>>>>> regulatory policy, e.g. device ID, manufacturer's=20 >> >> >>>>>>>>>>>>>> serial number, channel usage and power level=20 >> >> >>>>>>>>>>>>>> information of the master and its slaves. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> New steps could be introduced into one or more use=20 >> >> >>>>>>>>>>>>>> cases to cover these Ofcom requirements, e.g. new=20 >> >> >>>>>>>>>>>>>> steps 6bis and 9bis in the hotspot use case at >> >> >>>>>>>>>>>>>> 4.2.1: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 6bis. Prior to initiating transmission, if required=20 >> >> >>>>>>>>>>>>>> by local regulation, the master/AP informs the=20 >> >> >>>>>>>>>>>>>> database of the channel and power level it has=20 >> >> >>>>>>>>>>>>>> chosen. This is repeated for each slave that=20 >> >> >>>>>>>>>>>>>> associated with the master. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 9bis. Prior to initiating transmission, if required=20 >> >> >>>>>>>>>>>>>> by local regulation, the slave informs the=20 >> >> >>>>>>>>>>>>>> master/AP of the channel and power level it has=20 >> >> >>>>>>>>>>>>>> chosen, and the master/AP relays this information=20 >> >> >>>>>>>>>>>>>> to the >database. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> - end of new text - >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> For information, for those not accessing the url in=20 >> >> >>>>>>>>>>>>>> the first paragraph of this email, the full Ofcom=20 >> >> >>>>>>>>>>>>>> requirements leading to this new PAWS text are as >> >> >>>>>>>>>>>>>> follows: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 3.18 After receiving instructions from a WSDB in=20 >> >> >>>>>>>>>>>>>> relation to the maximum permitted EIRPs over the=20 >> >> >>>>>>>>>>>>>> DTT channels, and prior to initiating transmissions=20 >> >> >>>>>>>>>>>>>> within the UHF TV band, a master WSD must=20 >> >> >>>>>>>>>>>>>> communicate to the WSDB the following information: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 3.18.1 The lower and upper frequency boundaries^13=20 >> >> >>>>>>>>>>>>>> of the in-block emissions of the master WSD, and=20 >> >> >>>>>>>>>>>>>> those of the in-block emissions of its associated=20 >> >> >>>>>>>>>>>>>> slaves. A lower frequency will be specified as (470 >> >> >>>>>>>>>>>>>> + 8k + >> >> >>>>>>>>>>>>>> 0.2n) MHz, with the corresponding upper frequency=20 >> >> >>>>>>>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3?4 k >3?4 >> >> >>>>>>>>>>>>>> 39, 0 3?4 n 3?4 39, 1 3?4 m 3?4 40, and n< m. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 3.18.2 The maximum in-block EIRP spectral densities=20 >> >> >>>>>>>>>>>>>> (in dBm/(0.2 MHz)) that the master WSD, and its=20 >> >> >>>>>>>>>>>>>> associated slaves, actually radiate between each=20 >> >> >>>>>>>>>>>>>> reported lower frequency boundary and its=20 >> >> >>>>>>>>>>>>>> corresponding upper frequency boundary. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Footnote 13 states: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> The use of upper and lower frequency boundaries=20 >> >> >>>>>>>>>>>>>> (defined over a 200 kHz raster) allows a WSDB to=20 >> >> >>>>>>>>>>>>>> collect more granular information with regards to=20 >> >> >>>>>>>>>>>>>> the usage of the frequency resource by narrowband=20 >> >> >>>>>>>>>>>>>> WSD technologies. The upper and lower frequencies=20 >> >> >>>>>>>>>>>>>> of a boundary pair do not straddle a DTT channel >boundary. >> >> >>>>>>>>>>>>>> Note that a WSD may transmit over multiple,=20 >> >> >>>>>>>>>>>>>> non-contiguous, whole DTT channels or fractions of=20 >> >> >>>>>>>>>>>>>> DTT channels. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 3.19 A master WSD must be able to receive the=20 >> >> >>>>>>>>>>>>>> following information^14 from a WSDB: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in the >> >> >>>>>>>>>>>>>> context of 3.18, that the reported information on=20 >> >> >>>>>>>>>>>>>> the DTT channels and EIRP spectral densities=20 >> >> >>>>>>>>>>>>>> actually used by the master and slave WSDs were=20 >> >> >>>>>>>>>>>>>> received successfully by the WSDB^18 ]. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Footnote 14 states: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 14 While the communication of some of this=20 >> >> >>>>>>>>>>>>>> information from a WSDB to a master WSD is=20 >> >> >>>>>>>>>>>>>> optional, master WSDs must be able to receive and=20 >> >> >>>>>>>>>>>>>> interpret these. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Footnote 18 states: >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> 18 This forms part of a handshake protocol and may=20 >> >> >>>>>>>>>>>>>> be an area where industry could harmonise without=20 >> >> >>>>>>>>>>>>>> the need for an explicit requirement in the >regulations. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Regards >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Andy >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> *From:*paws-bounces@ietf.org=20 >> >> >>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] *On Behalf Of=20 >> >> >>>>>>>>>>>>>> *Gabor.Bajko@nokia.com *Sent:* 05 March 2012 19:46 >> >> >>>>>>>>>>>>>> *To:* paws@ietf.org *Subject:* [paws] WGLC for >> >> >>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> The authors of the use cases and requirements draft=20 >> >> >>>>>>>>>>>>>> have just posted a new version of the draft and=20 >> >> >>>>>>>>>>>>>> indicated that there are no unresolved=20 >> >> >>>>>>>>>>>>>> comments/issues they are aware of. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Therefore, I'd like to initiate a WG Last Call for=20 >> >> >>>>>>>>>>>>>> comments on=20 >> >> >>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-paws >> >> >>>>>>>>>>>>>> - >> >> problem- >> >> >>>>> stmt-u >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> >>>>> seca >> >> >>>>>>>>>>>>>> ses-rqmts-03.txt >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Please review the draft and send your comments to=20 >> >> >>>>>>>>>>>>>> the list by March 20th, 2012. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> If you review the draft and have no comments, send=20 >> >> >>>>>>>>>>>>>> a note to the list that the draft is good as it is,=20 >> >> >>>>>>>>>>>>>> we need these notes as much as we need the actual=20 >> >> >>>>>>>>>>>>>> comments. >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> Thanks, Gabor >> >> >>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>> >> >> > >> >> > _______________________________________________ >> >> > paws mailing list >> >> > paws@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/paws >> >> > >> >> _______________________________________________ >> >> paws mailing list >> >> paws@ietf.org >> >> https://www.ietf.org/mailman/listinfo/paws >> >> >> >> _______________________________________________ >> >> paws mailing list >> >> paws@ietf.org >> >> https://www.ietf.org/mailman/listinfo/paws >> >_______________________________________________ >> >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 > >________________________________ > >*********************************************************************** >* >****************************************** >For more information visit www.ofcom.org.uk > >This email (and any attachments) is confidential and intended for the=20 >use of the addressee only. > >If you have received this email in error please notify the originator=20 >of the message and delete it from your system. > >This email has been scanned for viruses. However, you open any=20 >attachments at your own risk. > >Any views expressed in this message are those of the individual sender=20 >and do not represent the views or opinions of Ofcom unless expressly=20 >stated otherwise. >*********************************************************************** >* >****************************************** >_______________________________________________ >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 ________________________________ ***************************************************************************= *************************************** 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. ***************************************************************************= *************************************** _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From Gabor.Bajko@nokia.com Fri Mar 9 23:44:33 2012 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 B40EB11E8074 for ; Fri, 9 Mar 2012 23:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.86 X-Spam-Level: X-Spam-Status: No, score=-4.86 tagged_above=-999 required=5 tests=[AWL=1.512, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 oYEe1DOv+R8C for ; Fri, 9 Mar 2012 23:44:32 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8E711E807F for ; Fri, 9 Mar 2012 23:44:31 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q2A7iQmY004272 for ; Sat, 10 Mar 2012 09:44:28 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 10 Mar 2012 09:44:26 +0200 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.157]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0355.003; Sat, 10 Mar 2012 08:44:26 +0100 From: To: Thread-Topic: [paws] WGLC fordraft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting Thread-Index: AQHM/g1GCIAqEXW5G0yHYlM8f9lIlpZjFgTg Date: Sat, 10 Mar 2012 07:44:24 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601E1E216@008-AM1MPN1-006.mgdnok.nokia.com> References: , <7BAC95F5A7E67643AAFB2C31BEE662D0157A034B37@SC-VEXCH2.marvell.com> <2D1F0F0C-F3B9-43ED-8195-0962DF863AC8@neustar.biz> <4F5A2841.4030506@qualcomm.com> In-Reply-To: <4F5A2841.4030506@qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.21.95.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Mar 2012 07:44:26.0190 (UTC) FILETIME=[9E0766E0:01CCFE91] X-Nokia-AV: Clean Subject: Re: [paws] WGLC fordraft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting 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, 10 Mar 2012 07:44:33 -0000 When we started this paws effort not that long ago, the whole purpose was t= o define a protocol which can help devices make use of white spaces, accord= ing to rules set by the regulators. The charter we came up with covered the= regulatory requirements available at the time of writing, and we did not a= nticipate requirements like the one Ofcom came up with recently. That is wh= y we do not have, as Pete pointed out, explicitly listed an item for the cl= ient devices to report back anything to the server. We do have, however, th= e following sentence in the charter:=20 " In order to ensure that the WG takes into account a broad range of possib= le use cases and requirements, the group should also reach out to other potential "customers" for a white space database access method and consider input from regulatory entities that are involved in the specification of the rule= s " It just does not say how the inputs from regulatory entities are to be cons= idered ... I would put aside the solution proposals on whether the client should use a= n acknowledgement message or a separate transaction for reporting back, wha= t exactly to report, etc, and consider for the time being that we have a re= quirements document and this whole thread started with Andy proposing new r= equirements the be added there to meet Ofcom requirements. I see the following possibilities: 1. ignore the Ofcom requirements on channel reporting back to the db. I bel= ieve, if we choose this path, then the protocol we'll design will not meet = the original goals, and we may just as well go home and play soccer instead 2. try to fit the Ofcom requirements into the charter. One could argue this= is possible, as the Ofcom requirements do not specify what the db is suppo= sed to do with that data, we could consider it is just for informational pu= rposes. We've seen both pro and con opinions on this on the list, so we cou= ld continue to argue. But since both the outgoing and incoming AD thinks th= is is not the way to go, I do not see much hope we can succeed on this path= . 3. go back to iesg and modify the charter to include the channel reporting = back to the db aspect. If we do this, we can then include the relevant requ= irements into the reqs draft, issue a new wglc and start the work on the pr= otocol itself. I see this the fastest and least controversial (at least fro= m the ADs pow) path. So what do folks, who believe they know the ietf process well enough, prefe= r? I am just trying to get the wg out of this deadlock situation, so please= be constructive. - Gabor -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Pete Resnick Sent: Friday, March 09, 2012 7:57 AM To: Gerald Chouinard Cc: paws@ietf.org Subject: Re: [paws] WGLC fordraft-ietf-paws-problem-stmt-usecases-rqmts-03:= channel reporting Folks, Fair warning as your incoming AD, but also as a current AD who thought he u= nderstood what work this group was chartered to do: The group is chartered to do (1) database discovery, (2) database access, (= 3) data formats for that database access, and (4) security for that databas= e access. The charter also describes what that database access is like: (a)= provide geolocation and other info to query the database, and (b) receive = the whitespace that can be used. Insofar as what this charter only allows for protocol that is about databas= e discovery and database access, the so-called "acknowledgment"=20 you all are talking is either writing back to the database (if the "acknowl= edgment" data gets saved into the same database) or is non-database-access = protocol to talk to a third party. In either case, I, as an AD, would be ex= tremely surprised to find out either that the database was writeable by the= client (that was not my understanding of the query described in the "rough= outline of the protocol" section of the charter) or that there was to be a= dditional protocol that sent data from the client to a third party. There i= s a whole new set of considerations on such protocol (e.g., Does the inform= ation sent back from the client need TTL values? Is there a renewal process= on the data after some time? What if there are multiple clients accessing = at the same time and they choose the same value? Can the response get back = an error and the client has to choose something different?). If you wish to take on this work, you need to go back to the IESG and re-ch= arter. That's fine: If the WG feels that this piece of protocol is required= in order to make the rest of the protocol at all useful, now is the time t= o tell the IESG that and figure out how to write it into the charter. But d= oing this work without a charter change is going to cause heartache later. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From jmh@joelhalpern.com Sat Mar 10 07:36:06 2012 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 9C47F21F85FD for ; Sat, 10 Mar 2012 07:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.981 X-Spam-Level: X-Spam-Status: No, score=-101.981 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 Wi1cKuAAmRJB for ; Sat, 10 Mar 2012 07:36:05 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id C32B821F85FC for ; Sat, 10 Mar 2012 07:36:05 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id A2B82CD14B for ; Sat, 10 Mar 2012 07:36:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 660441C6220; Sat, 10 Mar 2012 07:36:05 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.100] (pool-71-161-51-182.clppva.btas.verizon.net [71.161.51.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 55FAC1C61EA; Sat, 10 Mar 2012 07:36:04 -0800 (PST) Message-ID: <4F5B74E1.2010907@joelhalpern.com> Date: Sat, 10 Mar 2012 10:36:01 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Gabor.Bajko@nokia.com References: , <7BAC95F5A7E67643AAFB2C31BEE662D0157A034B37@SC-VEXCH2.marvell.com> <2D1F0F0C-F3B9-43ED-8195-0962DF863AC8@neustar.biz> <4F5A2841.4030506@qualcomm.com> <1ECAFF543A2FED4EA2BEB6CACE08E47601E1E216@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601E1E216@008-AM1MPN1-006.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: paws@ietf.org Subject: Re: [paws] WGLC fordraft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting 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, 10 Mar 2012 15:36:06 -0000 I don't know which path I would prefer. But, given the charter, and the discussion around the charter for the need for focus in the working group, I believe that if the working group wants to work on something akin to the stated ofcom usage reporting requirement then it needs to 1) ask the IESG if that is acceptable 2) if the IESG agrees in principle, then work with the IESG on a revision to the charter. Yours, Joel On 3/10/2012 2:44 AM, Gabor.Bajko@nokia.com wrote: > When we started this paws effort not that long ago, the whole purpose was to define a protocol which can help devices make use of white spaces, according to rules set by the regulators. The charter we came up with covered the regulatory requirements available at the time of writing, and we did not anticipate requirements like the one Ofcom came up with recently. That is why we do not have, as Pete pointed out, explicitly listed an item for the client devices to report back anything to the server. We do have, however, the following sentence in the charter: > " In order to ensure that the WG takes into account a broad range of possible use cases and > requirements, the group should also reach out to other potential > "customers" for a white space database access method and consider input > from regulatory entities that are involved in the specification of the rules " > It just does not say how the inputs from regulatory entities are to be considered ... > > I would put aside the solution proposals on whether the client should use an acknowledgement message or a separate transaction for reporting back, what exactly to report, etc, and consider for the time being that we have a requirements document and this whole thread started with Andy proposing new requirements the be added there to meet Ofcom requirements. > > I see the following possibilities: > 1. ignore the Ofcom requirements on channel reporting back to the db. I believe, if we choose this path, then the protocol we'll design will not meet the original goals, and we may just as well go home and play soccer instead > 2. try to fit the Ofcom requirements into the charter. One could argue this is possible, as the Ofcom requirements do not specify what the db is supposed to do with that data, we could consider it is just for informational purposes. We've seen both pro and con opinions on this on the list, so we could continue to argue. But since both the outgoing and incoming AD thinks this is not the way to go, I do not see much hope we can succeed on this path. > 3. go back to iesg and modify the charter to include the channel reporting back to the db aspect. If we do this, we can then include the relevant requirements into the reqs draft, issue a new wglc and start the work on the protocol itself. I see this the fastest and least controversial (at least from the ADs pow) path. > > So what do folks, who believe they know the ietf process well enough, prefer? I am just trying to get the wg out of this deadlock situation, so please be constructive. > > - Gabor > > > > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Pete Resnick > Sent: Friday, March 09, 2012 7:57 AM > To: Gerald Chouinard > Cc: paws@ietf.org > Subject: Re: [paws] WGLC fordraft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting > > Folks, > > Fair warning as your incoming AD, but also as a current AD who thought he understood what work this group was chartered to do: > > The group is chartered to do (1) database discovery, (2) database access, (3) data formats for that database access, and (4) security for that database access. The charter also describes what that database access is like: (a) provide geolocation and other info to query the database, and (b) receive the whitespace that can be used. > > Insofar as what this charter only allows for protocol that is about database discovery and database access, the so-called "acknowledgment" > you all are talking is either writing back to the database (if the "acknowledgment" data gets saved into the same database) or is non-database-access protocol to talk to a third party. In either case, I, as an AD, would be extremely surprised to find out either that the database was writeable by the client (that was not my understanding of the query described in the "rough outline of the protocol" section of the charter) or that there was to be additional protocol that sent data from the client to a third party. There is a whole new set of considerations on such protocol (e.g., Does the information sent back from the client need TTL values? Is there a renewal process on the data after some time? What if there are multiple clients accessing at the same time and they choose the same value? Can the response get back an error and the client has to choose something different?). > > If you wish to take on this work, you need to go back to the IESG and re-charter. That's fine: If the WG feels that this piece of protocol is required in order to make the rest of the protocol at all useful, now is the time to tell the IESG that and figure out how to write it into the charter. But doing this work without a charter change is going to cause heartache later. > > pr > > -- > Pete Resnick > Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 > > _______________________________________________ > 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 Mon Mar 12 11:16:20 2012 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 6A5BD21F867A for ; Mon, 12 Mar 2012 11:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.213 X-Spam-Level: X-Spam-Status: No, score=-105.213 tagged_above=-999 required=5 tests=[AWL=1.159, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 8UJ1bPPq2347 for ; Mon, 12 Mar 2012 11:16:19 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3AEC921F865B for ; Mon, 12 Mar 2012 11:16:19 -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.4) with ESMTP id q2CIGHgh016538 for ; Mon, 12 Mar 2012 20:16:18 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.26]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 20:16:16 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.150]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.01.0355.003; Mon, 12 Mar 2012 19:16:16 +0100 From: To: , Thread-Topic: [paws] WGLC fordraft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting Thread-Index: AQHNAHw2b56FrsplPEegvHZipAT3mA== Date: Mon, 12 Mar 2012 18:16:15 +0000 Message-ID: In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601E1E216@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [72.64.105.193] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Mar 2012 18:16:17.0007 (UTC) FILETIME=[37767FF0:01CD007C] X-Nokia-AV: Clean Subject: Re: [paws] WGLC fordraft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting 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, 12 Mar 2012 18:16:20 -0000 Hi Gabor, The WG charter has been defined with a very narrow focus in order to ensure that a protocol solution for use between white space devices and database(s) can be delivered within a reasonable timeframe. However at the time of the chartering, we did not have ofcom requirements and hence the scope was limited to a request/response protocol for the device-2-database interface. Now that we do have a better view of Ofcom requirements, it would be shortsighted to not consider those. I believe that the scope of the extension to the protocol that is being discussed is not significant enough to cause a major rethink of the charter or the protocol. Hence I would be in favor of option 3. The IETF process allows working groups to recharter at any time. I believe there is enough reason for a minimal extension of the charter scope to accommodate the Ofcom requirement. -Raj On 3/10/12 1:44 AM, "ext Gabor.Bajko@nokia.com" wrote: >When we started this paws effort not that long ago, the whole purpose was >to define a protocol which can help devices make use of white spaces, >according to rules set by the regulators. The charter we came up with >covered the regulatory requirements available at the time of writing, and >we did not anticipate requirements like the one Ofcom came up with >recently. That is why we do not have, as Pete pointed out, explicitly >listed an item for the client devices to report back anything to the >server. We do have, however, the following sentence in the charter: >" In order to ensure that the WG takes into account a broad range of >possible use cases and >requirements, the group should also reach out to other potential >"customers" for a white space database access method and consider input >from regulatory entities that are involved in the specification of the >rules " >It just does not say how the inputs from regulatory entities are to be >considered ... > >I would put aside the solution proposals on whether the client should use >an acknowledgement message or a separate transaction for reporting back, >what exactly to report, etc, and consider for the time being that we have >a requirements document and this whole thread started with Andy proposing >new requirements the be added there to meet Ofcom requirements. > >I see the following possibilities: >1. ignore the Ofcom requirements on channel reporting back to the db. I >believe, if we choose this path, then the protocol we'll design will not >meet the original goals, and we may just as well go home and play soccer >instead >2. try to fit the Ofcom requirements into the charter. One could argue >this is possible, as the Ofcom requirements do not specify what the db is >supposed to do with that data, we could consider it is just for >informational purposes. We've seen both pro and con opinions on this on >the list, so we could continue to argue. But since both the outgoing and >incoming AD thinks this is not the way to go, I do not see much hope we >can succeed on this path. >3. go back to iesg and modify the charter to include the channel >reporting back to the db aspect. If we do this, we can then include the >relevant requirements into the reqs draft, issue a new wglc and start the >work on the protocol itself. I see this the fastest and least >controversial (at least from the ADs pow) path. > >So what do folks, who believe they know the ietf process well enough, >prefer? I am just trying to get the wg out of this deadlock situation, so >please be constructive. > >- Gabor > > > >-----Original Message----- >From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >ext Pete Resnick >Sent: Friday, March 09, 2012 7:57 AM >To: Gerald Chouinard >Cc: paws@ietf.org >Subject: Re: [paws] WGLC >fordraft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting > >Folks, > >Fair warning as your incoming AD, but also as a current AD who thought he >understood what work this group was chartered to do: > >The group is chartered to do (1) database discovery, (2) database access, >(3) data formats for that database access, and (4) security for that >database access. The charter also describes what that database access is >like: (a) provide geolocation and other info to query the database, and >(b) receive the whitespace that can be used. > >Insofar as what this charter only allows for protocol that is about >database discovery and database access, the so-called "acknowledgment" >you all are talking is either writing back to the database (if the >"acknowledgment" data gets saved into the same database) or is >non-database-access protocol to talk to a third party. In either case, I, >as an AD, would be extremely surprised to find out either that the >database was writeable by the client (that was not my understanding of >the query described in the "rough outline of the protocol" section of the >charter) or that there was to be additional protocol that sent data from >the client to a third party. There is a whole new set of considerations >on such protocol (e.g., Does the information sent back from the client >need TTL values? Is there a renewal process on the data after some time? >What if there are multiple clients accessing at the same time and they >choose the same value? Can the response get back an error and the client >has to choose something different?). > >If you wish to take on this work, you need to go back to the IESG and >re-charter. That's fine: If the WG feels that this piece of protocol is >required in order to make the rest of the protocol at all useful, now is >the time to tell the IESG that and figure out how to write it into the >charter. But doing this work without a charter change is going to cause >heartache later. > >pr > >-- >Pete Resnick >Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From lei.zhu@huawei.com Tue Mar 13 00:02:33 2012 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 2223F11E8087 for ; Tue, 13 Mar 2012 00:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.274 X-Spam-Level: X-Spam-Status: No, score=-5.274 tagged_above=-999 required=5 tests=[AWL=1.324, 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 qx-CjkpcbbcO for ; Tue, 13 Mar 2012 00:02:32 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 3751811E8085 for ; Tue, 13 Mar 2012 00:02:32 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0T00CEJA7H00@szxga05-in.huawei.com> for paws@ietf.org; Tue, 13 Mar 2012 15:02:05 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0T0054GA7HR6@szxga05-in.huawei.com> for paws@ietf.org; Tue, 13 Mar 2012 15:02:05 +0800 (CST) Received: from szxeml213-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHK55901; Tue, 13 Mar 2012 15:02:05 +0800 Received: from SZXEML440-HUB.china.huawei.com (10.72.61.75) by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 13 Mar 2012 15:01:13 +0800 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.11]) by SZXEML440-HUB.china.huawei.com ([10.72.61.75]) with mapi id 14.01.0323.003; Tue, 13 Mar 2012 15:01:57 +0800 Date: Tue, 13 Mar 2012 07:01:57 +0000 From: ZhuLei X-Originating-IP: [10.111.64.76] To: "paws@ietf.org" Message-id: <470F27D1263A1B4EB73491ED995DE62516234020@szxeml504-mbs.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_me1eVLVBqb1f2Deo3ENFoA)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Time to present my ID in IETF Paris meeting Thread-index: Ac0A5yy1glWG2nAiTGCvtquF5UMsew== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [paws] Time to present my ID in IETF Paris 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: Tue, 13 Mar 2012 07:02:33 -0000 --Boundary_(ID_me1eVLVBqb1f2Deo3ENFoA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Folks and chairs, As what you might notice, I uploaded a ID on PAWS framework and protocol which is to fulfill PAWS requirements and regulators' requirements, "www.ietf.org/id/draft-lei-paws-framework-datamodel-00.txt". I would very like to request 25 minutes presenting and discussing it during IETF Paris meeting. Best regards, Zhu Lei --Boundary_(ID_me1eVLVBqb1f2Deo3ENFoA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Folks and chairs,

 

As what you might notice, I uploaded a ID on PAWS framework and protocol which is to fulfill PAWS requirements and regulators’ requirements, “www.ietf.org/id/draft-lei-paws-framework-datamodel-00.txt”.  I would very like to request 25 minutes presenting and discussing it during IETF Paris meeting.

 

Best regards,

Zhu Lei

--Boundary_(ID_me1eVLVBqb1f2Deo3ENFoA)-- From paul@marvell.com Tue Mar 13 00:35:22 2012 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 465B621F886B for ; Tue, 13 Mar 2012 00:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.296 X-Spam-Level: X-Spam-Status: No, score=-4.296 tagged_above=-999 required=5 tests=[AWL=-1.698, 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 R9iwzxanhvWh for ; Tue, 13 Mar 2012 00:35:18 -0700 (PDT) Received: from psmtp.com (na3sys009aog137.obsmtp.com [74.125.149.18]) by ietfa.amsl.com (Postfix) with ESMTP id D556721F886A for ; Tue, 13 Mar 2012 00:35:17 -0700 (PDT) Received: from sc-owa02.marvell.com ([65.219.4.130]) (using TLSv1) by na3sys009aob137.postini.com ([74.125.148.12]) with SMTP ID DSNKT174tdtGieWxV96s7pVc+5j5wiH6AGj5@postini.com; Tue, 13 Mar 2012 00:35:17 PDT Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Tue, 13 Mar 2012 00:28:11 -0700 From: Paul Lambert To: ZhuLei , "paws@ietf.org" Date: Tue, 13 Mar 2012 00:28:15 -0700 Thread-Topic: Time to present my ID in IETF Paris meeting Thread-Index: Ac0A5yy1glWG2nAiTGCvtquF5UMsewAA1Zbg Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D015E331D955@SC-VEXCH2.marvell.com> References: <470F27D1263A1B4EB73491ED995DE62516234020@szxeml504-mbs.china.huawei.com> In-Reply-To: <470F27D1263A1B4EB73491ED995DE62516234020@szxeml504-mbs.china.huawei.com> 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_7BAC95F5A7E67643AAFB2C31BEE662D015E331D955SCVEXCH2marve_" MIME-Version: 1.0 Subject: Re: [paws] Time to present my ID in IETF Paris 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: Tue, 13 Mar 2012 07:35:22 -0000 --_000_7BAC95F5A7E67643AAFB2C31BEE662D015E331D955SCVEXCH2marve_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Did our consensus process include a coordinating intermediary function? The coordinating database can get white space channels from database, receive the white space querying message from master device and provide the available white space channels for master devices with some degree decision making process. These decision making process might provide functionality of white space access protocol power to response available channels according to received device parameters (e.g. power, RF parameter), location information(e.g. altitude, position and direction of antenna ) and some particular white space spectrum decision making policies. Don't see that this is in scope. Seems inappropriate to create complete IDs= with features that are out-of-scope. Paul From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Zhu= Lei Sent: Tuesday, March 13, 2012 12:02 AM To: paws@ietf.org Subject: [paws] Time to present my ID in IETF Paris meeting Hi Folks and chairs, As what you might notice, I uploaded a ID on PAWS framework and protocol wh= ich is to fulfill PAWS requirements and regulators' requirements, "www.ietf= .org/id/draft-lei-paws-framework-datamodel-00.txt". I would very like to r= equest 25 minutes presenting and discussing it during IETF Paris meeting. Best regards, Zhu Lei --_000_7BAC95F5A7E67643AAFB2C31BEE662D015E331D955SCVEXCH2marve_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

&n= bsp;

Did our= consensus process include a coordinating intermediary function?

 

   The coordinating database ca= n get white space channels from database,

   receive the white space quer= ying message from master device and

   provide the available white = space channels for master devices with

   some degree decision making = process.  These decision making process

   might provide functionality = of white space access protocol power to

   response available channels = according to received device parameters

   (e.g. power, RF parameter), = location information(e.g. altitude,

   position and direction of an= tenna ) and some particular white space

   spectrum decision making pol= icies.

&n= bsp;

DonR= 17;t see that this is in scope. Seems inappropriate to create complete IDs with features = that are out-of-scope.

&n= bsp;

Paul

&n= bsp;

&n= bsp;

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Zh= uLei
Sent: Tuesday, March 13, 2012 12:02 AM
To: paws@ietf.org
Subject: [paws] Time to present my ID in IETF Paris meeting

 

Hi Folks and chairs,

 

As what you might notice, I uploaded a ID on PAWS fram= ework and protocol which is to fulfill PAWS requirements and regulators’ requirements, “www.ietf.org/id/draft-lei-paws-framework-datamodel-00.= txt”.  I would very like to request 25 minutes presenting and discussing it during IETF Paris meeting.

 

Best regards,

Zhu Lei

--_000_7BAC95F5A7E67643AAFB2C31BEE662D015E331D955SCVEXCH2marve_-- From lei.zhu@huawei.com Tue Mar 13 01:49:56 2012 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 0B3AF21F876E for ; Tue, 13 Mar 2012 01:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.614 X-Spam-Level: X-Spam-Status: No, score=-3.614 tagged_above=-999 required=5 tests=[AWL=-1.219, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Y1KYVzpTx2K for ; Tue, 13 Mar 2012 01:49:54 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0088321F876A for ; Tue, 13 Mar 2012 01:49:54 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0T00IJIF3CU2@szxga04-in.huawei.com> for paws@ietf.org; Tue, 13 Mar 2012 16:47:36 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0T00B5QF2GRU@szxga04-in.huawei.com> for paws@ietf.org; Tue, 13 Mar 2012 16:47:36 +0800 (CST) Received: from szxeml212-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHU58313; Tue, 13 Mar 2012 16:47:23 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 13 Mar 2012 16:46:57 +0800 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.11]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.003; Tue, 13 Mar 2012 16:47:19 +0800 Date: Tue, 13 Mar 2012 08:47:18 +0000 From: ZhuLei In-reply-to: <7BAC95F5A7E67643AAFB2C31BEE662D015E331D955@SC-VEXCH2.marvell.com> X-Originating-IP: [10.111.64.76] To: Paul Lambert , "paws@ietf.org" Message-id: <470F27D1263A1B4EB73491ED995DE625162340C4@szxeml504-mbs.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_zHIuqdcDxev4vuy5AoEPcg)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Time to present my ID in IETF Paris meeting Thread-index: Ac0A5yy1glWG2nAiTGCvtquF5UMsewAA1ZbgAACAvmA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <470F27D1263A1B4EB73491ED995DE62516234020@szxeml504-mbs.china.huawei.com> <7BAC95F5A7E67643AAFB2C31BEE662D015E331D955@SC-VEXCH2.marvell.com> Subject: Re: [paws] Time to present my ID in IETF Paris 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: Tue, 13 Mar 2012 08:49:56 -0000 --Boundary_(ID_zHIuqdcDxev4vuy5AoEPcg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SGkgUGF1bCwNCg0KRG8geW91IHByZWZlciB0byByZW1vdmUgdGhpcyBpbnRlcm1lZGlhcnkgZnVu Y3Rpb24/IFRoZSBpbnRlbnRpb24gb2YgdGhpcyBkcmFmdCBpcyBzdGlsbCB0byBwcm92aWRlIGEg cHJvcG9zYWwgb2YgZnJhbWV3b3JrIGFuZCBwcm90b2NvbCwgcHJvYmFibHkgaW5jbHVkaW5nIHdo b2xlIHBpY3R1cmUgd2l0aCBlc3NlbnRpYWwgZWxlbWVudHMsIGRpc2NvdmVyeSwgcXVlcnksIHVw ZGF0ZSBldGMuDQoNCkFzIHdoYXQgaXMgbWVudGlvbmVkIGluIGUtbWFpbCBsaXN0IGFuZCBsYXN0 IEYyRiBtZWV0aW5nLCBwb3NzaWJseSwgdGhlIFBBV1MgbWlnaHQgYmUgdmVyeSBleHRlbnNpYmxl IHNpbmNlIHRoZSBiYXNpYyBjb25jZXB0cywgc2NlbmFyaW9zIGFuZCByZXF1aXJlbWVudHMgYXJl IGVzdGFibGlzaGVkIHVwb24gdGhlIEZDQyBhbmQgb3RoZXIgcmVndWxhdG9yc6GvIHByb2Nlc3Mg b2Ygd2hpdGUgc3BhY2UuIFdlIHN0aWxsIGhhdmUgc29tZSBwb3RlbnRpYWwgbmVlZHMgZG9pbmcg ZnVydGhlciBhdCBmZWF0dXJlIGxldmVsIG9yIGV2ZW4gYXJjaGl0ZWN0dXJlIGxldmVsLiBBdCBs ZWFzdCwgdGhlIGRlc2lnbiBvZiB0aGlzIHByb3RvY29sIHNob3VsZCBtYWtlIHN1cmUgdGhpcyBu ZWVkLiBGcm9tIHRoaXMgcGVyc3BlY3RpdmUsIGF1dGhlbnRpY2F0aW9uIGFuZCBjb250ZW50IHBy b3RlY3Rpb24gbWlnaHQgYmUgY29uc2lkZXJlZCBmdXJ0aGVyLCBob3BlZnVsbHksIHdlIGFyZSBh YmxlIHRvIGRpc2N1c3Mgc2VjdXJpdHkgaW4gUGFyaXMuDQoNCldlIGFsc28gcmVhbGx5IG1ldCB2 YXJ5IHNpdHVhdGlvbnMgb2YgZGlmZmVyZW50IGFyZWFzIGFuZCByZWdpb25zIHdobyBkb21pbmF0 ZSBhIHF1aXRlIG51bWJlciBvZiBNYXN0ZXIgZGV2aWNlcy4gSSB3b3VsZCBub3QgaW1hZ2Ugb25l IGRhdGFiYXNlIHNlcnZpbmcgaHVnZSBudW1iZXIgb2YgTWFzdGVyIGRldmljZXMuIEZvciBzb21l IHJlYXNvbnMsIHJlZ3VsYXRvciBtYXkgYXV0aG9yaXplIGJyYW5jaGVzIHRvIGFkbWluaXN0cmF0 ZSBvciBtYWludGFpbiB3aGl0ZSBzcGFjZSBkYXRhIGJhc2Ugd2hpY2ggZG9taW5hdGVzIGEgcGFy dGljdWxhciByZWdpb24uIEkgZG8gbm90IHRoaW5rIHRoZSBtdWx0aXBsZSBkYXRhIGJhc2VzIG9y IGRpc3RyaWJ1dGVkIGRhdGEgbW9kZWwgZnJhbWV3b3JrIGFyZSBjb250cm92ZXJzaWFsIHRvIHVz LCBidXQgdGhlIGFkZGl0aW9uYWwgZnVuY3Rpb25zIG9mIHRoaXMgY29vcmRpbmF0aW5nIGRhdGEg YmFzZS4gVGhpcyBpbnRlcm1lZGlhdGUgbm9kZSB3aXRoIHdoaXRlIHNwYWNlIHNwZWN0cnVtIGRl Y2lzaW9uIG1ha2luZyBmdW5jdGlvbiBpcyB0aGUgaXNzdWUgb2YgZXh0ZW5zaWJpbGl0eSwgd2hp Y2ggY2FuIGJlIGhlbHBmdWwgd2hlbiBhZGRpbmcgc29tZSBmZWF0dXJlIHdoaWNoIGlzIG5vdCBk ZXNpcmVkIHRvIG1haW4gZGF0YSBiYXNlLiBEZWNpc2lvbiBtYWtpbmcgZnVuY3Rpb24gY291bGQg YmUgbm90IGEgZnVuY3Rpb25hbGl0eSBvZiBtYWluIGRhdGEgYmFzZSB3aGljaCBuZWVkcyB0byBi ZSB2ZXJ5IHN0YWJsZSBhbmQgc3RhdGljLiBJZiB3ZSByZWFsbHkgZXh0ZW50IGNvZXhpc3RlbmNl IG9yIGludGVyZmVyZW5jZSBhdm9pZGFuY2Ugcm9sZSB0byBQQVdTIHByb3RvY29sLCBpdCB3b3Vs ZCBiZSBlYXNpZXIgdG8gZXh0ZW50IGludGVybWVkaWFyeSBmdW5jdGlvbiB3aXRob3V0IGltcGFj dHMgb24gZnJhbWV3b3JrIG9mIFBBV1MsIGFuZCwgc3RydWN0dXJlIGFuZCBwcm90b2NvbCBvZiBQ QVdTLiBUaGlzIG5vZGUgaXMgYmVsaWV2ZWQgdG8gZXhpc3QgZm9yIHRoaXMgcHVycG9zZS4NCg0K SSBhbSBub3Qgc3VyZSB0aGF0IHlvdSB3b3VsZCBzdXBwb3J0IHRoaXMgaWRlYSwgYnV0IHRoZSB0 ZXh0IGRlc2NyaWJpbmcgdGhpcyBjYW4gbWFrZSB0aGluZ3MgY2xlYXJlciB3aGVuIHRhbGtpbmcg YWJvdXQgdGhpcy4NCg0KQmVzdCByZWdhcmRzLA0KWmh1IExlaQ0KDQoNCreivP7IyzogUGF1bCBM YW1iZXJ0IFttYWlsdG86cGF1bEBtYXJ2ZWxsLmNvbV0NCreiy83KsbzkOiAyMDEyxOoz1MIxM8jV IDE1OjI4DQrK1bz+yMs6IFpodUxlaTsgcGF3c0BpZXRmLm9yZw0K1vfM4jogUkU6IFRpbWUgdG8g cHJlc2VudCBteSBJRCBpbiBJRVRGIFBhcmlzIG1lZXRpbmcNCg0KDQpEaWQgb3VyIGNvbnNlbnN1 cyBwcm9jZXNzIGluY2x1ZGUgYSBjb29yZGluYXRpbmcgaW50ZXJtZWRpYXJ5IGZ1bmN0aW9uPw0K DQogICBUaGUgY29vcmRpbmF0aW5nIGRhdGFiYXNlIGNhbiBnZXQgd2hpdGUgc3BhY2UgY2hhbm5l bHMgZnJvbSBkYXRhYmFzZSwNCiAgIHJlY2VpdmUgdGhlIHdoaXRlIHNwYWNlIHF1ZXJ5aW5nIG1l c3NhZ2UgZnJvbSBtYXN0ZXIgZGV2aWNlIGFuZA0KICAgcHJvdmlkZSB0aGUgYXZhaWxhYmxlIHdo aXRlIHNwYWNlIGNoYW5uZWxzIGZvciBtYXN0ZXIgZGV2aWNlcyB3aXRoDQogICBzb21lIGRlZ3Jl ZSBkZWNpc2lvbiBtYWtpbmcgcHJvY2Vzcy4gIFRoZXNlIGRlY2lzaW9uIG1ha2luZyBwcm9jZXNz DQogICBtaWdodCBwcm92aWRlIGZ1bmN0aW9uYWxpdHkgb2Ygd2hpdGUgc3BhY2UgYWNjZXNzIHBy b3RvY29sIHBvd2VyIHRvDQogICByZXNwb25zZSBhdmFpbGFibGUgY2hhbm5lbHMgYWNjb3JkaW5n IHRvIHJlY2VpdmVkIGRldmljZSBwYXJhbWV0ZXJzDQogICAoZS5nLiBwb3dlciwgUkYgcGFyYW1l dGVyKSwgbG9jYXRpb24gaW5mb3JtYXRpb24oZS5nLiBhbHRpdHVkZSwNCiAgIHBvc2l0aW9uIGFu ZCBkaXJlY3Rpb24gb2YgYW50ZW5uYSApIGFuZCBzb21lIHBhcnRpY3VsYXIgd2hpdGUgc3BhY2UN CiAgIHNwZWN0cnVtIGRlY2lzaW9uIG1ha2luZyBwb2xpY2llcy4NCg0KRG9uoa90IHNlZSB0aGF0 IHRoaXMgaXMgaW4gc2NvcGUuIFNlZW1zIGluYXBwcm9wcmlhdGUgdG8gY3JlYXRlIGNvbXBsZXRl IElEcyB3aXRoIGZlYXR1cmVzIHRoYXQgYXJlIG91dC1vZi1zY29wZS4NCg0KUGF1bA0KDQoNCkZy b206IHBhd3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIFpodUxlaQ0KU2VudDogVHVlc2RheSwgTWFyY2ggMTMsIDIwMTIgMTI6MDIg QU0NClRvOiBwYXdzQGlldGYub3JnDQpTdWJqZWN0OiBbcGF3c10gVGltZSB0byBwcmVzZW50IG15 IElEIGluIElFVEYgUGFyaXMgbWVldGluZw0KDQpIaSBGb2xrcyBhbmQgY2hhaXJzLA0KDQpBcyB3 aGF0IHlvdSBtaWdodCBub3RpY2UsIEkgdXBsb2FkZWQgYSBJRCBvbiBQQVdTIGZyYW1ld29yayBh bmQgcHJvdG9jb2wgd2hpY2ggaXMgdG8gZnVsZmlsbCBQQVdTIHJlcXVpcmVtZW50cyBhbmQgcmVn dWxhdG9yc6GvIHJlcXVpcmVtZW50cywgobB3d3cuaWV0Zi5vcmcvaWQvZHJhZnQtbGVpLXBhd3Mt ZnJhbWV3b3JrLWRhdGFtb2RlbC0wMC50eHShsS4gIEkgd291bGQgdmVyeSBsaWtlIHRvIHJlcXVl c3QgMjUgbWludXRlcyBwcmVzZW50aW5nIGFuZCBkaXNjdXNzaW5nIGl0IGR1cmluZyBJRVRGIFBh cmlzIG1lZXRpbmcuDQoNCkJlc3QgcmVnYXJkcywNClpodSBMZWkNCg== --Boundary_(ID_zHIuqdcDxev4vuy5AoEPcg) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Hi Paul= ,

&n= bsp;

Do you = prefer to remove this intermediary function? The intention of this draft is= still to provide a proposal of framework and protocol, probably including = whole picture with essential elements, discovery, query, update etc.

&n= bsp;

As what= is mentioned in e-mail list and last F2F meeting, possibly, the PAWS might= be very extensible since the basic concepts, scenarios and requirements ar= e established upon the FCC and other regulators=A1=AF process of white space. We still have some potential needs doing further a= t feature level or even architecture level. At least, the design of this pr= otocol should make sure this need. From this perspective, authentication an= d content protection might be considered further, hopefully, we are able to discuss security in Paris.

&n= bsp;

We also really met vary situations of di= fferent areas and regions who dominate a quite number of Master devices. I = would not image one database serving huge number of Master devices. For some reasons, regulator may authorize branches to a= dministrate or maintain white space data base which dominates a particular = region. I do not think the multiple data bases or distributed data model fr= amework are controversial to us, but the additional functions of this coordinating data base. This intermed= iate node with white space spectrum decision making function is the issue o= f extensibility, which can be helpful when adding some feature which is not= desired to main data base. Decision making function could be not a functionality of main data base which needs= to be very stable and static. If we really extent coexistence or interfere= nce avoidance role to PAWS protocol, it would be easier to extent intermedi= ary function without impacts on framework of PAWS, and, structure and protocol of PAWS. This node is belie= ved to exist for this purpose.

 

I am not sure that you would support thi= s idea, but the text describing this can make things clearer when talking a= bout this.

 

Best regards,

Zhu Lei

 

&n= bsp;

=B7=A2=BC=FE=C8=CB: Paul Lambert [mailto:paul@marvell.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C213=C8=D5 15:28
=CA=D5=BC=FE=C8=CB: ZhuLei; paws@ietf.org
=D6=F7=CC=E2: RE: Time to present my ID in IETF Paris meeting<= /p>

 

 

Did our consensus process include a coordinating intermediary fun= ction?

<= o:p> 

&= nbsp;  The coordinating database can get white space channels from dat= abase,

&= nbsp;  receive the white space querying message from master device and=

&= nbsp;  provide the available white space channels for master devices w= ith

&= nbsp;  some degree decision making process.  These decision makin= g process

&= nbsp;  might provide functionality of white space access protocol powe= r to

&= nbsp;  response available channels according to received device parame= ters

&= nbsp;  (e.g. power, RF parameter), location information(e.g. altitude,=

&= nbsp;  position and direction of antenna ) and some particular white s= pace

&= nbsp;  spectrum decision making policies.

 

Don=A1=AFt see that this is in scope. Seems inappropriate to crea= te complete IDs with features that are out-of-scope.

 

Paul

 

 

From: paws-bounces= @ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ZhuLei
Sent: Tuesday, March 13, 2012 12:02 AM
To: paws@ietf.org
Subject: [paws] Time to present my ID in IETF Paris meeting

 

Hi Folks and chairs,=

 

As what you might notice, I upl= oaded a ID on PAWS framework and protocol which is to fulfill PAWS requirem= ents and regulators=A1=AF requirements, =A1=B0www.ietf.org/id/draft-lei-paw= s-framework-datamodel-00.txt=A1=B1.  I would very like to request 25 minutes presenting and discussing it during IETF Paris meeti= ng.

 

Best regards,=

Zhu Lei

--Boundary_(ID_zHIuqdcDxev4vuy5AoEPcg)-- From Basavaraj.Patil@nokia.com Tue Mar 13 07:38:44 2012 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 2038A21F86B0 for ; Tue, 13 Mar 2012 07:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.116 X-Spam-Level: X-Spam-Status: No, score=-105.116 tagged_above=-999 required=5 tests=[AWL=1.482, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 8+D40DReSDaz for ; Tue, 13 Mar 2012 07:38:43 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 783F021F8693 for ; Tue, 13 Mar 2012 07:38:42 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q2DEccPw003538; Tue, 13 Mar 2012 16:38:38 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Mar 2012 16:38:38 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.150]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0355.003; Tue, 13 Mar 2012 15:38:37 +0100 From: To: , , Thread-Topic: [paws] Time to present my ID in IETF Paris meeting Thread-Index: Ac0A5yy1glWG2nAiTGCvtquF5UMsewAA1ZbgAASkTIA= Date: Tue, 13 Mar 2012 14:38:36 +0000 Message-ID: In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D015E331D955@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.14.0.111121 x-originating-ip: [172.19.59.24] Content-Type: multipart/alternative; boundary="_000_CB84C6071BE48basavarajpatilnokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 13 Mar 2012 14:38:38.0125 (UTC) FILETIME=[FA2CFDD0:01CD0126] X-Nokia-AV: Clean Subject: Re: [paws] Time to present my ID in IETF Paris 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: Tue, 13 Mar 2012 14:38:44 -0000 --_000_CB84C6071BE48basavarajpatilnokiacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I agree with Paul's comment. The idea of a co-ordinating intermediary funct= ion is not in the current scope of PAWS AFAICT. -Raj From: ext Paul Lambert > Date: Tue, 13 Mar 2012 00:28:15 -0700 To: ZhuLei >, "paws@ietf.org<= mailto:paws@ietf.org>" > Subject: Re: [paws] Time to present my ID in IETF Paris meeting Did our consensus process include a coordinating intermediary function? The coordinating database can get white space channels from database, receive the white space querying message from master device and provide the available white space channels for master devices with some degree decision making process. These decision making process might provide functionality of white space access protocol power to response available channels according to received device parameters (e.g. power, RF parameter), location information(e.g. altitude, position and direction of antenna ) and some particular white space spectrum decision making policies. Don=92t see that this is in scope. Seems inappropriate to create complete I= Ds with features that are out-of-scope. Paul From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ZhuLei Sent: Tuesday, March 13, 2012 12:02 AM To: paws@ietf.org Subject: [paws] Time to present my ID in IETF Paris meeting Hi Folks and chairs, As what you might notice, I uploaded a ID on PAWS framework and protocol wh= ich is to fulfill PAWS requirements and regulators=92 requirements, =93www.= ietf.org/id/draft-lei-paws-framework-datamodel-00.txt=94. I would very lik= e to request 25 minutes presenting and discussing it during IETF Paris meet= ing. Best regards, Zhu Lei _______________________________________________ paws mailing list paws@ietf= .org https://www.ietf.org/mailman/listinfo/paws --_000_CB84C6071BE48basavarajpatilnokiacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

I agree with Paul's comment. The idea of a co-ordinating intermediary = function is not in the current scope of PAWS AFAICT.

-Raj

From: ext Paul Lambert <paul@marvell.com>
Date: Tue, 13 Mar 2012 00:28:15 -07= 00
To: ZhuLei <lei.zhu@huawei.com>, "paws@ietf.org" <paws= @ietf.org>
Subject: Re: [paws] Time to present= my ID in IETF Paris meeting

=  

Did o= ur consensus process include a coordinating intermediary function?

 =

   The coordin= ating database can get white space channels from database,

   receive the= white space querying message from master device and

   provide the= available white space channels for master devices with

   some degree= decision making process.  These decision making process

   might provi= de functionality of white space access protocol power to<= /p>

   response av= ailable channels according to received device parameters<= /p>

   (e.g. power= , RF parameter), location information(e.g. altitude,

   position an= d direction of antenna ) and some particular white space<= /p>

   spectrum de= cision making policies.

=  

Don= =92t see that this is in scope. Seems inappropriate to create complete IDs = with features that are out-of-scope.

=  

Paul =

=  

=  

From:= paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ZhuLei
Sent: Tuesday, March 13, 2012 12:02 AM
To: paws@ietf.org
Subject: [paws] Time to present my ID in IETF Paris meeting

 =

Hi Folks and chairs,

 

As what you might notice, I uploaded a ID on PAWS fr= amework and protocol which is to fulfill PAWS requirements and regulators= =92 requirements, =93www.ietf.org/id/draft-lei-paws-framework-datamodel-00.= txt=94.  I would very like to request 25 minutes presenting and discussing it during IETF Paris meeting.

 

Best regards,

Zhu Lei

_______________________________________________ paws mailing list paws@ietf.org ht= tps://www.ietf.org/mailman/listinfo/paws --_000_CB84C6071BE48basavarajpatilnokiacom_-- From paul@marvell.com Tue Mar 13 14:33:31 2012 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 699C621E8017 for ; Tue, 13 Mar 2012 14:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.14 X-Spam-Level: X-Spam-Status: No, score=-4.14 tagged_above=-999 required=5 tests=[AWL=-1.745, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jAR3zF42LBC for ; Tue, 13 Mar 2012 14:33:30 -0700 (PDT) Received: from na3sys009aog125.obsmtp.com (na3sys009aog125.obsmtp.com [74.125.149.153]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC9B21E8015 for ; Tue, 13 Mar 2012 14:33:29 -0700 (PDT) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob125.postini.com ([74.125.148.12]) with SMTP ID DSNKT1+9GP2WAIKSCjGYMNDGRcdruK2z+ZB4@postini.com; Tue, 13 Mar 2012 14:33:29 PDT Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Tue, 13 Mar 2012 14:31:40 -0700 From: Paul Lambert To: ZhuLei , "paws@ietf.org" Date: Tue, 13 Mar 2012 14:31:44 -0700 Thread-Topic: Time to present my ID in IETF Paris meeting Thread-Index: Ac0A5yy1glWG2nAiTGCvtquF5UMsewAA1ZbgAACAvmAAHF/YoA== Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D015E331DAA3@SC-VEXCH2.marvell.com> References: <470F27D1263A1B4EB73491ED995DE62516234020@szxeml504-mbs.china.huawei.com> <7BAC95F5A7E67643AAFB2C31BEE662D015E331D955@SC-VEXCH2.marvell.com> <470F27D1263A1B4EB73491ED995DE625162340C4@szxeml504-mbs.china.huawei.com> In-Reply-To: <470F27D1263A1B4EB73491ED995DE625162340C4@szxeml504-mbs.china.huawei.com> 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_7BAC95F5A7E67643AAFB2C31BEE662D015E331DAA3SCVEXCH2marve_" MIME-Version: 1.0 Subject: Re: [paws] Time to present my ID in IETF Paris 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: Tue, 13 Mar 2012 21:33:31 -0000 --_000_7BAC95F5A7E67643AAFB2C31BEE662D015E331DAA3SCVEXCH2marve_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgWmh1LA0KDQo+IEkgYW0gbm90IHN1cmUgdGhhdCB5b3Ugd291bGQgc3VwcG9ydCB0aGlzIGlk ZWEsIGJ1dCB0aGUgdGV4dCBkZXNjcmliaW5nIHRoaXMgY2FuIG1ha2UgdGhpbmdzIGNsZWFyZXIg d2hlbiB0YWxraW5nIGFib3V0IHRoaXMuDQoNCk5vIEkgZG8gbm90IHN1cHBvcnQgdGhlIGlkZWEg b2YgYWRkaXRpb25hbCBsYXllcnMgb2YgobBjb29yZGluYXRpbmcgZGF0YWJhc2WhsS4gIEVzcGVj aWFsbHkgZm9yIGRldGFpbGVkIGRlc2lnbnMgdXNpbmcgSFRUUFMuDQoNCj4gSSB3b3VsZCBub3Qg aW1hZ2Ugb25lIGRhdGFiYXNlIHNlcnZpbmcgaHVnZSBudW1iZXIgb2YgTWFzdGVyIGRldmljZXMu IEZvciBzb21lIHJlYXNvbnMsIHJlZ3VsYXRvcg0KPm1heSBhdXRob3JpemUgYnJhbmNoZXMgdG8g YWRtaW5pc3RyYXRlIG9yIG1haW50YWluIHdoaXRlIHNwYWNlIGRhdGEgYmFzZSB3aGljaCBkb21p bmF0ZXMgYSBwYXJ0aWN1bGFyIHJlZ2lvbi4NCg0KT3V0LW9mLXNjb3BlIGFuZCBjb21wbGV0ZWx5 IHVubmVjZXNzYXJ5LiAgV2hlbiB5b3UgdXNlIFNTTCB0byBhY2Nlc3MgYSBiYW5rIGFjY291bnQg ZG8geW91IGNhcmUgdGhhdCB0aGVyZSBtYXkgYmUgbXVsdGlwbGUgc2VydmVycyB0aGF0IGxvb2sg bGlrZSBhIHNpbmdsZSBlbnRpdHkgdG8gdGhlIHVzZXI/ICAgTmV3IGxheWVycyBvZiBhYnN0cmFj dGlvbiBhcmUgbm90IHJlcXVpcmVkIGZvciBzY2FsYWJpbGl0eS4gIFRoZSBzYW1lIHByb3RvY29s IGNhbiBiZSB1c2VkIHRvIG9uZSBvciBtdWx0aXBsZSBzZXJ2ZXJzLiAgWWVzLCBzb21lIGNvbnNp ZGVyYXRpb25zIG5lZWQgdG8gYmUgZGlzY3Vzc2VkIGFib3V0IGF1dGhlbnRpY2F0aW9uLiAgTm8g bmV3IGVudGl0aWVzLCBsYXllcnMsIGFyY2hpdGVjdHVyYWwgYmxvY2tzLCBjb25jZXB0cywgZnJh bWV3b3JrcyBvciBwcm90b2NvbHMgYXJlIHJlcXVpcmVkIGZvciChsHNlcnZpbmcgYSBodWdlIG51 bWJlciChrSChsC4NCg0KSSBhbHNvIHNlZSB0aGF0IHdlIHdhc3RlIGEgbG90IG9mIHdvcmRzIG9u IHRoZSBsaXN0IG9uIHRoaXMgdG9waWMgdGhhdCBtYXkgYmUgb3V0IG9mIHNjb3BlICh1cCB0byBj aGFpciB0byBtZWRpYXRlIKGtKS4gIFRoZSBwdXJwb3NlIG9mIHRoZSByZXF1aXJlbWVudHMgYW5k IHVzZSBjYXNlIHByb2Nlc3MgaXMgdG8gY3JlYXRlIGNvbnNlbnN1cyBmcm9tIHRoZSB0b3AgZG93 biB0byBmYWNpbGl0YXRlIHRoZSBjcmVhdGlvbiAgb2YgYSBzcGVjaWZpY2F0aW9uIG9mIHRoZSBi ZXN0IHBvc3NpYmxlIGRvY3VtZW50IGZyb20gdGhlIHdvcmtpbmcgZ3JvdXAuICBXZSBzaG91bGQg aWdub3JlIGFueSBkaXNjdXNzaW9ucyBhbmQgY29udHJpYnV0aW9ucyBvbiBvdXQtb2Ytc2NvcGUg Y29udHJpYnV0aW9ucyBhbmQgZm9jdXMgb24gdGhlIGN1cnJlbnQgc2NvcGUgYW5kIHdvcmsgaXRl bXMuDQoNClBhdWwNCg0KDQpQYXVsIEEuIExhbWJlcnQgfCBNYXJ2ZWxsIFNlbWljb25kdWN0b3Ig fCArMS02NTAtNzg3LTkxNDENCg0KRnJvbTogWmh1TGVpIFttYWlsdG86bGVpLnpodUBodWF3ZWku Y29tXQ0KU2VudDogVHVlc2RheSwgTWFyY2ggMTMsIDIwMTIgMTo0NyBBTQ0KVG86IFBhdWwgTGFt YmVydDsgcGF3c0BpZXRmLm9yZw0KU3ViamVjdDogUkU6IFRpbWUgdG8gcHJlc2VudCBteSBJRCBp biBJRVRGIFBhcmlzIG1lZXRpbmcNCg0KSGkgUGF1bCwNCg0KRG8geW91IHByZWZlciB0byByZW1v dmUgdGhpcyBpbnRlcm1lZGlhcnkgZnVuY3Rpb24/IFRoZSBpbnRlbnRpb24gb2YgdGhpcyBkcmFm dCBpcyBzdGlsbCB0byBwcm92aWRlIGEgcHJvcG9zYWwgb2YgZnJhbWV3b3JrIGFuZCBwcm90b2Nv bCwgcHJvYmFibHkgaW5jbHVkaW5nIHdob2xlIHBpY3R1cmUgd2l0aCBlc3NlbnRpYWwgZWxlbWVu dHMsIGRpc2NvdmVyeSwgcXVlcnksIHVwZGF0ZSBldGMuDQoNCkFzIHdoYXQgaXMgbWVudGlvbmVk IGluIGUtbWFpbCBsaXN0IGFuZCBsYXN0IEYyRiBtZWV0aW5nLCBwb3NzaWJseSwgdGhlIFBBV1Mg bWlnaHQgYmUgdmVyeSBleHRlbnNpYmxlIHNpbmNlIHRoZSBiYXNpYyBjb25jZXB0cywgc2NlbmFy aW9zIGFuZCByZXF1aXJlbWVudHMgYXJlIGVzdGFibGlzaGVkIHVwb24gdGhlIEZDQyBhbmQgb3Ro ZXIgcmVndWxhdG9yc6GvIHByb2Nlc3Mgb2Ygd2hpdGUgc3BhY2UuIFdlIHN0aWxsIGhhdmUgc29t ZSBwb3RlbnRpYWwgbmVlZHMgZG9pbmcgZnVydGhlciBhdCBmZWF0dXJlIGxldmVsIG9yIGV2ZW4g YXJjaGl0ZWN0dXJlIGxldmVsLiBBdCBsZWFzdCwgdGhlIGRlc2lnbiBvZiB0aGlzIHByb3RvY29s IHNob3VsZCBtYWtlIHN1cmUgdGhpcyBuZWVkLiBGcm9tIHRoaXMgcGVyc3BlY3RpdmUsIGF1dGhl bnRpY2F0aW9uIGFuZCBjb250ZW50IHByb3RlY3Rpb24gbWlnaHQgYmUgY29uc2lkZXJlZCBmdXJ0 aGVyLCBob3BlZnVsbHksIHdlIGFyZSBhYmxlIHRvIGRpc2N1c3Mgc2VjdXJpdHkgaW4gUGFyaXMu DQoNCldlIGFsc28gcmVhbGx5IG1ldCB2YXJ5IHNpdHVhdGlvbnMgb2YgZGlmZmVyZW50IGFyZWFz IGFuZCByZWdpb25zIHdobyBkb21pbmF0ZSBhIHF1aXRlIG51bWJlciBvZiBNYXN0ZXIgZGV2aWNl cy4gSSB3b3VsZCBub3QgaW1hZ2Ugb25lIGRhdGFiYXNlIHNlcnZpbmcgaHVnZSBudW1iZXIgb2Yg TWFzdGVyIGRldmljZXMuIEZvciBzb21lIHJlYXNvbnMsIHJlZ3VsYXRvciBtYXkgYXV0aG9yaXpl IGJyYW5jaGVzIHRvIGFkbWluaXN0cmF0ZSBvciBtYWludGFpbiB3aGl0ZSBzcGFjZSBkYXRhIGJh c2Ugd2hpY2ggZG9taW5hdGVzIGEgcGFydGljdWxhciByZWdpb24uIEkgZG8gbm90IHRoaW5rIHRo ZSBtdWx0aXBsZSBkYXRhIGJhc2VzIG9yIGRpc3RyaWJ1dGVkIGRhdGEgbW9kZWwgZnJhbWV3b3Jr IGFyZSBjb250cm92ZXJzaWFsIHRvIHVzLCBidXQgdGhlIGFkZGl0aW9uYWwgZnVuY3Rpb25zIG9m IHRoaXMgY29vcmRpbmF0aW5nIGRhdGEgYmFzZS4gVGhpcyBpbnRlcm1lZGlhdGUgbm9kZSB3aXRo IHdoaXRlIHNwYWNlIHNwZWN0cnVtIGRlY2lzaW9uIG1ha2luZyBmdW5jdGlvbiBpcyB0aGUgaXNz dWUgb2YgZXh0ZW5zaWJpbGl0eSwgd2hpY2ggY2FuIGJlIGhlbHBmdWwgd2hlbiBhZGRpbmcgc29t ZSBmZWF0dXJlIHdoaWNoIGlzIG5vdCBkZXNpcmVkIHRvIG1haW4gZGF0YSBiYXNlLiBEZWNpc2lv biBtYWtpbmcgZnVuY3Rpb24gY291bGQgYmUgbm90IGEgZnVuY3Rpb25hbGl0eSBvZiBtYWluIGRh dGEgYmFzZSB3aGljaCBuZWVkcyB0byBiZSB2ZXJ5IHN0YWJsZSBhbmQgc3RhdGljLiBJZiB3ZSBy ZWFsbHkgZXh0ZW50IGNvZXhpc3RlbmNlIG9yIGludGVyZmVyZW5jZSBhdm9pZGFuY2Ugcm9sZSB0 byBQQVdTIHByb3RvY29sLCBpdCB3b3VsZCBiZSBlYXNpZXIgdG8gZXh0ZW50IGludGVybWVkaWFy eSBmdW5jdGlvbiB3aXRob3V0IGltcGFjdHMgb24gZnJhbWV3b3JrIG9mIFBBV1MsIGFuZCwgc3Ry dWN0dXJlIGFuZCBwcm90b2NvbCBvZiBQQVdTLiBUaGlzIG5vZGUgaXMgYmVsaWV2ZWQgdG8gZXhp c3QgZm9yIHRoaXMgcHVycG9zZS4NCg0KSSBhbSBub3Qgc3VyZSB0aGF0IHlvdSB3b3VsZCBzdXBw b3J0IHRoaXMgaWRlYSwgYnV0IHRoZSB0ZXh0IGRlc2NyaWJpbmcgdGhpcyBjYW4gbWFrZSB0aGlu Z3MgY2xlYXJlciB3aGVuIHRhbGtpbmcgYWJvdXQgdGhpcy4NCg0KQmVzdCByZWdhcmRzLA0KWmh1 IExlaQ0KDQoNCreivP7IyzogUGF1bCBMYW1iZXJ0IFttYWlsdG86cGF1bEBtYXJ2ZWxsLmNvbV0N Creiy83KsbzkOiAyMDEyxOoz1MIxM8jVIDE1OjI4DQrK1bz+yMs6IFpodUxlaTsgcGF3c0BpZXRm Lm9yZw0K1vfM4jogUkU6IFRpbWUgdG8gcHJlc2VudCBteSBJRCBpbiBJRVRGIFBhcmlzIG1lZXRp bmcNCg0KDQpEaWQgb3VyIGNvbnNlbnN1cyBwcm9jZXNzIGluY2x1ZGUgYSBjb29yZGluYXRpbmcg aW50ZXJtZWRpYXJ5IGZ1bmN0aW9uPw0KDQogICBUaGUgY29vcmRpbmF0aW5nIGRhdGFiYXNlIGNh biBnZXQgd2hpdGUgc3BhY2UgY2hhbm5lbHMgZnJvbSBkYXRhYmFzZSwNCiAgIHJlY2VpdmUgdGhl IHdoaXRlIHNwYWNlIHF1ZXJ5aW5nIG1lc3NhZ2UgZnJvbSBtYXN0ZXIgZGV2aWNlIGFuZA0KICAg cHJvdmlkZSB0aGUgYXZhaWxhYmxlIHdoaXRlIHNwYWNlIGNoYW5uZWxzIGZvciBtYXN0ZXIgZGV2 aWNlcyB3aXRoDQogICBzb21lIGRlZ3JlZSBkZWNpc2lvbiBtYWtpbmcgcHJvY2Vzcy4gIFRoZXNl IGRlY2lzaW9uIG1ha2luZyBwcm9jZXNzDQogICBtaWdodCBwcm92aWRlIGZ1bmN0aW9uYWxpdHkg b2Ygd2hpdGUgc3BhY2UgYWNjZXNzIHByb3RvY29sIHBvd2VyIHRvDQogICByZXNwb25zZSBhdmFp bGFibGUgY2hhbm5lbHMgYWNjb3JkaW5nIHRvIHJlY2VpdmVkIGRldmljZSBwYXJhbWV0ZXJzDQog ICAoZS5nLiBwb3dlciwgUkYgcGFyYW1ldGVyKSwgbG9jYXRpb24gaW5mb3JtYXRpb24oZS5nLiBh bHRpdHVkZSwNCiAgIHBvc2l0aW9uIGFuZCBkaXJlY3Rpb24gb2YgYW50ZW5uYSApIGFuZCBzb21l IHBhcnRpY3VsYXIgd2hpdGUgc3BhY2UNCiAgIHNwZWN0cnVtIGRlY2lzaW9uIG1ha2luZyBwb2xp Y2llcy4NCg0KRG9uoa90IHNlZSB0aGF0IHRoaXMgaXMgaW4gc2NvcGUuIFNlZW1zIGluYXBwcm9w cmlhdGUgdG8gY3JlYXRlIGNvbXBsZXRlIElEcyB3aXRoIGZlYXR1cmVzIHRoYXQgYXJlIG91dC1v Zi1zY29wZS4NCg0KUGF1bA0KDQoNCkZyb206IHBhd3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv OnBhd3MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFpodUxlaQ0KU2VudDogVHVlc2Rh eSwgTWFyY2ggMTMsIDIwMTIgMTI6MDIgQU0NClRvOiBwYXdzQGlldGYub3JnDQpTdWJqZWN0OiBb cGF3c10gVGltZSB0byBwcmVzZW50IG15IElEIGluIElFVEYgUGFyaXMgbWVldGluZw0KDQpIaSBG b2xrcyBhbmQgY2hhaXJzLA0KDQpBcyB3aGF0IHlvdSBtaWdodCBub3RpY2UsIEkgdXBsb2FkZWQg YSBJRCBvbiBQQVdTIGZyYW1ld29yayBhbmQgcHJvdG9jb2wgd2hpY2ggaXMgdG8gZnVsZmlsbCBQ QVdTIHJlcXVpcmVtZW50cyBhbmQgcmVndWxhdG9yc6GvIHJlcXVpcmVtZW50cywgobB3d3cuaWV0 Zi5vcmcvaWQvZHJhZnQtbGVpLXBhd3MtZnJhbWV3b3JrLWRhdGFtb2RlbC0wMC50eHShsS4gIEkg d291bGQgdmVyeSBsaWtlIHRvIHJlcXVlc3QgMjUgbWludXRlcyBwcmVzZW50aW5nIGFuZCBkaXNj dXNzaW5nIGl0IGR1cmluZyBJRVRGIFBhcmlzIG1lZXRpbmcuDQoNCkJlc3QgcmVnYXJkcywNClpo dSBMZWkNCg== --_000_7BAC95F5A7E67643AAFB2C31BEE662D015E331DAA3SCVEXCH2marve_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Zhu,=

&n= bsp;

> I am not su= re that you would support this idea, but the text describing this can make thi= ngs clearer when talking about this.

 

No I do not support the idea of additional layers of =A1=B0coordinating databa= se=A1=B1.  Especially for detailed designs using HTTPS.

 

> I would not image one database serving huge number of Master devices. For s= ome reasons, regulator

>may authorize branches to administrate or maintain white space data base which dominates a particular region.

 

Out-of-scope and completely unnecessary.  When you use SSL to access a bank account= do you care that there may be multiple servers that look like a single entity = to the user?   New layers of abstraction are not required for scalability.  The same protocol can be used to one or multiple servers.  Yes, some considerations need to be discussed about authentication.  No new entities, layers, architectural blocks, concep= ts, frameworks or protocols are required for =A1=B0serving a huge number =A1=AD =A1=B0.

 

I also see that we waste a lot of words on the list on this topic that may be= out of scope (up to chair to mediate =A1=AD).  The purpose of the requirem= ents and use case process is to create consensus from the top down to facilitate the= creation  of a specification of the best possible document from the working group.  We should ignore any discussions and contributions on out-of-s= cope contributions and focus on the current scope and work items.

 

Paul

&n= bsp;

 

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

&n= bsp;

From: ZhuLei [mailto:lei.zhu@huawei.com]
Sent: Tuesday, March 13, 2012 1:47 AM
To: Paul Lambert; paws@ietf.org
Subject: RE: Time to present my ID in IETF Paris meeting<= /span>

 

Hi Paul,

 =

Do you prefer to remove = this intermediary function? The intention of this draft is still to provide a proposal of framework and protocol, probably including whole picture with essential elements, discovery, query, update etc.

 =

As what is mentioned in = e-mail list and last F2F meeting, possibly, the PAWS might be very extensible sinc= e the basic concepts, scenarios and requirements are established upon the FCC= and other regulators=A1=AF process of white space. We still have some potential= needs doing further at feature level or even architecture level. At least, the de= sign of this protocol should make sure this need. From this perspective, authentication and content protection might be considered further, hopefull= y, we are able to discuss security in Paris.

 =

We also really met vary situations of different areas and regions who dominate= a quite number of Master devices. I would not image one database serving huge number of Master devices. For some reasons, regulator may authorize branche= s to administrate or maintain white space data base which dominates a particular region. I do not think the multiple data bases or distributed data model framework are controversial to us, but the additional functions of this coordinating data base. This intermediate node with white space spectrum decision making function is the issue of extensibility, which can be helpfu= l when adding some feature which is not desired to main data base. Decision making function could be not a functionality of main data base which needs = to be very stable and static. If we really extent coexistence or interference avoidance role to PAWS protocol, it would be easier to extent intermediary function without impacts on framework of PAWS, and, structure and protocol = of PAWS. This node is believed to exist for this purpose.

 

I am not sure that you would support this idea, but the text describing this = can make things clearer when talking about this.

 

Best regards,

Zhu Lei

 

 =

=B7=A2=BC=FE=C8=CB= : Paul Lambert [mailto:paul@marvell.com]
= =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C213=C8=D5 15:28
= =CA=D5=BC=FE=C8=CB: ZhuLei; paws@ietf.org
= =D6=F7=CC=E2: RE: Time to present my ID in IETF Paris meeting=

 

&n= bsp;

Did our consensus process include a coordinating intermediary function?<= /span>

 

   The coordinating database ca= n get white space channels from database,

   receive the white space quer= ying message from master device and

   provide the available white space channels for master devices with

   some degree decision making process.  These decision making process =

   might provide functionality = of white space access protocol power to

   response available channels according to received device parameters

   (e.g. power, RF parameter), location information(e.g. altitude,

   position and direction of antenna ) and some particular white space

   spectrum decision making policies.

&n= bsp;

Don=A1= =AFt see that this is in scope. Seems inappropriate to create complete IDs with features = that are out-of-scope.

&n= bsp;

Paul

&n= bsp;

&n= bsp;

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Zh= uLei
Sent: Tuesday, March 13, 2012 12:02 AM
To: paws@ietf.org
Subject: [paws] Time to present my ID in IETF Paris meeting

 

Hi Folks and chairs,

 

As what you might notice, I uploaded a ID on PAWS fram= ework and protocol which is to fulfill PAWS requirements and regulators=A1=AF requirements, =A1=B0www.ietf.org/id/draft-lei-paws-framework-datamodel-00.t= xt=A1=B1.  I would very like to request 25 minutes presenting and discussing it during IETF Paris meeting.

 

Best regards,

Zhu Lei

--_000_7BAC95F5A7E67643AAFB2C31BEE662D015E331DAA3SCVEXCH2marve_-- From Gabor.Bajko@nokia.com Tue Mar 13 16:42:58 2012 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 4947C21E8072 for ; Tue, 13 Mar 2012 16:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEqqqlVpCoAI for ; Tue, 13 Mar 2012 16:42:57 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id D5C5C21E8013 for ; Tue, 13 Mar 2012 16:42:56 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q2DNgs6F011191 for ; Wed, 14 Mar 2012 01:42:55 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.23]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Mar 2012 01:42:54 +0200 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.157]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.01.0355.003; Wed, 14 Mar 2012 00:42:53 +0100 From: To: Thread-Topic: Time to present my ID in IETF Paris meeting Thread-Index: Ac0A5yy1glWG2nAiTGCvtquF5UMsewAA1ZbgAACAvmAAHF/YoAACvuxQ Date: Tue, 13 Mar 2012 23:42:53 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601E1F496@008-AM1MPN1-006.mgdnok.nokia.com> References: <470F27D1263A1B4EB73491ED995DE62516234020@szxeml504-mbs.china.huawei.com> <7BAC95F5A7E67643AAFB2C31BEE662D015E331D955@SC-VEXCH2.marvell.com> <470F27D1263A1B4EB73491ED995DE625162340C4@szxeml504-mbs.china.huawei.com> <7BAC95F5A7E67643AAFB2C31BEE662D015E331DAA3@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D015E331DAA3@SC-VEXCH2.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.197.99.162] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47601E1F496008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 13 Mar 2012 23:42:54.0230 (UTC) FILETIME=[02BB2B60:01CD0173] X-Nokia-AV: Clean Subject: Re: [paws] Time to present my ID in IETF Paris 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: Tue, 13 Mar 2012 23:42:58 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601E1F496008AM1MPN1006mg_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 V2h5IHdvdWxkIHRoZSBjaGFpcnMgbWVkaWF0ZSB0aGlzIGRpc2N1c3Npb24/IFRoZXJloa9zIGFu IGluZGl2aWR1YWwgc3VibWlzc2lvbiBhbmQgdGhlIGF1dGhvciBpcyBzZWVraW5nIGNvbW1lbnRz IG9uIHRoZSBsaXN0IGJlZm9yZSB0aGUgcHJlc2VudGF0aW9uIGluIHRoZSBmMmYuDQpUaGF0IGlz IGhvdyBpZXRmIHdvcmtzLCB3ZSBuZWVkIGNvbW1lbnRzIHRvIHRoZSBsaXN0IHRvIG1ha2UgcHJv Z3Jlc3Mgb25lIHdheSBvciB0aGUgb3RoZXIuDQoNCg0KLSAgICAgICAgICBHYWJvcg0KDQpGcm9t OiBwYXdzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBleHQgUGF1bCBMYW1iZXJ0DQpTZW50OiBUdWVzZGF5LCBNYXJjaCAxMywgMjAx MiAyOjMyIFBNDQpUbzogWmh1TGVpOyBwYXdzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Bhd3Nd IFRpbWUgdG8gcHJlc2VudCBteSBJRCBpbiBJRVRGIFBhcmlzIG1lZXRpbmcNCg0KSGkgWmh1LA0K DQo+IEkgYW0gbm90IHN1cmUgdGhhdCB5b3Ugd291bGQgc3VwcG9ydCB0aGlzIGlkZWEsIGJ1dCB0 aGUgdGV4dCBkZXNjcmliaW5nIHRoaXMgY2FuIG1ha2UgdGhpbmdzIGNsZWFyZXIgd2hlbiB0YWxr aW5nIGFib3V0IHRoaXMuDQoNCk5vIEkgZG8gbm90IHN1cHBvcnQgdGhlIGlkZWEgb2YgYWRkaXRp b25hbCBsYXllcnMgb2YgobBjb29yZGluYXRpbmcgZGF0YWJhc2WhsS4gIEVzcGVjaWFsbHkgZm9y IGRldGFpbGVkIGRlc2lnbnMgdXNpbmcgSFRUUFMuDQoNCj4gSSB3b3VsZCBub3QgaW1hZ2Ugb25l IGRhdGFiYXNlIHNlcnZpbmcgaHVnZSBudW1iZXIgb2YgTWFzdGVyIGRldmljZXMuIEZvciBzb21l IHJlYXNvbnMsIHJlZ3VsYXRvcg0KPm1heSBhdXRob3JpemUgYnJhbmNoZXMgdG8gYWRtaW5pc3Ry YXRlIG9yIG1haW50YWluIHdoaXRlIHNwYWNlIGRhdGEgYmFzZSB3aGljaCBkb21pbmF0ZXMgYSBw YXJ0aWN1bGFyIHJlZ2lvbi4NCg0KT3V0LW9mLXNjb3BlIGFuZCBjb21wbGV0ZWx5IHVubmVjZXNz YXJ5LiAgV2hlbiB5b3UgdXNlIFNTTCB0byBhY2Nlc3MgYSBiYW5rIGFjY291bnQgZG8geW91IGNh cmUgdGhhdCB0aGVyZSBtYXkgYmUgbXVsdGlwbGUgc2VydmVycyB0aGF0IGxvb2sgbGlrZSBhIHNp bmdsZSBlbnRpdHkgdG8gdGhlIHVzZXI/ICAgTmV3IGxheWVycyBvZiBhYnN0cmFjdGlvbiBhcmUg bm90IHJlcXVpcmVkIGZvciBzY2FsYWJpbGl0eS4gIFRoZSBzYW1lIHByb3RvY29sIGNhbiBiZSB1 c2VkIHRvIG9uZSBvciBtdWx0aXBsZSBzZXJ2ZXJzLiAgWWVzLCBzb21lIGNvbnNpZGVyYXRpb25z IG5lZWQgdG8gYmUgZGlzY3Vzc2VkIGFib3V0IGF1dGhlbnRpY2F0aW9uLiAgTm8gbmV3IGVudGl0 aWVzLCBsYXllcnMsIGFyY2hpdGVjdHVyYWwgYmxvY2tzLCBjb25jZXB0cywgZnJhbWV3b3JrcyBv ciBwcm90b2NvbHMgYXJlIHJlcXVpcmVkIGZvciChsHNlcnZpbmcgYSBodWdlIG51bWJlciChrSCh sC4NCg0KSSBhbHNvIHNlZSB0aGF0IHdlIHdhc3RlIGEgbG90IG9mIHdvcmRzIG9uIHRoZSBsaXN0 IG9uIHRoaXMgdG9waWMgdGhhdCBtYXkgYmUgb3V0IG9mIHNjb3BlICh1cCB0byBjaGFpciB0byBt ZWRpYXRlIKGtKS4gIFRoZSBwdXJwb3NlIG9mIHRoZSByZXF1aXJlbWVudHMgYW5kIHVzZSBjYXNl IHByb2Nlc3MgaXMgdG8gY3JlYXRlIGNvbnNlbnN1cyBmcm9tIHRoZSB0b3AgZG93biB0byBmYWNp bGl0YXRlIHRoZSBjcmVhdGlvbiAgb2YgYSBzcGVjaWZpY2F0aW9uIG9mIHRoZSBiZXN0IHBvc3Np YmxlIGRvY3VtZW50IGZyb20gdGhlIHdvcmtpbmcgZ3JvdXAuICBXZSBzaG91bGQgaWdub3JlIGFu eSBkaXNjdXNzaW9ucyBhbmQgY29udHJpYnV0aW9ucyBvbiBvdXQtb2Ytc2NvcGUgY29udHJpYnV0 aW9ucyBhbmQgZm9jdXMgb24gdGhlIGN1cnJlbnQgc2NvcGUgYW5kIHdvcmsgaXRlbXMuDQoNClBh dWwNCg0KDQpQYXVsIEEuIExhbWJlcnQgfCBNYXJ2ZWxsIFNlbWljb25kdWN0b3IgfCArMS02NTAt Nzg3LTkxNDENCg0KRnJvbTogWmh1TGVpIFttYWlsdG86bGVpLnpodUBodWF3ZWkuY29tXTxtYWls dG86W21haWx0bzpsZWkuemh1QGh1YXdlaS5jb21dPg0KU2VudDogVHVlc2RheSwgTWFyY2ggMTMs IDIwMTIgMTo0NyBBTQ0KVG86IFBhdWwgTGFtYmVydDsgcGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3 c0BpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBUaW1lIHRvIHByZXNlbnQgbXkgSUQgaW4gSUVURiBQ YXJpcyBtZWV0aW5nDQoNCkhpIFBhdWwsDQoNCkRvIHlvdSBwcmVmZXIgdG8gcmVtb3ZlIHRoaXMg aW50ZXJtZWRpYXJ5IGZ1bmN0aW9uPyBUaGUgaW50ZW50aW9uIG9mIHRoaXMgZHJhZnQgaXMgc3Rp bGwgdG8gcHJvdmlkZSBhIHByb3Bvc2FsIG9mIGZyYW1ld29yayBhbmQgcHJvdG9jb2wsIHByb2Jh Ymx5IGluY2x1ZGluZyB3aG9sZSBwaWN0dXJlIHdpdGggZXNzZW50aWFsIGVsZW1lbnRzLCBkaXNj b3ZlcnksIHF1ZXJ5LCB1cGRhdGUgZXRjLg0KDQpBcyB3aGF0IGlzIG1lbnRpb25lZCBpbiBlLW1h aWwgbGlzdCBhbmQgbGFzdCBGMkYgbWVldGluZywgcG9zc2libHksIHRoZSBQQVdTIG1pZ2h0IGJl IHZlcnkgZXh0ZW5zaWJsZSBzaW5jZSB0aGUgYmFzaWMgY29uY2VwdHMsIHNjZW5hcmlvcyBhbmQg cmVxdWlyZW1lbnRzIGFyZSBlc3RhYmxpc2hlZCB1cG9uIHRoZSBGQ0MgYW5kIG90aGVyIHJlZ3Vs YXRvcnOhryBwcm9jZXNzIG9mIHdoaXRlIHNwYWNlLiBXZSBzdGlsbCBoYXZlIHNvbWUgcG90ZW50 aWFsIG5lZWRzIGRvaW5nIGZ1cnRoZXIgYXQgZmVhdHVyZSBsZXZlbCBvciBldmVuIGFyY2hpdGVj dHVyZSBsZXZlbC4gQXQgbGVhc3QsIHRoZSBkZXNpZ24gb2YgdGhpcyBwcm90b2NvbCBzaG91bGQg bWFrZSBzdXJlIHRoaXMgbmVlZC4gRnJvbSB0aGlzIHBlcnNwZWN0aXZlLCBhdXRoZW50aWNhdGlv biBhbmQgY29udGVudCBwcm90ZWN0aW9uIG1pZ2h0IGJlIGNvbnNpZGVyZWQgZnVydGhlciwgaG9w ZWZ1bGx5LCB3ZSBhcmUgYWJsZSB0byBkaXNjdXNzIHNlY3VyaXR5IGluIFBhcmlzLg0KDQpXZSBh bHNvIHJlYWxseSBtZXQgdmFyeSBzaXR1YXRpb25zIG9mIGRpZmZlcmVudCBhcmVhcyBhbmQgcmVn aW9ucyB3aG8gZG9taW5hdGUgYSBxdWl0ZSBudW1iZXIgb2YgTWFzdGVyIGRldmljZXMuIEkgd291 bGQgbm90IGltYWdlIG9uZSBkYXRhYmFzZSBzZXJ2aW5nIGh1Z2UgbnVtYmVyIG9mIE1hc3RlciBk ZXZpY2VzLiBGb3Igc29tZSByZWFzb25zLCByZWd1bGF0b3IgbWF5IGF1dGhvcml6ZSBicmFuY2hl cyB0byBhZG1pbmlzdHJhdGUgb3IgbWFpbnRhaW4gd2hpdGUgc3BhY2UgZGF0YSBiYXNlIHdoaWNo IGRvbWluYXRlcyBhIHBhcnRpY3VsYXIgcmVnaW9uLiBJIGRvIG5vdCB0aGluayB0aGUgbXVsdGlw bGUgZGF0YSBiYXNlcyBvciBkaXN0cmlidXRlZCBkYXRhIG1vZGVsIGZyYW1ld29yayBhcmUgY29u dHJvdmVyc2lhbCB0byB1cywgYnV0IHRoZSBhZGRpdGlvbmFsIGZ1bmN0aW9ucyBvZiB0aGlzIGNv b3JkaW5hdGluZyBkYXRhIGJhc2UuIFRoaXMgaW50ZXJtZWRpYXRlIG5vZGUgd2l0aCB3aGl0ZSBz cGFjZSBzcGVjdHJ1bSBkZWNpc2lvbiBtYWtpbmcgZnVuY3Rpb24gaXMgdGhlIGlzc3VlIG9mIGV4 dGVuc2liaWxpdHksIHdoaWNoIGNhbiBiZSBoZWxwZnVsIHdoZW4gYWRkaW5nIHNvbWUgZmVhdHVy ZSB3aGljaCBpcyBub3QgZGVzaXJlZCB0byBtYWluIGRhdGEgYmFzZS4gRGVjaXNpb24gbWFraW5n IGZ1bmN0aW9uIGNvdWxkIGJlIG5vdCBhIGZ1bmN0aW9uYWxpdHkgb2YgbWFpbiBkYXRhIGJhc2Ug d2hpY2ggbmVlZHMgdG8gYmUgdmVyeSBzdGFibGUgYW5kIHN0YXRpYy4gSWYgd2UgcmVhbGx5IGV4 dGVudCBjb2V4aXN0ZW5jZSBvciBpbnRlcmZlcmVuY2UgYXZvaWRhbmNlIHJvbGUgdG8gUEFXUyBw cm90b2NvbCwgaXQgd291bGQgYmUgZWFzaWVyIHRvIGV4dGVudCBpbnRlcm1lZGlhcnkgZnVuY3Rp b24gd2l0aG91dCBpbXBhY3RzIG9uIGZyYW1ld29yayBvZiBQQVdTLCBhbmQsIHN0cnVjdHVyZSBh bmQgcHJvdG9jb2wgb2YgUEFXUy4gVGhpcyBub2RlIGlzIGJlbGlldmVkIHRvIGV4aXN0IGZvciB0 aGlzIHB1cnBvc2UuDQoNCkkgYW0gbm90IHN1cmUgdGhhdCB5b3Ugd291bGQgc3VwcG9ydCB0aGlz IGlkZWEsIGJ1dCB0aGUgdGV4dCBkZXNjcmliaW5nIHRoaXMgY2FuIG1ha2UgdGhpbmdzIGNsZWFy ZXIgd2hlbiB0YWxraW5nIGFib3V0IHRoaXMuDQoNCkJlc3QgcmVnYXJkcywNClpodSBMZWkNCg0K DQq3orz+yMs6IFBhdWwgTGFtYmVydCBbbWFpbHRvOnBhdWxAbWFydmVsbC5jb21dPG1haWx0bzpb bWFpbHRvOnBhdWxAbWFydmVsbC5jb21dPg0Kt6LLzcqxvOQ6IDIwMTLE6jPUwjEzyNUgMTU6MjgN CsrVvP7IyzogWmh1TGVpOyBwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPg0K1vfM 4jogUkU6IFRpbWUgdG8gcHJlc2VudCBteSBJRCBpbiBJRVRGIFBhcmlzIG1lZXRpbmcNCg0KDQpE aWQgb3VyIGNvbnNlbnN1cyBwcm9jZXNzIGluY2x1ZGUgYSBjb29yZGluYXRpbmcgaW50ZXJtZWRp YXJ5IGZ1bmN0aW9uPw0KDQogICBUaGUgY29vcmRpbmF0aW5nIGRhdGFiYXNlIGNhbiBnZXQgd2hp dGUgc3BhY2UgY2hhbm5lbHMgZnJvbSBkYXRhYmFzZSwNCiAgIHJlY2VpdmUgdGhlIHdoaXRlIHNw YWNlIHF1ZXJ5aW5nIG1lc3NhZ2UgZnJvbSBtYXN0ZXIgZGV2aWNlIGFuZA0KICAgcHJvdmlkZSB0 aGUgYXZhaWxhYmxlIHdoaXRlIHNwYWNlIGNoYW5uZWxzIGZvciBtYXN0ZXIgZGV2aWNlcyB3aXRo DQogICBzb21lIGRlZ3JlZSBkZWNpc2lvbiBtYWtpbmcgcHJvY2Vzcy4gIFRoZXNlIGRlY2lzaW9u IG1ha2luZyBwcm9jZXNzDQogICBtaWdodCBwcm92aWRlIGZ1bmN0aW9uYWxpdHkgb2Ygd2hpdGUg c3BhY2UgYWNjZXNzIHByb3RvY29sIHBvd2VyIHRvDQogICByZXNwb25zZSBhdmFpbGFibGUgY2hh bm5lbHMgYWNjb3JkaW5nIHRvIHJlY2VpdmVkIGRldmljZSBwYXJhbWV0ZXJzDQogICAoZS5nLiBw b3dlciwgUkYgcGFyYW1ldGVyKSwgbG9jYXRpb24gaW5mb3JtYXRpb24oZS5nLiBhbHRpdHVkZSwN CiAgIHBvc2l0aW9uIGFuZCBkaXJlY3Rpb24gb2YgYW50ZW5uYSApIGFuZCBzb21lIHBhcnRpY3Vs YXIgd2hpdGUgc3BhY2UNCiAgIHNwZWN0cnVtIGRlY2lzaW9uIG1ha2luZyBwb2xpY2llcy4NCg0K RG9uoa90IHNlZSB0aGF0IHRoaXMgaXMgaW4gc2NvcGUuIFNlZW1zIGluYXBwcm9wcmlhdGUgdG8g Y3JlYXRlIGNvbXBsZXRlIElEcyB3aXRoIGZlYXR1cmVzIHRoYXQgYXJlIG91dC1vZi1zY29wZS4N Cg0KUGF1bA0KDQoNCkZyb206IHBhd3MtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cGF3cy1ib3Vu Y2VzQGlldGYub3JnPiBbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZ108bWFpbHRvOlttYWls dG86cGF3cy1ib3VuY2VzQGlldGYub3JnXT4gT24gQmVoYWxmIE9mIFpodUxlaQ0KU2VudDogVHVl c2RheSwgTWFyY2ggMTMsIDIwMTIgMTI6MDIgQU0NClRvOiBwYXdzQGlldGYub3JnPG1haWx0bzpw YXdzQGlldGYub3JnPg0KU3ViamVjdDogW3Bhd3NdIFRpbWUgdG8gcHJlc2VudCBteSBJRCBpbiBJ RVRGIFBhcmlzIG1lZXRpbmcNCg0KSGkgRm9sa3MgYW5kIGNoYWlycywNCg0KQXMgd2hhdCB5b3Ug bWlnaHQgbm90aWNlLCBJIHVwbG9hZGVkIGEgSUQgb24gUEFXUyBmcmFtZXdvcmsgYW5kIHByb3Rv Y29sIHdoaWNoIGlzIHRvIGZ1bGZpbGwgUEFXUyByZXF1aXJlbWVudHMgYW5kIHJlZ3VsYXRvcnOh ryByZXF1aXJlbWVudHMsIKGwd3d3LmlldGYub3JnL2lkL2RyYWZ0LWxlaS1wYXdzLWZyYW1ld29y ay1kYXRhbW9kZWwtMDAudHh0PGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtbGVpLXBhd3Mt ZnJhbWV3b3JrLWRhdGFtb2RlbC0wMC50eHQ+obEuICBJIHdvdWxkIHZlcnkgbGlrZSB0byByZXF1 ZXN0IDI1IG1pbnV0ZXMgcHJlc2VudGluZyBhbmQgZGlzY3Vzc2luZyBpdCBkdXJpbmcgSUVURiBQ YXJpcyBtZWV0aW5nLg0KDQpCZXN0IHJlZ2FyZHMsDQpaaHUgTGVpDQo= --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601E1F496008AM1MPN1006mg_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Why w= ould the chairs mediate this discussion? There=A1=AFs an individual submiss= ion and the author is seeking comments on the list before the presentation = in the f2f.

That = is how ietf works, we need comments to the list to make progress one way or= the other.

=  

-          Gabor

=  

From: paws-bounces@ietf.org [mailto:paws-bounces= @ietf.org] On Behalf Of ext Paul Lambert
Sent: Tuesday, March 13, 2012 2:32 PM
To: ZhuLei; paws@ietf.org
Subject: Re: [paws] Time to present my ID in IETF Paris meeting=

 =

Hi Zh= u,

=  

> I am not sure that you would support this idea, but the text describing = this can make things clearer when talking about this.

 

No I do not support the idea of additional layers of =A1= =B0coordinating database=A1=B1.  Especially for detailed designs using= HTTPS.

 

> I would not image one database serving huge number = of Master devices. For some reasons, regulator

>may authorize branches to administrate or maintain w= hite space data base which dominates a particular region.=

 

Out-of-scope and completely unnecessary.  When you = use SSL to access a bank account do you care that there may be multiple ser= vers that look like a single entity to the user?   New layers of abstraction are not required for scalability.  The same= protocol can be used to one or multiple servers.  Yes, some considera= tions need to be discussed about authentication.  No new entities, lay= ers, architectural blocks, concepts, frameworks or protocols are required for =A1=B0serving a huge number =A1=AD =A1=B0.

 

I also see that we waste a lot of words on the list on t= his topic that may be out of scope (up to chair to mediate =A1=AD).  T= he purpose of the requirements and use case process is to create consensus from the top down to facilitate the creation  = of a specification of the best possible document from the working group.&nb= sp; We should ignore any discussions and contributions on out-of-scope cont= ributions and focus on the current scope and work items.

 

Paul

=  

 

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

=  

From: ZhuLei [mailto:lei.zhu@huawei.com]<= /a>
Sent: Tuesday, March 13, 2012 1:47 AM
To: Paul Lambert; paws@ietf.org=
Subject: RE: Time to present my ID in IETF Paris meeting<= /span>

 =

Hi Paul,

 

Do you prefer to remov= e this intermediary function? The intention of this draft is still to provi= de a proposal of framework and protocol, probably including whole picture w= ith essential elements, discovery, query, update etc.

 

As what is mentioned i= n e-mail list and last F2F meeting, possibly, the PAWS might be very extens= ible since the basic concepts, scenarios and requirements are established u= pon the FCC and other regulators=A1=AF process of white space. We still have some potential needs doing further at featur= e level or even architecture level. At least, the design of this protocol s= hould make sure this need. From this perspective, authentication and conten= t protection might be considered further, hopefully, we are able to discuss security in Paris.

 

We also really met vary situations of different areas an= d regions who dominate a quite number of Master devices. I would not image = one database serving huge number of Master devices. For some reasons, regulator may authorize branches to administrat= e or maintain white space data base which dominates a particular region. I = do not think the multiple data bases or distributed data model framework ar= e controversial to us, but the additional functions of this coordinating data base. This intermediate node with whit= e space spectrum decision making function is the issue of extensibility, wh= ich can be helpful when adding some feature which is not desired to main da= ta base. Decision making function could be not a functionality of main data base which needs to be very stab= le and static. If we really extent coexistence or interference avoidance ro= le to PAWS protocol, it would be easier to extent intermediary function wit= hout impacts on framework of PAWS, and, structure and protocol of PAWS. This node is believed to exist for th= is purpose.

 

I am not sure that you would support this idea, but the = text describing this can make things clearer when talking about this.<= /o:p>

 

Best regards,

Zhu Lei

 

 

=B7=A2=BC=FE=C8= =CB: Paul Lambert [mailto:paul@marvell.= com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C213=C8=D5 15:28
=CA=D5=BC=FE=C8=CB: ZhuLei; paws@ietf.org
=D6=F7=CC=E2: RE: Time to present my ID = in IETF Paris meeting

 =

=  

Did o= ur consensus process include a coordinating intermediary function?

 =

   The = coordinating database can get white space channels from database,

   rece= ive the white space querying message from master device and

   prov= ide the available white space channels for master devices with

   some= degree decision making process.  These decision making process

   migh= t provide functionality of white space access protocol power to<= /span>

   resp= onse available channels according to received device parameters<= /span>

   (e.g= . power, RF parameter), location information(e.g. altitude,

   posi= tion and direction of antenna ) and some particular white space<= /span>

   spec= trum decision making policies.

=  

Don= =A1=AFt see that this is in scope. Seems inappropriate to create complete I= Ds with features that are out-of-scope.

=  

Paul =

=  

=  

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ZhuLei
Sent: Tuesday, March 13, 2012 12:02 AM
To: paws@ietf.org
Subject: [paws] Time to present my ID in IETF Paris meeting

 =

Hi Folks and chairs,

 

As what you might notice, I uploaded a ID on PAWS fr= amework and protocol which is to fulfill PAWS requirements and regulators= =A1=AF requirements, =A1=B0www.ietf.org/id/draft-lei-paws-framework-datam= odel-00.txt=A1=B1.  I would very like to request 25 minutes presenting and discussing it= during IETF Paris meeting.

 

Best regards,

Zhu Lei

--_000_1ECAFF543A2FED4EA2BEB6CACE08E47601E1F496008AM1MPN1006mg_-- From Basavaraj.Patil@nokia.com Tue Mar 13 17:06:20 2012 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 2B5AA21E8079 for ; Tue, 13 Mar 2012 17:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.044 X-Spam-Level: X-Spam-Status: No, score=-103.044 tagged_above=-999 required=5 tests=[AWL=-0.649, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, 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 u2aFm3wS2SE3 for ; Tue, 13 Mar 2012 17:06:18 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id B9FA921E8071 for ; Tue, 13 Mar 2012 17:06:13 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q2E069xj032266 for ; Wed, 14 Mar 2012 02:06:10 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Mar 2012 02:06:09 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.150]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.01.0355.003; Wed, 14 Mar 2012 01:06:08 +0100 From: To: , Thread-Topic: [paws] Time to present my ID in IETF Paris meeting Thread-Index: AQHNAXZBv5MHbxp/JUy4n8zz+YZtXw== Date: Wed, 14 Mar 2012 00:06:08 +0000 Message-ID: <21E7D9BD69CC7241AAE00F4EA183B7191066E24F@008-AM1MPN1-073.mgdnok.nokia.com> References: <470F27D1263A1B4EB73491ED995DE62516234020@szxeml504-mbs.china.huawei.com> <7BAC95F5A7E67643AAFB2C31BEE662D015E331D955@SC-VEXCH2.marvell.com> <470F27D1263A1B4EB73491ED995DE625162340C4@szxeml504-mbs.china.huawei.com> <7BAC95F5A7E67643AAFB2C31BEE662D015E331DAA3@SC-VEXCH2.marvell.com>, <1ECAFF543A2FED4EA2BEB6CACE08E47601E1F496@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601E1F496@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_21E7D9BD69CC7241AAE00F4EA183B7191066E24F008AM1MPN1073mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 14 Mar 2012 00:06:09.0587 (UTC) FILETIME=[426DC030:01CD0176] X-Nokia-AV: Clean Subject: Re: [paws] Time to present my ID in IETF Paris 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: Wed, 14 Mar 2012 00:06:20 -0000 --_000_21E7D9BD69CC7241AAE00F4EA183B7191066E24F008AM1MPN1073mg_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 PldoeSB3b3VsZCB0aGUgY2hhaXJzIG1lZGlhdGUgdGhpcyBkaXNjdXNzaW9uPw0KDQpJbiBvcmRl ciB0byBlbnN1cmUgd2UgYXJlIG5vdCB3YXN0aW5nIGJhbmR3aWR0aCBvbiB0b3BpY3MgdGhhdCBh cmUgY2xlYXJseSBvdXRzaWRlIHRoZSBXRyBzY29wZS4uLg0KQW5kIGl0IGlzIHlvdXIgcmVzcG9u c2liaWxpdHkgdG8gbW9kZXJhdGUgdG8gZW5zdXJlIHdlIGFyZSBtYWtpbmcgZm9yd2FyZCBwcm9n cmVzcy4uDQpBbmQgYmVjYXVzZSB5b3UgZ2V0IHRvIHdlYXIgdGhlIGJsdWUgZG90IDspDQoNClNl bnQgZnJvbSBteSBMdW1pYSA4MDANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpG cm9tOiBCYWprbyBHYWJvciAoTm9raWEtQ0lDL1NpbGljb25WYWxsZXkpDQpTZW50OiAzLzEzLzIw MTIgNjo0MyBQTQ0KVG86IHBhd3NAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcGF3c10gVGltZSB0 byBwcmVzZW50IG15IElEIGluIElFVEYgUGFyaXMgbWVldGluZw0KDQpXaHkgd291bGQgdGhlIGNo YWlycyBtZWRpYXRlIHRoaXMgZGlzY3Vzc2lvbj8gVGhlcmWhr3MgYW4gaW5kaXZpZHVhbCBzdWJt aXNzaW9uIGFuZCB0aGUgYXV0aG9yIGlzIHNlZWtpbmcgY29tbWVudHMgb24gdGhlIGxpc3QgYmVm b3JlIHRoZSBwcmVzZW50YXRpb24gaW4gdGhlIGYyZi4NClRoYXQgaXMgaG93IGlldGYgd29ya3Ms IHdlIG5lZWQgY29tbWVudHMgdG8gdGhlIGxpc3QgdG8gbWFrZSBwcm9ncmVzcyBvbmUgd2F5IG9y IHRoZSBvdGhlci4NCg0KDQotICAgICAgICAgIEdhYm9yDQoNCkZyb206IHBhd3MtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGV4dCBQ YXVsIExhbWJlcnQNClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDEzLCAyMDEyIDI6MzIgUE0NClRvOiBa aHVMZWk7IHBhd3NAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcGF3c10gVGltZSB0byBwcmVzZW50 IG15IElEIGluIElFVEYgUGFyaXMgbWVldGluZw0KDQpIaSBaaHUsDQoNCj4gSSBhbSBub3Qgc3Vy ZSB0aGF0IHlvdSB3b3VsZCBzdXBwb3J0IHRoaXMgaWRlYSwgYnV0IHRoZSB0ZXh0IGRlc2NyaWJp bmcgdGhpcyBjYW4gbWFrZSB0aGluZ3MgY2xlYXJlciB3aGVuIHRhbGtpbmcgYWJvdXQgdGhpcy4N Cg0KTm8gSSBkbyBub3Qgc3VwcG9ydCB0aGUgaWRlYSBvZiBhZGRpdGlvbmFsIGxheWVycyBvZiCh sGNvb3JkaW5hdGluZyBkYXRhYmFzZaGxLiAgRXNwZWNpYWxseSBmb3IgZGV0YWlsZWQgZGVzaWdu cyB1c2luZyBIVFRQUy4NCg0KPiBJIHdvdWxkIG5vdCBpbWFnZSBvbmUgZGF0YWJhc2Ugc2Vydmlu ZyBodWdlIG51bWJlciBvZiBNYXN0ZXIgZGV2aWNlcy4gRm9yIHNvbWUgcmVhc29ucywgcmVndWxh dG9yDQo+bWF5IGF1dGhvcml6ZSBicmFuY2hlcyB0byBhZG1pbmlzdHJhdGUgb3IgbWFpbnRhaW4g d2hpdGUgc3BhY2UgZGF0YSBiYXNlIHdoaWNoIGRvbWluYXRlcyBhIHBhcnRpY3VsYXIgcmVnaW9u Lg0KDQpPdXQtb2Ytc2NvcGUgYW5kIGNvbXBsZXRlbHkgdW5uZWNlc3NhcnkuICBXaGVuIHlvdSB1 c2UgU1NMIHRvIGFjY2VzcyBhIGJhbmsgYWNjb3VudCBkbyB5b3UgY2FyZSB0aGF0IHRoZXJlIG1h eSBiZSBtdWx0aXBsZSBzZXJ2ZXJzIHRoYXQgbG9vayBsaWtlIGEgc2luZ2xlIGVudGl0eSB0byB0 aGUgdXNlcj8gICBOZXcgbGF5ZXJzIG9mIGFic3RyYWN0aW9uIGFyZSBub3QgcmVxdWlyZWQgZm9y IHNjYWxhYmlsaXR5LiAgVGhlIHNhbWUgcHJvdG9jb2wgY2FuIGJlIHVzZWQgdG8gb25lIG9yIG11 bHRpcGxlIHNlcnZlcnMuICBZZXMsIHNvbWUgY29uc2lkZXJhdGlvbnMgbmVlZCB0byBiZSBkaXNj dXNzZWQgYWJvdXQgYXV0aGVudGljYXRpb24uICBObyBuZXcgZW50aXRpZXMsIGxheWVycywgYXJj aGl0ZWN0dXJhbCBibG9ja3MsIGNvbmNlcHRzLCBmcmFtZXdvcmtzIG9yIHByb3RvY29scyBhcmUg cmVxdWlyZWQgZm9yIKGwc2VydmluZyBhIGh1Z2UgbnVtYmVyIKGtIKGwLg0KDQpJIGFsc28gc2Vl IHRoYXQgd2Ugd2FzdGUgYSBsb3Qgb2Ygd29yZHMgb24gdGhlIGxpc3Qgb24gdGhpcyB0b3BpYyB0 aGF0IG1heSBiZSBvdXQgb2Ygc2NvcGUgKHVwIHRvIGNoYWlyIHRvIG1lZGlhdGUgoa0pLiAgVGhl IHB1cnBvc2Ugb2YgdGhlIHJlcXVpcmVtZW50cyBhbmQgdXNlIGNhc2UgcHJvY2VzcyBpcyB0byBj cmVhdGUgY29uc2Vuc3VzIGZyb20gdGhlIHRvcCBkb3duIHRvIGZhY2lsaXRhdGUgdGhlIGNyZWF0 aW9uICBvZiBhIHNwZWNpZmljYXRpb24gb2YgdGhlIGJlc3QgcG9zc2libGUgZG9jdW1lbnQgZnJv bSB0aGUgd29ya2luZyBncm91cC4gIFdlIHNob3VsZCBpZ25vcmUgYW55IGRpc2N1c3Npb25zIGFu ZCBjb250cmlidXRpb25zIG9uIG91dC1vZi1zY29wZSBjb250cmlidXRpb25zIGFuZCBmb2N1cyBv biB0aGUgY3VycmVudCBzY29wZSBhbmQgd29yayBpdGVtcy4NCg0KUGF1bA0KDQoNClBhdWwgQS4g TGFtYmVydCB8IE1hcnZlbGwgU2VtaWNvbmR1Y3RvciB8ICsxLTY1MC03ODctOTE0MQ0KDQpGcm9t OiBaaHVMZWkgW21haWx0bzpsZWkuemh1QGh1YXdlaS5jb21dPG1haWx0bzpbbWFpbHRvOmxlaS56 aHVAaHVhd2VpLmNvbV0+DQpTZW50OiBUdWVzZGF5LCBNYXJjaCAxMywgMjAxMiAxOjQ3IEFNDQpU bzogUGF1bCBMYW1iZXJ0OyBwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPg0KU3Vi amVjdDogUkU6IFRpbWUgdG8gcHJlc2VudCBteSBJRCBpbiBJRVRGIFBhcmlzIG1lZXRpbmcNCg0K SGkgUGF1bCwNCg0KRG8geW91IHByZWZlciB0byByZW1vdmUgdGhpcyBpbnRlcm1lZGlhcnkgZnVu Y3Rpb24/IFRoZSBpbnRlbnRpb24gb2YgdGhpcyBkcmFmdCBpcyBzdGlsbCB0byBwcm92aWRlIGEg cHJvcG9zYWwgb2YgZnJhbWV3b3JrIGFuZCBwcm90b2NvbCwgcHJvYmFibHkgaW5jbHVkaW5nIHdo b2xlIHBpY3R1cmUgd2l0aCBlc3NlbnRpYWwgZWxlbWVudHMsIGRpc2NvdmVyeSwgcXVlcnksIHVw ZGF0ZSBldGMuDQoNCkFzIHdoYXQgaXMgbWVudGlvbmVkIGluIGUtbWFpbCBsaXN0IGFuZCBsYXN0 IEYyRiBtZWV0aW5nLCBwb3NzaWJseSwgdGhlIFBBV1MgbWlnaHQgYmUgdmVyeSBleHRlbnNpYmxl IHNpbmNlIHRoZSBiYXNpYyBjb25jZXB0cywgc2NlbmFyaW9zIGFuZCByZXF1aXJlbWVudHMgYXJl IGVzdGFibGlzaGVkIHVwb24gdGhlIEZDQyBhbmQgb3RoZXIgcmVndWxhdG9yc6GvIHByb2Nlc3Mg b2Ygd2hpdGUgc3BhY2UuIFdlIHN0aWxsIGhhdmUgc29tZSBwb3RlbnRpYWwgbmVlZHMgZG9pbmcg ZnVydGhlciBhdCBmZWF0dXJlIGxldmVsIG9yIGV2ZW4gYXJjaGl0ZWN0dXJlIGxldmVsLiBBdCBs ZWFzdCwgdGhlIGRlc2lnbiBvZiB0aGlzIHByb3RvY29sIHNob3VsZCBtYWtlIHN1cmUgdGhpcyBu ZWVkLiBGcm9tIHRoaXMgcGVyc3BlY3RpdmUsIGF1dGhlbnRpY2F0aW9uIGFuZCBjb250ZW50IHBy b3RlY3Rpb24gbWlnaHQgYmUgY29uc2lkZXJlZCBmdXJ0aGVyLCBob3BlZnVsbHksIHdlIGFyZSBh YmxlIHRvIGRpc2N1c3Mgc2VjdXJpdHkgaW4gUGFyaXMuDQoNCldlIGFsc28gcmVhbGx5IG1ldCB2 YXJ5IHNpdHVhdGlvbnMgb2YgZGlmZmVyZW50IGFyZWFzIGFuZCByZWdpb25zIHdobyBkb21pbmF0 ZSBhIHF1aXRlIG51bWJlciBvZiBNYXN0ZXIgZGV2aWNlcy4gSSB3b3VsZCBub3QgaW1hZ2Ugb25l IGRhdGFiYXNlIHNlcnZpbmcgaHVnZSBudW1iZXIgb2YgTWFzdGVyIGRldmljZXMuIEZvciBzb21l IHJlYXNvbnMsIHJlZ3VsYXRvciBtYXkgYXV0aG9yaXplIGJyYW5jaGVzIHRvIGFkbWluaXN0cmF0 ZSBvciBtYWludGFpbiB3aGl0ZSBzcGFjZSBkYXRhIGJhc2Ugd2hpY2ggZG9taW5hdGVzIGEgcGFy dGljdWxhciByZWdpb24uIEkgZG8gbm90IHRoaW5rIHRoZSBtdWx0aXBsZSBkYXRhIGJhc2VzIG9y IGRpc3RyaWJ1dGVkIGRhdGEgbW9kZWwgZnJhbWV3b3JrIGFyZSBjb250cm92ZXJzaWFsIHRvIHVz LCBidXQgdGhlIGFkZGl0aW9uYWwgZnVuY3Rpb25zIG9mIHRoaXMgY29vcmRpbmF0aW5nIGRhdGEg YmFzZS4gVGhpcyBpbnRlcm1lZGlhdGUgbm9kZSB3aXRoIHdoaXRlIHNwYWNlIHNwZWN0cnVtIGRl Y2lzaW9uIG1ha2luZyBmdW5jdGlvbiBpcyB0aGUgaXNzdWUgb2YgZXh0ZW5zaWJpbGl0eSwgd2hp Y2ggY2FuIGJlIGhlbHBmdWwgd2hlbiBhZGRpbmcgc29tZSBmZWF0dXJlIHdoaWNoIGlzIG5vdCBk ZXNpcmVkIHRvIG1haW4gZGF0YSBiYXNlLiBEZWNpc2lvbiBtYWtpbmcgZnVuY3Rpb24gY291bGQg YmUgbm90IGEgZnVuY3Rpb25hbGl0eSBvZiBtYWluIGRhdGEgYmFzZSB3aGljaCBuZWVkcyB0byBi ZSB2ZXJ5IHN0YWJsZSBhbmQgc3RhdGljLiBJZiB3ZSByZWFsbHkgZXh0ZW50IGNvZXhpc3RlbmNl IG9yIGludGVyZmVyZW5jZSBhdm9pZGFuY2Ugcm9sZSB0byBQQVdTIHByb3RvY29sLCBpdCB3b3Vs ZCBiZSBlYXNpZXIgdG8gZXh0ZW50IGludGVybWVkaWFyeSBmdW5jdGlvbiB3aXRob3V0IGltcGFj dHMgb24gZnJhbWV3b3JrIG9mIFBBV1MsIGFuZCwgc3RydWN0dXJlIGFuZCBwcm90b2NvbCBvZiBQ QVdTLiBUaGlzIG5vZGUgaXMgYmVsaWV2ZWQgdG8gZXhpc3QgZm9yIHRoaXMgcHVycG9zZS4NCg0K SSBhbSBub3Qgc3VyZSB0aGF0IHlvdSB3b3VsZCBzdXBwb3J0IHRoaXMgaWRlYSwgYnV0IHRoZSB0 ZXh0IGRlc2NyaWJpbmcgdGhpcyBjYW4gbWFrZSB0aGluZ3MgY2xlYXJlciB3aGVuIHRhbGtpbmcg YWJvdXQgdGhpcy4NCg0KQmVzdCByZWdhcmRzLA0KWmh1IExlaQ0KDQoNCreivP7IyzogUGF1bCBM YW1iZXJ0IFttYWlsdG86cGF1bEBtYXJ2ZWxsLmNvbV08bWFpbHRvOlttYWlsdG86cGF1bEBtYXJ2 ZWxsLmNvbV0+DQq3osvNyrG85DogMjAxMsTqM9TCMTPI1SAxNToyOA0KytW8/sjLOiBaaHVMZWk7 IHBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+DQrW98ziOiBSRTogVGltZSB0byBw cmVzZW50IG15IElEIGluIElFVEYgUGFyaXMgbWVldGluZw0KDQoNCkRpZCBvdXIgY29uc2Vuc3Vz IHByb2Nlc3MgaW5jbHVkZSBhIGNvb3JkaW5hdGluZyBpbnRlcm1lZGlhcnkgZnVuY3Rpb24/DQoN CiAgIFRoZSBjb29yZGluYXRpbmcgZGF0YWJhc2UgY2FuIGdldCB3aGl0ZSBzcGFjZSBjaGFubmVs cyBmcm9tIGRhdGFiYXNlLA0KICAgcmVjZWl2ZSB0aGUgd2hpdGUgc3BhY2UgcXVlcnlpbmcgbWVz c2FnZSBmcm9tIG1hc3RlciBkZXZpY2UgYW5kDQogICBwcm92aWRlIHRoZSBhdmFpbGFibGUgd2hp dGUgc3BhY2UgY2hhbm5lbHMgZm9yIG1hc3RlciBkZXZpY2VzIHdpdGgNCiAgIHNvbWUgZGVncmVl IGRlY2lzaW9uIG1ha2luZyBwcm9jZXNzLiAgVGhlc2UgZGVjaXNpb24gbWFraW5nIHByb2Nlc3MN CiAgIG1pZ2h0IHByb3ZpZGUgZnVuY3Rpb25hbGl0eSBvZiB3aGl0ZSBzcGFjZSBhY2Nlc3MgcHJv dG9jb2wgcG93ZXIgdG8NCiAgIHJlc3BvbnNlIGF2YWlsYWJsZSBjaGFubmVscyBhY2NvcmRpbmcg dG8gcmVjZWl2ZWQgZGV2aWNlIHBhcmFtZXRlcnMNCiAgIChlLmcuIHBvd2VyLCBSRiBwYXJhbWV0 ZXIpLCBsb2NhdGlvbiBpbmZvcm1hdGlvbihlLmcuIGFsdGl0dWRlLA0KICAgcG9zaXRpb24gYW5k IGRpcmVjdGlvbiBvZiBhbnRlbm5hICkgYW5kIHNvbWUgcGFydGljdWxhciB3aGl0ZSBzcGFjZQ0K ICAgc3BlY3RydW0gZGVjaXNpb24gbWFraW5nIHBvbGljaWVzLg0KDQpEb26hr3Qgc2VlIHRoYXQg dGhpcyBpcyBpbiBzY29wZS4gU2VlbXMgaW5hcHByb3ByaWF0ZSB0byBjcmVhdGUgY29tcGxldGUg SURzIHdpdGggZmVhdHVyZXMgdGhhdCBhcmUgb3V0LW9mLXNjb3BlLg0KDQpQYXVsDQoNCg0KRnJv bTogcGF3cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmc+IFtt YWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnXTxtYWlsdG86W21haWx0bzpwYXdzLWJvdW5jZXNA aWV0Zi5vcmddPiBPbiBCZWhhbGYgT2YgWmh1TGVpDQpTZW50OiBUdWVzZGF5LCBNYXJjaCAxMywg MjAxMiAxMjowMiBBTQ0KVG86IHBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+DQpT dWJqZWN0OiBbcGF3c10gVGltZSB0byBwcmVzZW50IG15IElEIGluIElFVEYgUGFyaXMgbWVldGlu Zw0KDQpIaSBGb2xrcyBhbmQgY2hhaXJzLA0KDQpBcyB3aGF0IHlvdSBtaWdodCBub3RpY2UsIEkg dXBsb2FkZWQgYSBJRCBvbiBQQVdTIGZyYW1ld29yayBhbmQgcHJvdG9jb2wgd2hpY2ggaXMgdG8g ZnVsZmlsbCBQQVdTIHJlcXVpcmVtZW50cyBhbmQgcmVndWxhdG9yc6GvIHJlcXVpcmVtZW50cywg obB3d3cuaWV0Zi5vcmcvaWQvZHJhZnQtbGVpLXBhd3MtZnJhbWV3b3JrLWRhdGFtb2RlbC0wMC50 eHQ8aHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1sZWktcGF3cy1mcmFtZXdvcmstZGF0YW1v ZGVsLTAwLnR4dD6hsS4gIEkgd291bGQgdmVyeSBsaWtlIHRvIHJlcXVlc3QgMjUgbWludXRlcyBw cmVzZW50aW5nIGFuZCBkaXNjdXNzaW5nIGl0IGR1cmluZyBJRVRGIFBhcmlzIG1lZXRpbmcuDQoN CkJlc3QgcmVnYXJkcywNClpodSBMZWkNCg== --_000_21E7D9BD69CC7241AAE00F4EA183B7191066E24F008AM1MPN1073mg_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
>Why would= the chairs mediate this discussion?

In order to ensure we are not wasting bandwidth on topics that are clearly = outside the WG scope...
And it is your responsibility to moderate to ensure we are making forward p= rogress..
And because you get to wear the blue dot ;)

Sent from my Lumia 800
From: Bajko = Gabor (Nokia-CIC/SiliconValley)
Sent: 3/13/2= 012 6:43 PM
To: paws@i= etf.org
Subject: Re: [p= aws] Time to present my ID in IETF Paris meeting

Why = would the chairs mediate this discussion? There=A1=AFs an individual submis= sion and the author is seeking comments on the list before the presentation= in the f2f.

That= is how ietf works, we need comments to the list to make progress one way o= r the other.

&nbs= p;

-       &nb= sp;  Gabor<= /span>

&nbs= p;

From: paws-bounces@ietf.org [mailto:paws-bounc= es@ietf.org] On Behalf Of ext Paul Lambert
Sent: Tuesday, March 13, 2012 2:32 PM
To: ZhuLei; paws@ietf.org
Subject: Re: [paws] Time to present my ID in IETF Paris meeting

 

Hi Z= hu,

&nbs= p;

> I am not sure that you would support this idea, but the text describing= this can make things clearer when talking about this.

 

No I do not support the idea of additional layers of =A1= =B0coordinating database=A1=B1.  Especially for detailed designs using= HTTPS.

 

> I would not image one database serving huge number = of Master devices. For some reasons, regulator

>may authorize branches to administrate or maintain w= hite space data base which dominates a particular region.

 

Out-of-scope and completely unnecessary.  When you = use SSL to access a bank account do you care that there may be multiple ser= vers that look like a single entity to the user?   New layers of abstraction are not required for scalability.  The same= protocol can be used to one or multiple servers.  Yes, some considera= tions need to be discussed about authentication.  No new entities, lay= ers, architectural blocks, concepts, frameworks or protocols are required for =A1=B0serving a huge number =A1=AD =A1=B0.

 

I also see that we waste a lot of words on the list on t= his topic that may be out of scope (up to chair to mediate =A1=AD).  T= he purpose of the requirements and use case process is to create consensus from the top down to facilitate the creation  = of a specification of the best possible document from the working group.&nb= sp; We should ignore any discussions and contributions on out-of-scope cont= ributions and focus on the current scope and work items.

 

Paul

&nbs= p;

 

Paul A. Lambert | Marvell Semiconducto= r | +1-650-787-9141

&nbs= p;

From: ZhuLei [mailto:lei.zhu@huawei.com]<= /a>
Sent: Tuesday, March 13, 2012 1:47 AM
To: Paul Lambert; paws@ietf.org=
Subject: RE: Time to present my ID in IETF Paris meeting

 

Hi Paul,

 

Do you prefer to remov= e this intermediary function? The intention of this draft is still to provi= de a proposal of framework and protocol, probably including whole picture w= ith essential elements, discovery, query, update etc.

 

As what is mentioned i= n e-mail list and last F2F meeting, possibly, the PAWS might be very extens= ible since the basic concepts, scenarios and requirements are established u= pon the FCC and other regulators=A1=AF process of white space. We still have some potential needs doing further at featur= e level or even architecture level. At least, the design of this protocol s= hould make sure this need. From this perspective, authentication and conten= t protection might be considered further, hopefully, we are able to discuss security in Paris.

 

We also really met vary situations of different areas an= d regions who dominate a quite number of Master devices. I would not image = one database serving huge number of Master devices. For some reasons, regulator may authorize branches to administrat= e or maintain white space data base which dominates a particular region. I = do not think the multiple data bases or distributed data model framework ar= e controversial to us, but the additional functions of this coordinating data base. This intermediate node with whit= e space spectrum decision making function is the issue of extensibility, wh= ich can be helpful when adding some feature which is not desired to main da= ta base. Decision making function could be not a functionality of main data base which needs to be very stab= le and static. If we really extent coexistence or interference avoidance ro= le to PAWS protocol, it would be easier to extent intermediary function wit= hout impacts on framework of PAWS, and, structure and protocol of PAWS. This node is believed to exist for th= is purpose.

 

I am not sure that you would support this idea, but the = text describing this can make things clearer when talking about this.

 

Best regards,

Zhu Lei

 

 

=B7=A2=BC=FE=C8= =CB: Paul Lambert [mailto:paul@mar= vell.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C213=C8=D5 15:28
=CA=D5=BC=FE=C8=CB: ZhuLei; paws@ietf.org
=D6=F7=CC=E2: RE: Time to present my ID = in IETF Paris meeting

 

&nbs= p;

Did = our consensus process include a coordinating intermediary function?<= /p>

 

   The= coordinating database can get white space channels from database,

   rec= eive the white space querying message from master device and

   pro= vide the available white space channels for master devices with

   som= e degree decision making process.  These decision making process

   mig= ht provide functionality of white space access protocol power to

   res= ponse available channels according to received device parameters

   (e.= g. power, RF parameter), location information(e.g. altitude,

   pos= ition and direction of antenna ) and some particular white space

   spe= ctrum decision making policies.

&nbs= p;

Don= =A1=AFt see that this is in scope. Seems inappropriate to create complete I= Ds with features that are out-of-scope.

&nbs= p;

Paul=

&nbs= p;

&nbs= p;

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ZhuLei
Sent: Tuesday, March 13, 2012 12:02 AM
To: paws@ietf.org
Subject: [paws] Time to present my ID in IETF Paris meeting

 

Hi Folks and chairs,

 

As what you might notice, I uploaded a ID on PAWS fr= amework and protocol which is to fulfill PAWS requirements and regulators= =A1=AF requirements, =A1=B0www.ietf.org/id/draft-lei-paws-framework-datam= odel-00.txt=A1=B1.  I would very like to request 25 minutes presenting and discussing it= during IETF Paris meeting.

 

Best regards,

Zhu Lei

--_000_21E7D9BD69CC7241AAE00F4EA183B7191066E24F008AM1MPN1073mg_-- From JuanCarlos.Zuniga@InterDigital.com Tue Mar 13 18:42:35 2012 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 9F4E221F8569 for ; Tue, 13 Mar 2012 18:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.524 X-Spam-Level: X-Spam-Status: No, score=-0.524 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNpAOI3mUy2p for ; Tue, 13 Mar 2012 18:42:34 -0700 (PDT) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id D0A1221F8568 for ; Tue, 13 Mar 2012 18:42:33 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Mar 2012 21:42:33 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD0183.B97FA19E" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 13 Mar 2012 21:42:31 -0400 Message-ID: In-Reply-To: <21E7D9BD69CC7241AAE00F4EA183B7191066E24F@008-AM1MPN1-073.mgdnok.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [paws] Time to present my ID in IETF Paris meeting Thread-Index: AQHNAXZBv5MHbxp/JUy4n8zz+YZtX5Zo/brw References: <470F27D1263A1B4EB73491ED995DE62516234020@szxeml504-mbs.china.huawei.com><7BAC95F5A7E67643AAFB2C31BEE662D015E331D955@SC-VEXCH2.marvell.com><470F27D1263A1B4EB73491ED995DE625162340C4@szxeml504-mbs.china.huawei.com><7BAC95F5A7E67643AAFB2C31BEE662D015E331DAA3@SC-VEXCH2.marvell.com>, <1ECAFF543A2FED4EA2BEB6CACE08E47601E1F496@008-AM1MPN1-006.mgdnok.nokia.com> <21E7D9BD69CC7241AAE00F4EA183B7191066E24F@008-AM1MPN1-073.mgdnok.nokia.com> From: "Zuniga, Juan Carlos" To: X-OriginalArrivalTime: 14 Mar 2012 01:42:33.0056 (UTC) FILETIME=[B9A51600:01CD0183] Subject: Re: [paws] Time to present my ID in IETF Paris 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: Wed, 14 Mar 2012 01:42:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD0183.B97FA19E Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Unfortunately we don=A1=AFt have a reference architecture to work upon, = so people will make the proposals and comments based on what they = understand. =20 We have agreed before to limit the terminology to =A1=B0WSD <-> = WSDB=A1=B1 to keep it simple. =20 We know that WSD will be a device and WSDB a server-based service = provided by a WS Service Provider (most likely not the Regulator). =20 This is a proposal defining a protocol between WSD and WSDB, so I = believe it is in scope. Perhaps if we wanted to provide constructive = feedback to the authors we could suggest revising the terminology of = their draft. =20 Jc =20 From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of = Basavaraj.Patil@nokia.com Sent: Tuesday, March 13, 2012 2:06 PM To: Gabor.Bajko@nokia.com; paws@ietf.org Subject: Re: [paws] Time to present my ID in IETF Paris meeting =20 >Why would the chairs mediate this discussion? In order to ensure we are not wasting bandwidth on topics that are = clearly outside the WG scope... And it is your responsibility to moderate to ensure we are making = forward progress.. And because you get to wear the blue dot ;) Sent from my Lumia 800 ________________________________ From: Bajko Gabor (Nokia-CIC/SiliconValley) Sent: 3/13/2012 6:43 PM To: paws@ietf.org Subject: Re: [paws] Time to present my ID in IETF Paris meeting Why would the chairs mediate this discussion? There=A1=AFs an individual = submission and the author is seeking comments on the list before the = presentation in the f2f. That is how ietf works, we need comments to the list to make progress = one way or the other. =20 - Gabor =20 From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of = ext Paul Lambert Sent: Tuesday, March 13, 2012 2:32 PM To: ZhuLei; paws@ietf.org Subject: Re: [paws] Time to present my ID in IETF Paris meeting =20 Hi Zhu, =20 > I am not sure that you would support this idea, but the text = describing this can make things clearer when talking about this. =20 No I do not support the idea of additional layers of =A1=B0coordinating = database=A1=B1. Especially for detailed designs using HTTPS. =20 > I would not image one database serving huge number of Master devices. = For some reasons, regulator=20 >may authorize branches to administrate or maintain white space data = base which dominates a particular region. =20 Out-of-scope and completely unnecessary. When you use SSL to access a = bank account do you care that there may be multiple servers that look = like a single entity to the user? New layers of abstraction are not = required for scalability. The same protocol can be used to one or = multiple servers. Yes, some considerations need to be discussed about = authentication. No new entities, layers, architectural blocks, = concepts, frameworks or protocols are required for =A1=B0serving a huge = number =A1=AD =A1=B0. =20 I also see that we waste a lot of words on the list on this topic that = may be out of scope (up to chair to mediate =A1=AD). The purpose of the = requirements and use case process is to create consensus from the top = down to facilitate the creation of a specification of the best possible = document from the working group. We should ignore any discussions and = contributions on out-of-scope contributions and focus on the current = scope and work items. =20 Paul =20 =20 Paul A. Lambert | Marvell Semiconductor | +1-650-787-9141 =20 From: ZhuLei [mailto:lei.zhu@huawei.com]=20 Sent: Tuesday, March 13, 2012 1:47 AM To: Paul Lambert; paws@ietf.org Subject: RE: Time to present my ID in IETF Paris meeting =20 Hi Paul, =20 Do you prefer to remove this intermediary function? The intention of = this draft is still to provide a proposal of framework and protocol, = probably including whole picture with essential elements, discovery, = query, update etc. =20 As what is mentioned in e-mail list and last F2F meeting, possibly, the = PAWS might be very extensible since the basic concepts, scenarios and = requirements are established upon the FCC and other regulators=A1=AF = process of white space. We still have some potential needs doing further = at feature level or even architecture level. At least, the design of = this protocol should make sure this need. From this perspective, = authentication and content protection might be considered further, = hopefully, we are able to discuss security in Paris. =20 We also really met vary situations of different areas and regions who = dominate a quite number of Master devices. I would not image one = database serving huge number of Master devices. For some reasons, = regulator may authorize branches to administrate or maintain white space = data base which dominates a particular region. I do not think the = multiple data bases or distributed data model framework are = controversial to us, but the additional functions of this coordinating = data base. This intermediate node with white space spectrum decision = making function is the issue of extensibility, which can be helpful when = adding some feature which is not desired to main data base. Decision = making function could be not a functionality of main data base which = needs to be very stable and static. If we really extent coexistence or = interference avoidance role to PAWS protocol, it would be easier to = extent intermediary function without impacts on framework of PAWS, and, = structure and protocol of PAWS. This node is believed to exist for this = purpose. =20 I am not sure that you would support this idea, but the text describing = this can make things clearer when talking about this. =20 Best regards, Zhu Lei =20 =20 =B7=A2=BC=FE=C8=CB: Paul Lambert [mailto:paul@marvell.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C213=C8=D5 15:28 =CA=D5=BC=FE=C8=CB: ZhuLei; paws@ietf.org =D6=F7=CC=E2: RE: Time to present my ID in IETF Paris meeting =20 =20 Did our consensus process include a coordinating intermediary function? =20 The coordinating database can get white space channels from database, receive the white space querying message from master device and provide the available white space channels for master devices with some degree decision making process. These decision making process=20 might provide functionality of white space access protocol power to response available channels according to received device parameters (e.g. power, RF parameter), location information(e.g. altitude, position and direction of antenna ) and some particular white space spectrum decision making policies. =20 Don=A1=AFt see that this is in scope. Seems inappropriate to create = complete IDs with features that are out-of-scope. =20 Paul=20 =20 =20 From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of = ZhuLei Sent: Tuesday, March 13, 2012 12:02 AM To: paws@ietf.org Subject: [paws] Time to present my ID in IETF Paris meeting =20 Hi Folks and chairs, =20 As what you might notice, I uploaded a ID on PAWS framework and protocol = which is to fulfill PAWS requirements and regulators=A1=AF requirements, = =A1=B0www.ietf.org/id/draft-lei-paws-framework-datamodel-00.txt=A1=B1. = I would very like to request 25 minutes presenting and discussing it = during IETF Paris meeting.=20 =20 Best regards, Zhu Lei ------_=_NextPart_001_01CD0183.B97FA19E Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Unfortunately we don=A1=AFt = have a reference architecture to work upon, so people will make the = proposals and comments based on what they = understand.

 

We have = agreed before to limit the terminology to =A1=B0WSD <-> WSDB=A1=B1 = to keep it simple.

 

We know = that WSD will be a device and WSDB a server-based service provided by a = WS Service Provider (most likely not the = Regulator).

 

This is = a proposal defining a protocol between WSD and WSDB, so I believe it is = in scope. Perhaps if we wanted to provide constructive feedback to the = authors we could suggest revising the terminology of their = draft.

 

Jc

 

From:= = paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of = Basavaraj.Patil@nokia.com
Sent: Tuesday, March 13, 2012 = 2:06 PM
To: Gabor.Bajko@nokia.com; = paws@ietf.org
Subject: Re: [paws] Time to present my ID in = IETF Paris meeting

 

>Why would the chairs mediate this = discussion?

In order to ensure we are not wasting bandwidth on = topics that are clearly outside the WG scope...
And it is your = responsibility to moderate to ensure we are making forward = progress..
And because you get to wear the blue dot ;)

Sent = from my Lumia 800

From: = Bajko Gabor = (Nokia-CIC/SiliconValley)
Sent: = 3/13/2012 = 6:43 PM
To: = paws@ietf.or= g
Subject: = Re: [paws] = Time to present my ID in IETF Paris meeting

Why would the chairs mediate = this discussion? There=A1=AFs an individual submission and the author is = seeking comments on the list before the presentation in the = f2f.

That is how ietf works, we need = comments to the list to make progress one way or the = other.

 

-       &= nbsp;  Gabor

 

From:= = paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of = ext Paul Lambert
Sent: Tuesday, March 13, 2012 2:32 = PM
To: ZhuLei; paws@ietf.org
Subject: Re: [paws] = Time to present my ID in IETF Paris = meeting

 

Hi = Zhu,

 

> I am not sure that you would support this idea, = but the text describing this can make things clearer when talking about = this.

 

No = I do not support the idea of additional layers of =A1=B0coordinating = database=A1=B1.  Especially for detailed designs using = HTTPS.

 

> I would not image one database serving huge = number of Master devices. For some reasons, regulator =

>may = authorize branches to administrate or maintain white space data base = which dominates a particular region.

 

Out-of-scope and completely unnecessary.  = When you use SSL to access a bank account do you care that there may be = multiple servers that look like a single entity to the user?   = New layers of abstraction are not required for scalability.  The = same protocol can be used to one or multiple servers.  Yes, some = considerations need to be discussed about authentication.  No new = entities, layers, architectural blocks, concepts, frameworks or = protocols are required for =A1=B0serving a huge number =A1=AD = =A1=B0.

 

I = also see that we waste a lot of words on the list on this topic that may = be out of scope (up to chair to mediate =A1=AD).  The purpose of = the requirements and use case process is to create consensus from the = top down to facilitate the creation  of a specification of the best = possible document from the working group.  We should ignore any = discussions and contributions on out-of-scope contributions and focus on = the current scope and work items.

 

Paul

 

 

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

 

From:= = ZhuLei [mailto:lei.zhu@huawei.com]
Sent: Tuesday, March 13, 2012 1:47 AM
To: Paul = Lambert; paws@ietf.org
Subject: RE: = Time to present my ID in IETF Paris = meeting

 

Hi = Paul,

 

Do you prefer to remove = this intermediary function? The intention of this draft is still to = provide a proposal of framework and protocol, probably including whole = picture with essential elements, discovery, query, update = etc.

 

As what is mentioned in = e-mail list and last F2F meeting, possibly, the PAWS might be very = extensible since the basic concepts, scenarios and requirements are = established upon the FCC and other regulators=A1=AF process of white = space. We still have some potential needs doing further at feature level = or even architecture level. At least, the design of this protocol should = make sure this need. From this perspective, authentication and content = protection might be considered further, hopefully, we are able to = discuss security in Paris.

 

We = also really met vary situations of different areas and regions who = dominate a quite number of Master devices. I would not image one = database serving huge number of Master devices. For some reasons, = regulator may authorize branches to administrate or maintain white space = data base which dominates a particular region. I do not think the = multiple data bases or distributed data model framework are = controversial to us, but the additional functions of this coordinating = data base. This intermediate node with white space spectrum decision = making function is the issue of extensibility, which can be helpful when = adding some feature which is not desired to main data base. Decision = making function could be not a functionality of main data base which = needs to be very stable and static. If we really extent coexistence or = interference avoidance role to PAWS protocol, it would be easier to = extent intermediary function without impacts on framework of PAWS, and, = structure and protocol of PAWS. This node is believed to exist for this = purpose.

 

I = am not sure that you would support this idea, but the text describing = this can make things clearer when talking about = this.

 

Best regards,

Zhu Lei

 

 

=B7=A2=BC=FE=C8=CB= : Paul Lambert = [mailto:paul@marvell.com] =
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C213=C8=D5 15:28
=CA=D5=BC=FE=C8=CB: ZhuLei; paws@ietf.org
=D6=F7=CC=E2: RE: Time to present my ID in IETF = Paris meeting

 

 

Did our = consensus process include a coordinating intermediary = function?

 

   The = coordinating database can get white space channels from = database,

   = receive the white space querying message from master device = and

   = provide the available white space channels for master devices = with

   some = degree decision making process.  These decision making process

   might = provide functionality of white space access protocol power = to

   = response available channels according to received device = parameters

   (e.g. = power, RF parameter), location information(e.g. = altitude,

   = position and direction of antenna ) and some particular white = space

   = spectrum decision making policies.

 

Don=A1=AFt see that this is in = scope. Seems inappropriate to create complete IDs with features that are = out-of-scope.

 

Paul =

 

 

From:= = paws-bounces@ietf.org [mailto:paws-bounces@ietf.= org] On Behalf Of ZhuLei
Sent: Tuesday, March 13, = 2012 12:02 AM
To: paws@ietf.org
Subject: = [paws] Time to present my ID in IETF Paris = meeting

 

Hi Folks and chairs,

 

As what you = might notice, I uploaded a ID on PAWS framework and protocol which is to = fulfill PAWS requirements and regulators=A1=AF requirements, =A1=B0www.ietf.org/id/draft-lei-paws-framework-datamodel-00.txt=A1=B1. =  I would very like to request 25 minutes presenting and discussing = it during IETF Paris meeting.

 

Best = regards,

Zhu = Lei

------_=_NextPart_001_01CD0183.B97FA19E-- From paul@marvell.com Tue Mar 13 19:24:18 2012 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 D3FF921E803A for ; Tue, 13 Mar 2012 19:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.085 X-Spam-Level: X-Spam-Status: No, score=-4.085 tagged_above=-999 required=5 tests=[AWL=-1.690, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TReAxeztB9sW for ; Tue, 13 Mar 2012 19:24:17 -0700 (PDT) Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with ESMTP id D07FB21E800F for ; Tue, 13 Mar 2012 19:24:16 -0700 (PDT) Received: from sc-owa02.marvell.com ([65.219.4.130]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKT2ABT3L8qZgJhOHo+UJLHGybmoVJcv0X@postini.com; Tue, 13 Mar 2012 19: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, 13 Mar 2012 19:20:07 -0700 From: Paul Lambert To: "Zuniga, Juan Carlos" , "paws@ietf.org" Date: Tue, 13 Mar 2012 19:20:10 -0700 Thread-Topic: [paws] Time to present my ID in IETF Paris meeting Thread-Index: AQHNAXZBv5MHbxp/JUy4n8zz+YZtX5Zo/brwgAAPzzA= Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D015E331DB50@SC-VEXCH2.marvell.com> References: <470F27D1263A1B4EB73491ED995DE62516234020@szxeml504-mbs.china.huawei.com><7BAC95F5A7E67643AAFB2C31BEE662D015E331D955@SC-VEXCH2.marvell.com><470F27D1263A1B4EB73491ED995DE625162340C4@szxeml504-mbs.china.huawei.com><7BAC95F5A7E67643AAFB2C31BEE662D015E331DAA3@SC-VEXCH2.marvell.com>, <1ECAFF543A2FED4EA2BEB6CACE08E47601E1F496@008-AM1MPN1-006.mgdnok.nokia.com> <21E7D9BD69CC7241AAE00F4EA183B7191066E24F@008-AM1MPN1-073.mgdnok.nokia.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: multipart/alternative; boundary="_000_7BAC95F5A7E67643AAFB2C31BEE662D015E331DB50SCVEXCH2marve_" MIME-Version: 1.0 Subject: Re: [paws] Time to present my ID in IETF Paris 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: Wed, 14 Mar 2012 02:24:18 -0000 --_000_7BAC95F5A7E67643AAFB2C31BEE662D015E331DB50SCVEXCH2marve_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQo+VGhpcyBpcyBhIHByb3Bvc2FsIGRlZmluaW5nIGEgcHJvdG9jb2wgYmV0d2VlbiBXU0QgYW5k IFdTREIsIHNvIEkgYmVsaWV2ZQ0KPml0IGlzIGluIHNjb3BlLiBQZXJoYXBzIGlmIHdlIHdhbnRl ZCB0byBwcm92aWRlIGNvbnN0cnVjdGl2ZSBmZWVkYmFjayB0byB0aGUNCj5hdXRob3JzIHdlIGNv dWxkIHN1Z2dlc3QgcmV2aXNpbmcgdGhlIHRlcm1pbm9sb2d5IG9mIHRoZWlyIGRyYWZ0Lg0KDQpU aGUgobBjb29yZGluYXRpbmcgZGF0YWJhc2WhsSBpcyBuZWl0aGVyIGEgV1NEIG9yIGEgV1NEQi4g IFRoZSBjb25zdHJ1Y3RpdmUgY3JpdGljaXNtIGlzIHRoYXQgdGhpcyBjb25jZXB0IGlzOiBvdXQt b2Ytc2NvcGUgKElNTyksIHVubmVjZXNzYXJ5IGFuZCBzaG91bGQgYmUgZnVsbHkgcmVtb3ZlZCBm cm9tIHRoZSBkcmFmdCBhbmQgZnVydGhlciBkaXNjdXNzaW9ucyBvbiB0aGlzIGxpc3QuDQoNClBh dWwNCg0KDQpQYXVsIEEuIExhbWJlcnQgfCBNYXJ2ZWxsIFNlbWljb25kdWN0b3IgfCArMS02NTAt Nzg3LTkxNDENCg0KRnJvbTogcGF3cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cGF3cy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWnVuaWdhLCBKdWFuIENhcmxvcw0KU2VudDogVHVl c2RheSwgTWFyY2ggMTMsIDIwMTIgNjo0MyBQTQ0KVG86IHBhd3NAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbcGF3c10gVGltZSB0byBwcmVzZW50IG15IElEIGluIElFVEYgUGFyaXMgbWVldGluZw0K DQpVbmZvcnR1bmF0ZWx5IHdlIGRvbqGvdCBoYXZlIGEgcmVmZXJlbmNlIGFyY2hpdGVjdHVyZSB0 byB3b3JrIHVwb24sIHNvIHBlb3BsZSB3aWxsIG1ha2UgdGhlIHByb3Bvc2FscyBhbmQgY29tbWVu dHMgYmFzZWQgb24gd2hhdCB0aGV5IHVuZGVyc3RhbmQuDQoNCldlIGhhdmUgYWdyZWVkIGJlZm9y ZSB0byBsaW1pdCB0aGUgdGVybWlub2xvZ3kgdG8gobBXU0QgPC0+IFdTREKhsSB0byBrZWVwIGl0 IHNpbXBsZS4NCg0KV2Uga25vdyB0aGF0IFdTRCB3aWxsIGJlIGEgZGV2aWNlIGFuZCBXU0RCIGEg c2VydmVyLWJhc2VkIHNlcnZpY2UgcHJvdmlkZWQgYnkgYSBXUyBTZXJ2aWNlIFByb3ZpZGVyICht b3N0IGxpa2VseSBub3QgdGhlIFJlZ3VsYXRvcikuDQoNClRoaXMgaXMgYSBwcm9wb3NhbCBkZWZp bmluZyBhIHByb3RvY29sIGJldHdlZW4gV1NEIGFuZCBXU0RCLCBzbyBJIGJlbGlldmUgaXQgaXMg aW4gc2NvcGUuIFBlcmhhcHMgaWYgd2Ugd2FudGVkIHRvIHByb3ZpZGUgY29uc3RydWN0aXZlIGZl ZWRiYWNrIHRvIHRoZSBhdXRob3JzIHdlIGNvdWxkIHN1Z2dlc3QgcmV2aXNpbmcgdGhlIHRlcm1p bm9sb2d5IG9mIHRoZWlyIGRyYWZ0Lg0KDQpKYw0KDQpGcm9tOiBwYXdzLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCYXNhdmFyYWou UGF0aWxAbm9raWEuY29tDQpTZW50OiBUdWVzZGF5LCBNYXJjaCAxMywgMjAxMiAyOjA2IFBNDQpU bzogR2Fib3IuQmFqa29Abm9raWEuY29tOyBwYXdzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Bh d3NdIFRpbWUgdG8gcHJlc2VudCBteSBJRCBpbiBJRVRGIFBhcmlzIG1lZXRpbmcNCg0KPldoeSB3 b3VsZCB0aGUgY2hhaXJzIG1lZGlhdGUgdGhpcyBkaXNjdXNzaW9uPw0KDQpJbiBvcmRlciB0byBl bnN1cmUgd2UgYXJlIG5vdCB3YXN0aW5nIGJhbmR3aWR0aCBvbiB0b3BpY3MgdGhhdCBhcmUgY2xl YXJseSBvdXRzaWRlIHRoZSBXRyBzY29wZS4uLg0KQW5kIGl0IGlzIHlvdXIgcmVzcG9uc2liaWxp dHkgdG8gbW9kZXJhdGUgdG8gZW5zdXJlIHdlIGFyZSBtYWtpbmcgZm9yd2FyZCBwcm9ncmVzcy4u DQpBbmQgYmVjYXVzZSB5b3UgZ2V0IHRvIHdlYXIgdGhlIGJsdWUgZG90IDspDQoNClNlbnQgZnJv bSBteSBMdW1pYSA4MDANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBC YWprbyBHYWJvciAoTm9raWEtQ0lDL1NpbGljb25WYWxsZXkpDQpTZW50OiAzLzEzLzIwMTIgNjo0 MyBQTQ0KVG86IHBhd3NAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcGF3c10gVGltZSB0byBwcmVz ZW50IG15IElEIGluIElFVEYgUGFyaXMgbWVldGluZw0KV2h5IHdvdWxkIHRoZSBjaGFpcnMgbWVk aWF0ZSB0aGlzIGRpc2N1c3Npb24/IFRoZXJloa9zIGFuIGluZGl2aWR1YWwgc3VibWlzc2lvbiBh bmQgdGhlIGF1dGhvciBpcyBzZWVraW5nIGNvbW1lbnRzIG9uIHRoZSBsaXN0IGJlZm9yZSB0aGUg cHJlc2VudGF0aW9uIGluIHRoZSBmMmYuDQpUaGF0IGlzIGhvdyBpZXRmIHdvcmtzLCB3ZSBuZWVk IGNvbW1lbnRzIHRvIHRoZSBsaXN0IHRvIG1ha2UgcHJvZ3Jlc3Mgb25lIHdheSBvciB0aGUgb3Ro ZXIuDQoNCg0KLSAgICAgICAgICBHYWJvcg0KDQpGcm9tOiBwYXdzLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgUGF1bCBMYW1i ZXJ0DQpTZW50OiBUdWVzZGF5LCBNYXJjaCAxMywgMjAxMiAyOjMyIFBNDQpUbzogWmh1TGVpOyBw YXdzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Bhd3NdIFRpbWUgdG8gcHJlc2VudCBteSBJRCBp biBJRVRGIFBhcmlzIG1lZXRpbmcNCg0KSGkgWmh1LA0KDQo+IEkgYW0gbm90IHN1cmUgdGhhdCB5 b3Ugd291bGQgc3VwcG9ydCB0aGlzIGlkZWEsIGJ1dCB0aGUgdGV4dCBkZXNjcmliaW5nIHRoaXMg Y2FuIG1ha2UgdGhpbmdzIGNsZWFyZXIgd2hlbiB0YWxraW5nIGFib3V0IHRoaXMuDQoNCk5vIEkg ZG8gbm90IHN1cHBvcnQgdGhlIGlkZWEgb2YgYWRkaXRpb25hbCBsYXllcnMgb2YgobBjb29yZGlu YXRpbmcgZGF0YWJhc2WhsS4gIEVzcGVjaWFsbHkgZm9yIGRldGFpbGVkIGRlc2lnbnMgdXNpbmcg SFRUUFMuDQoNCj4gSSB3b3VsZCBub3QgaW1hZ2Ugb25lIGRhdGFiYXNlIHNlcnZpbmcgaHVnZSBu dW1iZXIgb2YgTWFzdGVyIGRldmljZXMuIEZvciBzb21lIHJlYXNvbnMsIHJlZ3VsYXRvcg0KPm1h eSBhdXRob3JpemUgYnJhbmNoZXMgdG8gYWRtaW5pc3RyYXRlIG9yIG1haW50YWluIHdoaXRlIHNw YWNlIGRhdGEgYmFzZSB3aGljaCBkb21pbmF0ZXMgYSBwYXJ0aWN1bGFyIHJlZ2lvbi4NCg0KT3V0 LW9mLXNjb3BlIGFuZCBjb21wbGV0ZWx5IHVubmVjZXNzYXJ5LiAgV2hlbiB5b3UgdXNlIFNTTCB0 byBhY2Nlc3MgYSBiYW5rIGFjY291bnQgZG8geW91IGNhcmUgdGhhdCB0aGVyZSBtYXkgYmUgbXVs dGlwbGUgc2VydmVycyB0aGF0IGxvb2sgbGlrZSBhIHNpbmdsZSBlbnRpdHkgdG8gdGhlIHVzZXI/ ICAgTmV3IGxheWVycyBvZiBhYnN0cmFjdGlvbiBhcmUgbm90IHJlcXVpcmVkIGZvciBzY2FsYWJp bGl0eS4gIFRoZSBzYW1lIHByb3RvY29sIGNhbiBiZSB1c2VkIHRvIG9uZSBvciBtdWx0aXBsZSBz ZXJ2ZXJzLiAgWWVzLCBzb21lIGNvbnNpZGVyYXRpb25zIG5lZWQgdG8gYmUgZGlzY3Vzc2VkIGFi b3V0IGF1dGhlbnRpY2F0aW9uLiAgTm8gbmV3IGVudGl0aWVzLCBsYXllcnMsIGFyY2hpdGVjdHVy YWwgYmxvY2tzLCBjb25jZXB0cywgZnJhbWV3b3JrcyBvciBwcm90b2NvbHMgYXJlIHJlcXVpcmVk IGZvciChsHNlcnZpbmcgYSBodWdlIG51bWJlciChrSChsC4NCg0KSSBhbHNvIHNlZSB0aGF0IHdl IHdhc3RlIGEgbG90IG9mIHdvcmRzIG9uIHRoZSBsaXN0IG9uIHRoaXMgdG9waWMgdGhhdCBtYXkg YmUgb3V0IG9mIHNjb3BlICh1cCB0byBjaGFpciB0byBtZWRpYXRlIKGtKS4gIFRoZSBwdXJwb3Nl IG9mIHRoZSByZXF1aXJlbWVudHMgYW5kIHVzZSBjYXNlIHByb2Nlc3MgaXMgdG8gY3JlYXRlIGNv bnNlbnN1cyBmcm9tIHRoZSB0b3AgZG93biB0byBmYWNpbGl0YXRlIHRoZSBjcmVhdGlvbiAgb2Yg YSBzcGVjaWZpY2F0aW9uIG9mIHRoZSBiZXN0IHBvc3NpYmxlIGRvY3VtZW50IGZyb20gdGhlIHdv cmtpbmcgZ3JvdXAuICBXZSBzaG91bGQgaWdub3JlIGFueSBkaXNjdXNzaW9ucyBhbmQgY29udHJp YnV0aW9ucyBvbiBvdXQtb2Ytc2NvcGUgY29udHJpYnV0aW9ucyBhbmQgZm9jdXMgb24gdGhlIGN1 cnJlbnQgc2NvcGUgYW5kIHdvcmsgaXRlbXMuDQoNClBhdWwNCg0KDQpQYXVsIEEuIExhbWJlcnQg fCBNYXJ2ZWxsIFNlbWljb25kdWN0b3IgfCArMS02NTAtNzg3LTkxNDENCg0KRnJvbTogWmh1TGVp IFttYWlsdG86bGVpLnpodUBodWF3ZWkuY29tXTxtYWlsdG86W21haWx0bzpsZWkuemh1QGh1YXdl aS5jb21dPg0KU2VudDogVHVlc2RheSwgTWFyY2ggMTMsIDIwMTIgMTo0NyBBTQ0KVG86IFBhdWwg TGFtYmVydDsgcGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4NClN1YmplY3Q6IFJF OiBUaW1lIHRvIHByZXNlbnQgbXkgSUQgaW4gSUVURiBQYXJpcyBtZWV0aW5nDQoNCkhpIFBhdWws DQoNCkRvIHlvdSBwcmVmZXIgdG8gcmVtb3ZlIHRoaXMgaW50ZXJtZWRpYXJ5IGZ1bmN0aW9uPyBU aGUgaW50ZW50aW9uIG9mIHRoaXMgZHJhZnQgaXMgc3RpbGwgdG8gcHJvdmlkZSBhIHByb3Bvc2Fs IG9mIGZyYW1ld29yayBhbmQgcHJvdG9jb2wsIHByb2JhYmx5IGluY2x1ZGluZyB3aG9sZSBwaWN0 dXJlIHdpdGggZXNzZW50aWFsIGVsZW1lbnRzLCBkaXNjb3ZlcnksIHF1ZXJ5LCB1cGRhdGUgZXRj Lg0KDQpBcyB3aGF0IGlzIG1lbnRpb25lZCBpbiBlLW1haWwgbGlzdCBhbmQgbGFzdCBGMkYgbWVl dGluZywgcG9zc2libHksIHRoZSBQQVdTIG1pZ2h0IGJlIHZlcnkgZXh0ZW5zaWJsZSBzaW5jZSB0 aGUgYmFzaWMgY29uY2VwdHMsIHNjZW5hcmlvcyBhbmQgcmVxdWlyZW1lbnRzIGFyZSBlc3RhYmxp c2hlZCB1cG9uIHRoZSBGQ0MgYW5kIG90aGVyIHJlZ3VsYXRvcnOhryBwcm9jZXNzIG9mIHdoaXRl IHNwYWNlLiBXZSBzdGlsbCBoYXZlIHNvbWUgcG90ZW50aWFsIG5lZWRzIGRvaW5nIGZ1cnRoZXIg YXQgZmVhdHVyZSBsZXZlbCBvciBldmVuIGFyY2hpdGVjdHVyZSBsZXZlbC4gQXQgbGVhc3QsIHRo ZSBkZXNpZ24gb2YgdGhpcyBwcm90b2NvbCBzaG91bGQgbWFrZSBzdXJlIHRoaXMgbmVlZC4gRnJv bSB0aGlzIHBlcnNwZWN0aXZlLCBhdXRoZW50aWNhdGlvbiBhbmQgY29udGVudCBwcm90ZWN0aW9u IG1pZ2h0IGJlIGNvbnNpZGVyZWQgZnVydGhlciwgaG9wZWZ1bGx5LCB3ZSBhcmUgYWJsZSB0byBk aXNjdXNzIHNlY3VyaXR5IGluIFBhcmlzLg0KDQpXZSBhbHNvIHJlYWxseSBtZXQgdmFyeSBzaXR1 YXRpb25zIG9mIGRpZmZlcmVudCBhcmVhcyBhbmQgcmVnaW9ucyB3aG8gZG9taW5hdGUgYSBxdWl0 ZSBudW1iZXIgb2YgTWFzdGVyIGRldmljZXMuIEkgd291bGQgbm90IGltYWdlIG9uZSBkYXRhYmFz ZSBzZXJ2aW5nIGh1Z2UgbnVtYmVyIG9mIE1hc3RlciBkZXZpY2VzLiBGb3Igc29tZSByZWFzb25z LCByZWd1bGF0b3IgbWF5IGF1dGhvcml6ZSBicmFuY2hlcyB0byBhZG1pbmlzdHJhdGUgb3IgbWFp bnRhaW4gd2hpdGUgc3BhY2UgZGF0YSBiYXNlIHdoaWNoIGRvbWluYXRlcyBhIHBhcnRpY3VsYXIg cmVnaW9uLiBJIGRvIG5vdCB0aGluayB0aGUgbXVsdGlwbGUgZGF0YSBiYXNlcyBvciBkaXN0cmli dXRlZCBkYXRhIG1vZGVsIGZyYW1ld29yayBhcmUgY29udHJvdmVyc2lhbCB0byB1cywgYnV0IHRo ZSBhZGRpdGlvbmFsIGZ1bmN0aW9ucyBvZiB0aGlzIGNvb3JkaW5hdGluZyBkYXRhIGJhc2UuIFRo aXMgaW50ZXJtZWRpYXRlIG5vZGUgd2l0aCB3aGl0ZSBzcGFjZSBzcGVjdHJ1bSBkZWNpc2lvbiBt YWtpbmcgZnVuY3Rpb24gaXMgdGhlIGlzc3VlIG9mIGV4dGVuc2liaWxpdHksIHdoaWNoIGNhbiBi ZSBoZWxwZnVsIHdoZW4gYWRkaW5nIHNvbWUgZmVhdHVyZSB3aGljaCBpcyBub3QgZGVzaXJlZCB0 byBtYWluIGRhdGEgYmFzZS4gRGVjaXNpb24gbWFraW5nIGZ1bmN0aW9uIGNvdWxkIGJlIG5vdCBh IGZ1bmN0aW9uYWxpdHkgb2YgbWFpbiBkYXRhIGJhc2Ugd2hpY2ggbmVlZHMgdG8gYmUgdmVyeSBz dGFibGUgYW5kIHN0YXRpYy4gSWYgd2UgcmVhbGx5IGV4dGVudCBjb2V4aXN0ZW5jZSBvciBpbnRl cmZlcmVuY2UgYXZvaWRhbmNlIHJvbGUgdG8gUEFXUyBwcm90b2NvbCwgaXQgd291bGQgYmUgZWFz aWVyIHRvIGV4dGVudCBpbnRlcm1lZGlhcnkgZnVuY3Rpb24gd2l0aG91dCBpbXBhY3RzIG9uIGZy YW1ld29yayBvZiBQQVdTLCBhbmQsIHN0cnVjdHVyZSBhbmQgcHJvdG9jb2wgb2YgUEFXUy4gVGhp cyBub2RlIGlzIGJlbGlldmVkIHRvIGV4aXN0IGZvciB0aGlzIHB1cnBvc2UuDQoNCkkgYW0gbm90 IHN1cmUgdGhhdCB5b3Ugd291bGQgc3VwcG9ydCB0aGlzIGlkZWEsIGJ1dCB0aGUgdGV4dCBkZXNj cmliaW5nIHRoaXMgY2FuIG1ha2UgdGhpbmdzIGNsZWFyZXIgd2hlbiB0YWxraW5nIGFib3V0IHRo aXMuDQoNCkJlc3QgcmVnYXJkcywNClpodSBMZWkNCg0KDQq3orz+yMs6IFBhdWwgTGFtYmVydCBb bWFpbHRvOnBhdWxAbWFydmVsbC5jb21dPG1haWx0bzpbbWFpbHRvOnBhdWxAbWFydmVsbC5jb21d Pg0Kt6LLzcqxvOQ6IDIwMTLE6jPUwjEzyNUgMTU6MjgNCsrVvP7IyzogWmh1TGVpOyBwYXdzQGll dGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPg0K1vfM4jogUkU6IFRpbWUgdG8gcHJlc2VudCBt eSBJRCBpbiBJRVRGIFBhcmlzIG1lZXRpbmcNCg0KDQpEaWQgb3VyIGNvbnNlbnN1cyBwcm9jZXNz IGluY2x1ZGUgYSBjb29yZGluYXRpbmcgaW50ZXJtZWRpYXJ5IGZ1bmN0aW9uPw0KDQogICBUaGUg Y29vcmRpbmF0aW5nIGRhdGFiYXNlIGNhbiBnZXQgd2hpdGUgc3BhY2UgY2hhbm5lbHMgZnJvbSBk YXRhYmFzZSwNCiAgIHJlY2VpdmUgdGhlIHdoaXRlIHNwYWNlIHF1ZXJ5aW5nIG1lc3NhZ2UgZnJv bSBtYXN0ZXIgZGV2aWNlIGFuZA0KICAgcHJvdmlkZSB0aGUgYXZhaWxhYmxlIHdoaXRlIHNwYWNl IGNoYW5uZWxzIGZvciBtYXN0ZXIgZGV2aWNlcyB3aXRoDQogICBzb21lIGRlZ3JlZSBkZWNpc2lv biBtYWtpbmcgcHJvY2Vzcy4gIFRoZXNlIGRlY2lzaW9uIG1ha2luZyBwcm9jZXNzDQogICBtaWdo dCBwcm92aWRlIGZ1bmN0aW9uYWxpdHkgb2Ygd2hpdGUgc3BhY2UgYWNjZXNzIHByb3RvY29sIHBv d2VyIHRvDQogICByZXNwb25zZSBhdmFpbGFibGUgY2hhbm5lbHMgYWNjb3JkaW5nIHRvIHJlY2Vp dmVkIGRldmljZSBwYXJhbWV0ZXJzDQogICAoZS5nLiBwb3dlciwgUkYgcGFyYW1ldGVyKSwgbG9j YXRpb24gaW5mb3JtYXRpb24oZS5nLiBhbHRpdHVkZSwNCiAgIHBvc2l0aW9uIGFuZCBkaXJlY3Rp b24gb2YgYW50ZW5uYSApIGFuZCBzb21lIHBhcnRpY3VsYXIgd2hpdGUgc3BhY2UNCiAgIHNwZWN0 cnVtIGRlY2lzaW9uIG1ha2luZyBwb2xpY2llcy4NCg0KRG9uoa90IHNlZSB0aGF0IHRoaXMgaXMg aW4gc2NvcGUuIFNlZW1zIGluYXBwcm9wcmlhdGUgdG8gY3JlYXRlIGNvbXBsZXRlIElEcyB3aXRo IGZlYXR1cmVzIHRoYXQgYXJlIG91dC1vZi1zY29wZS4NCg0KUGF1bA0KDQoNCkZyb206IHBhd3Mt Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOnBh d3MtYm91bmNlc0BpZXRmLm9yZ108bWFpbHRvOlttYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3Jn XT4gT24gQmVoYWxmIE9mIFpodUxlaQ0KU2VudDogVHVlc2RheSwgTWFyY2ggMTMsIDIwMTIgMTI6 MDIgQU0NClRvOiBwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPg0KU3ViamVjdDog W3Bhd3NdIFRpbWUgdG8gcHJlc2VudCBteSBJRCBpbiBJRVRGIFBhcmlzIG1lZXRpbmcNCg0KSGkg Rm9sa3MgYW5kIGNoYWlycywNCg0KQXMgd2hhdCB5b3UgbWlnaHQgbm90aWNlLCBJIHVwbG9hZGVk IGEgSUQgb24gUEFXUyBmcmFtZXdvcmsgYW5kIHByb3RvY29sIHdoaWNoIGlzIHRvIGZ1bGZpbGwg UEFXUyByZXF1aXJlbWVudHMgYW5kIHJlZ3VsYXRvcnOhryByZXF1aXJlbWVudHMsIKGwd3d3Lmll dGYub3JnL2lkL2RyYWZ0LWxlaS1wYXdzLWZyYW1ld29yay1kYXRhbW9kZWwtMDAudHh0PGh0dHA6 Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtbGVpLXBhd3MtZnJhbWV3b3JrLWRhdGFtb2RlbC0wMC50 eHQ+obEuICBJIHdvdWxkIHZlcnkgbGlrZSB0byByZXF1ZXN0IDI1IG1pbnV0ZXMgcHJlc2VudGlu ZyBhbmQgZGlzY3Vzc2luZyBpdCBkdXJpbmcgSUVURiBQYXJpcyBtZWV0aW5nLg0KDQpCZXN0IHJl Z2FyZHMsDQpaaHUgTGVpDQo= --_000_7BAC95F5A7E67643AAFB2C31BEE662D015E331DB50SCVEXCH2marve_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

&n= bsp;

>Thi= s is a proposal defining a protocol between WSD and WSDB, so I believe =

>it = is in scope. Perhaps if we wanted to provide constructive feedback to the

>aut= hors we could suggest revising the terminology of their draft.

&n= bsp;

The =A1= =B0coordinating database=A1=B1 is neither a WSD or a WSDB.  The constructive criticism= is that this concept is: out-of-scope (IMO), unnecessary and should be fully removed fro= m the draft and further discussions on this list.

&n= bsp;

Paul

&n= bsp;

 

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

&n= bsp;

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Zu= niga, Juan Carlos
Sent: Tuesday, March 13, 2012 6:43 PM
To: paws@ietf.org
Subject: Re: [paws] Time to present my ID in IETF Paris meeting=

 

Unfortu= nately we don=A1=AFt have a reference architecture to work upon, so people will ma= ke the proposals and comments based on what they understand.

&n= bsp;

We have= agreed before to limit the terminology to =A1=B0WSD <-> WSDB=A1=B1 to keep i= t simple.

&n= bsp;

We know= that WSD will be a device and WSDB a server-based service provided by a WS Servi= ce Provider (most likely not the Regulator).

&n= bsp;

This is= a proposal defining a protocol between WSD and WSDB, so I believe it is in sc= ope. Perhaps if we wanted to provide constructive feedback to the authors we cou= ld suggest revising the terminology of their draft.

&n= bsp;

Jc=

&n= bsp;

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Ba= savaraj.Patil@nokia.com
Sent: Tuesday, March 13, 2012 2:06 PM
To: Gabor.Bajko@nokia.com; paws@ietf.org
Subject: Re: [paws] Time to present my ID in IETF Paris meeting=

 

>Why would the chairs mediate this discussion?

In order to ensure we are not wasting bandwidth on topics that are clearly outside the WG scope...
And it is your responsibility to moderate to ensure we are making forward progress..
And because you get to wear the blue dot ;)

Sent from my Lumia 800

From: <= /b>Bajko Gabor (Nokia-CIC/SiliconValley)
Sent: 3/13/2012 6:43 PM
To: paws@ietf.org<= /span>
Subject: Re: [paws] Time to present my ID in IETF Paris meeting

Why wou= ld the chairs mediate this discussion? There=A1=AFs an individual submission and t= he author is seeking comments on the list before the presentation in the f2f.<= o:p>

That is= how ietf works, we need comments to the list to make progress one way or the ot= her.

 <= /span>

-          Gabor

 <= /span>

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ex= t Paul Lambert
Sent: Tuesday, March 13, 2012 2:32 PM
To: ZhuLei; paws@ietf.org
Subject: Re: [paws] Time to present my ID in IETF Paris meeting

 

Hi Zhu,=

 <= /span>

> I am not su= re that you would support this idea, but the text describing this can make thi= ngs clearer when talking about this.

 

No I do not support the idea of additional layers of =A1=B0coordinating database=A1=B1.  Especially for detailed designs using HTTPS.

 

> I would not image one database serving huge number of Master devices. For s= ome reasons, regulator

>may authorize branches to administrate or maintain white space data base which dominates a particular region.

 

Out-of-scope and completely unnecessary.  When you use SSL to access a bank account= do you care that there may be multiple servers that look like a single entity = to the user?   New layers of abstraction are not required for scalability.  The same protocol can be used to one or multiple servers.  Yes, some considerations need to be discussed about authentication.  No new entities, layers, architectural blocks, concep= ts, frameworks or protocols are required for =A1=B0serving a huge number =A1=AD= =A1=B0.

 

I also see that we waste a lot of words on the list on this topic that may be= out of scope (up to chair to mediate =A1=AD).  The purpose of the requirem= ents and use case process is to create consensus from the top down to facilitate the creation  of a specification of the best possible document from the working group.  We should ignore any discussions and contributions on out-of-scope contributions and focus on the current scope and work items.

 

Paul

 <= /span>

 

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

 <= /span>

From: ZhuLei [mailto:lei.zhu@huawei.com]=
Sent: Tuesday, March 13, 2012 1:47 AM
To: Paul Lambert; paws@ietf.org=
Subject: RE: Time to present my ID in IETF Paris meeting=

 

Hi Paul,

 =

Do you prefer to remove = this intermediary function? The intention of this draft is still to provide a proposal of framework and protocol, probably including whole picture with e= ssential elements, discovery, query, update etc.

 =

As what is mentioned in = e-mail list and last F2F meeting, possibly, the PAWS might be very extensible sinc= e the basic concepts, scenarios and requirements are established upon the FCC= and other regulators=A1=AF process of white space. We still have some potential= needs doing further at feature level or even architecture level. At least, the de= sign of this protocol should make sure this need. From this perspective, authentication and content protection might be considered further, hopefull= y, we are able to discuss security in Paris.

 =

We also really met vary situations of different areas and regions who dominate= a quite number of Master devices. I would not image one database serving huge number of Master devices. For some reasons, regulator may authorize branche= s to administrate or maintain white space data base which dominates a particular region. I do not think the multiple data bases or distributed data model framework are controversial to us, but the additional functions of this coordinating data base. This intermediate node with white space spectrum decision making function is the issue of extensibility, which can be helpfu= l when adding some feature which is not desired to main data base. Decision making function could be not a functionality of main data base which needs = to be very stable and static. If we really extent coexistence or interference avoidance role to PAWS protocol, it would be easier to extent intermediary function without impacts on framework of PAWS, and, structure and protocol = of PAWS. This node is believed to exist for this purpose.

 

I am not sure that you would support this idea, but the text describing this = can make things clearer when talking about this.

 

Best regards,

Zhu Lei

 

 =

=B7=A2=BC=FE=C8=CB= : Paul Lambert [mailto:paul@marvell.com] =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C213=C8=D5 15:28
=CA=D5=BC=FE=C8=CB: ZhuLei; paws@ietf.org
=D6=F7=CC=E2: RE: Time to present my ID in= IETF Paris meeting

 

 <= /span>

Did our consensus process include a coordinating intermediary function?=

 

   The coordinating database ca= n get white space channels from database,

   receive the white space quer= ying message from master device and

   provide the available white space channels for master devices with

   some degree decision making process.  These decision making process =

   might provide functionality = of white space access protocol power to

   response available channels according to received device parameters

   (e.g. power, RF parameter), location information(e.g. altitude,

   position and direction of antenna ) and some particular white space

   spectrum decision making policies.

 <= /span>

Don=A1= =AFt see that this is in scope. Seems inappropriate to create complete IDs with features = that are out-of-scope.

 <= /span>

Paul

 <= /span>

 <= /span>

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.or= g] On Behalf Of ZhuLei
Sent: Tuesday, March 13, 2012 12:02 AM
To: paws@ietf.org
Subject: [paws] Time to present my ID in IETF Paris meeting

 

Hi Folks and chairs,

 

As what you might notice, I uploaded a ID on PAWS fram= ework and protocol which is to fulfill PAWS requirements and regulators=A1=AF requirements, =A1=B0w= ww.ietf.org/id/draft-lei-paws-framework-datamodel-00.txt=A1=B1.  I would very like to request 25 minutes presenting and discussing it during IETF Paris meeting.

 

Best regards,

Zhu Lei

--_000_7BAC95F5A7E67643AAFB2C31BEE662D015E331DB50SCVEXCH2marve_-- From nbravin@earthlink.net Tue Mar 13 20:25:17 2012 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 0CC9621E8026 for ; Tue, 13 Mar 2012 20:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.315 X-Spam-Level: X-Spam-Status: No, score=0.315 tagged_above=-999 required=5 tests=[AWL=-1.633, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=1.396, SARE_BIZOP=0.7] 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 nGtLU3lBYf0V for ; Tue, 13 Mar 2012 20:25:15 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 43FDD21E8017 for ; Tue, 13 Mar 2012 20:25:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Ndv8p9CNmXgHclF3iUbrXEdS5UHguh5BpaY963U0Lv6VUwh8B2deUVSObMnhwpZN; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [98.150.41.129] (helo=[10.0.1.2]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1S7eps-0001t8-BJ; Tue, 13 Mar 2012 23:25:13 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-6--946490983 From: Nancy Bravin In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D015E331DB50@SC-VEXCH2.marvell.com> Date: Tue, 13 Mar 2012 20:25:10 -0700 Message-Id: References: <470F27D1263A1B4EB73491ED995DE62516234020@szxeml504-mbs.china.huawei.com><7BAC95F5A7E67643AAFB2C31BEE662D015E331D955@SC-VEXCH2.marvell.com><470F27D1263A1B4EB73491ED995DE625162340C4@szxeml504-mbs.china.huawei.com><7BAC95F5A7E67643AAFB2C31BEE662D015E331DAA3@SC-VEXCH2.marvell.com>, <1ECAFF543A2FED4EA2BEB6CACE08E47601E1F496@008-AM1MPN1-006.mgdnok.nokia.com> <21E7D9BD69CC7241AAE00F4EA183B7191066E24F@008-AM1MPN1-073.mgdnok.nokia.com> <7BAC95F5A7E67643AAFB2C31BEE662D015E331DB50@SC-VEXCH2.marvell.com> To: Paul Lambert X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad863f5bc618a6e504eb3b459cbf51e62465350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.150.41.129 Cc: "paws@ietf.org" Subject: Re: [paws] Time to present my ID in IETF Paris 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: Wed, 14 Mar 2012 03:25:17 -0000 --Apple-Mail-6--946490983 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 All, In my opinion, we must address how the rest of the world beside the USA, = UK, FInland etc would need to use a DB(s) and if one or more countries wants to have an offloading database in its regs for one reason or = another..that is not out of scope, it is under the DB and regulator = control. It may be a great business opportunity, it may be a way for a country = with a huge population to do things it cannot do now. I think if it is under the database, and it is something that the regs in China = will ask for, why not listen to a presentation with an open mind. Maybe one database will be for one set of circumstances, another for = offloading, when needed? or One will be dedicated to more than WSD and have some proprietary things on it, the other will not? I myself = would like to learn more of the thoughts of having what Zhu Lei is=20 presenting, and you will be able to ask questions, maybe there will be a = slide deck for examples of how her country is thinking. Knowledge is a good thing=A1=ADlet's give it a chance to be heard under = the scope of DB. My 2 cents.=20 Nancy On Mar 13, 2012, at 7:20 PM, Paul Lambert wrote: > =20 > >This is a proposal defining a protocol between WSD and WSDB, so I = believe > >it is in scope. Perhaps if we wanted to provide constructive feedback = to the > >authors we could suggest revising the terminology of their draft. > =20 > The =A1=B0coordinating database=A1=B1 is neither a WSD or a WSDB. The = constructive criticism is that this concept is: out-of-scope (IMO), = unnecessary and should be fully removed from the draft and further = discussions on this list. > =20 > Paul > =20 > =20 > Paul A. Lambert | Marvell Semiconductor | +1-650-787-9141 > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of Zuniga, Juan Carlos > Sent: Tuesday, March 13, 2012 6:43 PM > To: paws@ietf.org > Subject: Re: [paws] Time to present my ID in IETF Paris meeting > =20 > Unfortunately we don=A1=AFt have a reference architecture to work = upon, so people will make the proposals and comments based on what they = understand. > =20 > We have agreed before to limit the terminology to =A1=B0WSD <-> WSDB=A1=B1= to keep it simple. > =20 > We know that WSD will be a device and WSDB a server-based service = provided by a WS Service Provider (most likely not the Regulator). > =20 > This is a proposal defining a protocol between WSD and WSDB, so I = believe it is in scope. Perhaps if we wanted to provide constructive = feedback to the authors we could suggest revising the terminology of = their draft. > =20 > Jc > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of Basavaraj.Patil@nokia.com > Sent: Tuesday, March 13, 2012 2:06 PM > To: Gabor.Bajko@nokia.com; paws@ietf.org > Subject: Re: [paws] Time to present my ID in IETF Paris meeting > =20 > >Why would the chairs mediate this discussion? >=20 > In order to ensure we are not wasting bandwidth on topics that are = clearly outside the WG scope... > And it is your responsibility to moderate to ensure we are making = forward progress.. > And because you get to wear the blue dot ;) >=20 > Sent from my Lumia 800 > From: Bajko Gabor (Nokia-CIC/SiliconValley) > Sent: 3/13/2012 6:43 PM > To: paws@ietf.org > Subject: Re: [paws] Time to present my ID in IETF Paris meeting >=20 > Why would the chairs mediate this discussion? There=A1=AFs an = individual submission and the author is seeking comments on the list = before the presentation in the f2f. > That is how ietf works, we need comments to the list to make progress = one way or the other. > =20 > - Gabor > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of ext Paul Lambert > Sent: Tuesday, March 13, 2012 2:32 PM > To: ZhuLei; paws@ietf.org > Subject: Re: [paws] Time to present my ID in IETF Paris meeting > =20 > Hi Zhu, > =20 > > I am not sure that you would support this idea, but the text = describing this can make things clearer when talking about this. > =20 > No I do not support the idea of additional layers of =A1=B0coordinating = database=A1=B1. Especially for detailed designs using HTTPS. > =20 > > I would not image one database serving huge number of Master = devices. For some reasons, regulator > >may authorize branches to administrate or maintain white space data = base which dominates a particular region. > =20 > Out-of-scope and completely unnecessary. When you use SSL to access a = bank account do you care that there may be multiple servers that look = like a single entity to the user? New layers of abstraction are not = required for scalability. The same protocol can be used to one or = multiple servers. Yes, some considerations need to be discussed about = authentication. No new entities, layers, architectural blocks, = concepts, frameworks or protocols are required for =A1=B0serving a huge = number =A1=AD =A1=B0. > =20 > I also see that we waste a lot of words on the list on this topic that = may be out of scope (up to chair to mediate =A1=AD). The purpose of the = requirements and use case process is to create consensus from the top = down to facilitate the creation of a specification of the best possible = document from the working group. We should ignore any discussions and = contributions on out-of-scope contributions and focus on the current = scope and work items. > =20 > Paul > =20 > =20 > Paul A. Lambert | Marvell Semiconductor | +1-650-787-9141 > =20 > From: ZhuLei [mailto:lei.zhu@huawei.com]=20 > Sent: Tuesday, March 13, 2012 1:47 AM > To: Paul Lambert; paws@ietf.org > Subject: RE: Time to present my ID in IETF Paris meeting > =20 > Hi Paul, > =20 > Do you prefer to remove this intermediary function? The intention of = this draft is still to provide a proposal of framework and protocol, = probably including whole picture with essential elements, discovery, = query, update etc. > =20 > As what is mentioned in e-mail list and last F2F meeting, possibly, = the PAWS might be very extensible since the basic concepts, scenarios = and requirements are established upon the FCC and other regulators=A1=AF = process of white space. We still have some potential needs doing further = at feature level or even architecture level. At least, the design of = this protocol should make sure this need. =46rom this perspective, = authentication and content protection might be considered further, = hopefully, we are able to discuss security in Paris. > =20 > We also really met vary situations of different areas and regions who = dominate a quite number of Master devices. I would not image one = database serving huge number of Master devices. For some reasons, = regulator may authorize branches to administrate or maintain white space = data base which dominates a particular region. I do not think the = multiple data bases or distributed data model framework are = controversial to us, but the additional functions of this coordinating = data base. This intermediate node with white space spectrum decision = making function is the issue of extensibility, which can be helpful when = adding some feature which is not desired to main data base. Decision = making function could be not a functionality of main data base which = needs to be very stable and static. If we really extent coexistence or = interference avoidance role to PAWS protocol, it would be easier to = extent intermediary function without impacts on framework of PAWS, and, = structure and protocol of PAWS. This node is believed to exist for this = purpose. > =20 > I am not sure that you would support this idea, but the text = describing this can make things clearer when talking about this. > =20 > Best regards, > Zhu Lei > =20 > =20 > =B7=A2=BC=FE=C8=CB: Paul Lambert [mailto:paul@marvell.com]=20 > =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C213=C8=D5 15:28 > =CA=D5=BC=FE=C8=CB: ZhuLei; paws@ietf.org > =D6=F7=CC=E2: RE: Time to present my ID in IETF Paris meeting > =20 > =20 > Did our consensus process include a coordinating intermediary = function? > =20 > The coordinating database can get white space channels from = database, > receive the white space querying message from master device and > provide the available white space channels for master devices with > some degree decision making process. These decision making process > might provide functionality of white space access protocol power to > response available channels according to received device parameters > (e.g. power, RF parameter), location information(e.g. altitude, > position and direction of antenna ) and some particular white space > spectrum decision making policies. > =20 > Don=A1=AFt see that this is in scope. Seems inappropriate to create = complete IDs with features that are out-of-scope. > =20 > Paul > =20 > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of ZhuLei > Sent: Tuesday, March 13, 2012 12:02 AM > To: paws@ietf.org > Subject: [paws] Time to present my ID in IETF Paris meeting > =20 > Hi Folks and chairs, > =20 > As what you might notice, I uploaded a ID on PAWS framework and = protocol which is to fulfill PAWS requirements and regulators=A1=AF = requirements, = =A1=B0www.ietf.org/id/draft-lei-paws-framework-datamodel-00.txt=A1=B1. = I would very like to request 25 minutes presenting and discussing it = during IETF Paris meeting. > =20 > Best regards, > Zhu Lei > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws --Apple-Mail-6--946490983 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312 All,

In my opinion, we must = address how the rest of the world beside the USA, UK, FInland etc would = need to use a DB(s) and if one or more countries
wants to have = an offloading database in its regs for one reason or another..that is = not out of scope, it is under the DB and regulator control.
It = may be a great business opportunity, it may be a way for a country with = a huge population to do things it cannot do now. I think
if it = is under the database, and it is something that the regs in China will = ask for, why not listen to a presentation with an open = mind.
Maybe one database will be for one set of circumstances, = another for offloading, when needed? or One will be dedicated to more = than WSD
and have some proprietary things on it, the other = will not? I myself would like to learn more of the thoughts of having = what Zhu Lei is 
presenting, and you will be able to ask = questions, maybe there will be a slide deck for examples of how her = country is thinking.

Knowledge is a good = thing=A1=ADlet's give it a chance to be heard under the scope of = DB.

My 2 = cents. 

Nancy


<= div>
On Mar 13, 2012, at 7:20 PM, Paul Lambert wrote:

 
Paul
 
 
Paul A. Lambert | Marvell Semiconductor | = +1-650-787-9141
 paws-bounces@ietf.org [mailto:paws-bounces@ietf.org= ] On Behalf Of Zuniga, Juan = Carlos
Sent: Tuesday, March 13, 2012 = 6:43 PM
To: paws@ietf.org
Subject: Re: [paws] Time to present = my ID in IETF Paris meeting
 
Unfortunately we don=A1=AFt have a reference = architecture to work upon, so people will make the proposals and = comments based on what they understand.
 
We have agreed before to limit the = terminology to =A1=B0WSD <-> WSDB=A1=B1 to keep it = simple.
 paws-bounces@ietf.org [mailto:paws-bounces@ietf.org= ] On Behalf Of  Tuesday, March 13, 2012 = 2:06 PM
To: Gabor.Bajko@nokia.com; paws@ietf.org
Subject: Re: [paws] Time to present = my ID in IETF Paris meeting
>Why would the chairs mediate = this discussion?

In order to ensure we are not wasting bandwidth = on topics that are clearly outside the WG scope...
And it is your = responsibility to moderate to ensure we are making forward = progress..
And because you get to wear the blue dot ;)

Sent = from my Lumia 800

From: Bajko Gabor = (Nokia-CIC/SiliconValley)
Sent: 3/13/2012 = 6:43 PMTo: paws@ietf.org
Subject: Re: [paws] = Time to present my ID in IETF Paris meetingThat is how ietf works, we need comments to = the list to make progress one way or the = other.

- 
From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org= ] On Behalf Of ext Paul = Lambert
Sent: Tuesday, March 13, 2012 = 2:32 PM
To: ZhuLei; paws@ietf.org
Subject: Re: [paws] Time to present = my ID in IETF Paris meeting
 
Hi Zhu,
 
> I am not sure = that you would support this idea, but the text describing this can make = things clearer when talking about this.
 
No I do not support the idea = of additional layers of =A1=B0coordinating database=A1=B1.  = Especially for detailed designs using HTTPS.
 
> I would not image one = database serving huge number of Master devices. For some reasons, = regulator
>may authorize branches = to administrate or maintain white space data base which dominates a = particular region.
Out-of-scope and completely = unnecessary.  When you use SSL to access a bank account do you care = that there may be multiple servers that look like a single entity to the = user?   New layers of abstraction are not required for = scalability.  The same protocol can be used to one or multiple = servers.  Yes, some considerations need to be discussed about = authentication.  No new entities, layers, architectural blocks, = concepts, frameworks or protocols are required for =A1=B0serving a huge = number =A1=AD =A1=B0.
I also see that we waste a = lot of words on the list on this topic that may be out of scope (up to = chair to mediate =A1=AD).  The purpose of the requirements and use = case process is to create consensus from the top down to facilitate the = creation  of a specification of the best possible document from the = working group.  We should ignore any discussions and contributions = on out-of-scope contributions and focus on the current scope and work = items.
Paul A. = Lambert | Marvell Semiconductor | = +1-650-787-9141
 ZhuLei [mailto:lei.zhu@huawei.com] 
Sent: Tuesday, March 13, 2012 = 1:47 AM
To: Paul Lambert; paws@ietf.org
Subject: RE: Time to present my ID = in IETF Paris meeting
 
Hi Paul,
Do you prefer to = remove this intermediary function? The intention of this draft is still = to provide a proposal of framework and protocol, probably including = whole picture with essential elements, discovery, query, update = etc.
 
As what is mentioned in e-mail list and last F2F meeting, = possibly, the PAWS might be very extensible since the basic concepts, = scenarios and requirements are established upon the FCC and other = regulators=A1=AF process of white space. We still have some potential = needs doing further at feature level or even architecture level. At = least, the design of this protocol should make sure this need. =46rom = this perspective, authentication and content protection might be = considered further, hopefully, we are able to discuss security in = Paris.
We also really met vary = situations of different areas and regions who dominate a quite number of = Master devices. I would not image one database serving huge number of = Master devices. For some reasons, regulator may authorize branches to = administrate or maintain white space data base which dominates a = particular region. I do not think the multiple data bases or distributed = data model framework are controversial to us, but the additional = functions of this coordinating data base. This intermediate node with = white space spectrum decision making function is the issue of = extensibility, which can be helpful when adding some feature which is = not desired to main data base. Decision making function could be not a = functionality of main data base which needs to be very stable and = static. If we really extent coexistence or interference avoidance role = to PAWS protocol, it would be easier to extent intermediary function = without impacts on framework of PAWS, and, structure and protocol of = PAWS. This node is believed to exist for this = purpose.
I am not sure that you would = support this idea, but the text describing this can make things clearer = when talking about this.
Best = regards,
Zhu = Lei
 
 
: Paul Lambert [mailto:paul@marvell.com] 
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C213=C8=D5 15:28
=CA=D5=BC=FE=C8=CB: ZhuLei; paws@ietf.org
=D6=F7=CC=E2: RE: Time to present my ID = in IETF Paris meeting
 
 
Did our consensus process include a = coordinating intermediary function?
 
   The coordinating database can = get white space channels from database,
   receive the white space = querying message from master device and
   provide the available white = space channels for master devices with
   some degree decision making = process.  These decision making process
   might provide functionality = of white space access protocol power to
   response available channels = according to received device parameters
   (e.g. power, RF parameter), = location information(e.g. altitude,
   position and direction of = antenna ) and some particular white space
   spectrum decision making = policies.
 paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ZhuLei
Sent: Tuesday, March 13, 2012 = 12:02 AM
To: paws@ietf.org
Subject: [paws] Time to present my = ID in IETF Paris meeting
 
Hi Folks and = chairs,
As what you might = notice, I uploaded a ID on PAWS framework and protocol which is to = fulfill PAWS requirements and regulators=A1=AF requirements, =A1=B0 
____________= ___________________________________
paws mailing list
paws@ietf.org
Subject: Re: [paws] Time to present my ID in IETF Paris 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: Wed, 14 Mar 2012 13:15:38 -0000 QmVzaWRlcywgcmVnYXJkbGVzcyBvZiBvbmUncyBvcGluaW9uIG9uIHRoZSBjb29yZGluYXRpbmcg ZGF0YWJhc2UNCmNvbmNlcHQsIGl0IGlzIHJlYWxseSBqdXN0IGEgbWlub3IgcGFydCBvZiB0aGlz IGRyYWZ0LiAgVGhlIGRyYWZ0DQpnb2VzIGludG8gcXVpdGUgYSBiaXQgb2YgZGV0YWlsIG9uIGFu IFhNTCBzY2hlbWEgZm9yIGRldmljZTwtPldTREINCmNvbW11bmljYXRpb24uICBJIHdvdWxkIGhv cGUgaXQgZ2V0cyBzb21lIGFnZW5kYSB0aW1lIGluIFBhcmlzLg0KDQotUGV0ZQ0KDQpOYW5jeSBC cmF2aW4gd3JvdGU6DQo+IEFsbCwNCj4gDQo+IEluIG15IG9waW5pb24sIHdlIG11c3QgYWRkcmVz cyBob3cgdGhlIHJlc3Qgb2YgdGhlIHdvcmxkIGJlc2lkZSB0aGUgDQo+IFVTQSwgVUssIEZJbmxh bmQgZXRjIHdvdWxkIG5lZWQgdG8gdXNlIGEgREIocykgYW5kIGlmIG9uZSBvciBtb3JlIA0KPiBj b3VudHJpZXMgd2FudHMgdG8gaGF2ZSBhbiBvZmZsb2FkaW5nIGRhdGFiYXNlIGluIGl0cyByZWdz IGZvciBvbmUgDQo+IHJlYXNvbiBvciBhbm90aGVyLi50aGF0IGlzIG5vdCBvdXQgb2Ygc2NvcGUs IGl0IGlzIHVuZGVyIHRoZSBEQiBhbmQgDQo+IHJlZ3VsYXRvciBjb250cm9sLg0KPiBJdCBtYXkg YmUgYSBncmVhdCBidXNpbmVzcyBvcHBvcnR1bml0eSwgaXQgbWF5IGJlIGEgd2F5IGZvciBhIGNv dW50cnkgDQo+IHdpdGggYSBodWdlIHBvcHVsYXRpb24gdG8gZG8gdGhpbmdzIGl0IGNhbm5vdCBk byBub3cuIEkgdGhpbmsgaWYgaXQgaXMgDQo+IHVuZGVyIHRoZSBkYXRhYmFzZSwgYW5kIGl0IGlz IHNvbWV0aGluZyB0aGF0IHRoZSByZWdzIGluIENoaW5hIHdpbGwgDQo+IGFzayBmb3IsIHdoeSBu b3QgbGlzdGVuIHRvIGEgcHJlc2VudGF0aW9uIHdpdGggYW4gb3BlbiBtaW5kLg0KPiBNYXliZSBv bmUgZGF0YWJhc2Ugd2lsbCBiZSBmb3Igb25lIHNldCBvZiBjaXJjdW1zdGFuY2VzLCBhbm90aGVy IGZvciANCj4gb2ZmbG9hZGluZywgd2hlbiBuZWVkZWQ/IG9yIE9uZSB3aWxsIGJlIGRlZGljYXRl ZCB0byBtb3JlIHRoYW4gV1NEIGFuZCANCj4gaGF2ZSBzb21lIHByb3ByaWV0YXJ5IHRoaW5ncyBv biBpdCwgdGhlIG90aGVyIHdpbGwgbm90PyBJIG15c2VsZiB3b3VsZCANCj4gbGlrZSB0byBsZWFy biBtb3JlIG9mIHRoZSB0aG91Z2h0cyBvZiBoYXZpbmcgd2hhdCBaaHUgTGVpIGlzIA0KPiBwcmVz ZW50aW5nLCBhbmQgeW91IHdpbGwgYmUgYWJsZSB0byBhc2sgcXVlc3Rpb25zLCBtYXliZSB0aGVy ZSB3aWxsIGJlIA0KPiBhIHNsaWRlIGRlY2sgZm9yIGV4YW1wbGVzIG9mIGhvdyBoZXIgY291bnRy eSBpcyB0aGlua2luZy4NCj4gDQo+IEtub3dsZWRnZSBpcyBhIGdvb2QgdGhpbmehrWxldCdzIGdp dmUgaXQgYSBjaGFuY2UgdG8gYmUgaGVhcmQgdW5kZXIgdGhlIA0KPiBzY29wZSBvZiBEQi4NCj4g DQo+IE15IDIgY2VudHMuDQo+IA0KPiBOYW5jeQ0KPiANCj4gDQo+IE9uIE1hciAxMywgMjAxMiwg YXQgNzoyMCBQTSwgUGF1bCBMYW1iZXJ0IHdyb3RlOg0KPiANCj4gDQo+IA0KPiANCj4gCT5UaGlz IGlzIGEgcHJvcG9zYWwgZGVmaW5pbmcgYSBwcm90b2NvbCBiZXR3ZWVuIFdTRCBhbmQgV1NEQiwg c28gSQ0KPiBiZWxpZXZlIAk+aXQgaXMgaW4gc2NvcGUuIFBlcmhhcHMgaWYgd2Ugd2FudGVkIHRv IHByb3ZpZGUgY29uc3RydWN0aXZlDQo+IGZlZWRiYWNrIHRvIHRoZSAJPmF1dGhvcnMgd2UgY291 bGQgc3VnZ2VzdCByZXZpc2luZyB0aGUgdGVybWlub2xvZ3kgb2YNCj4gdGhlaXIgZHJhZnQuDQo+ IA0KPiAJVGhlIKGwY29vcmRpbmF0aW5nIGRhdGFiYXNlobEgaXMgbmVpdGhlciBhIFdTRCBvciBh IFdTREIuICBUaGUgDQo+IGNvbnN0cnVjdGl2ZSBjcml0aWNpc20gaXMgdGhhdCB0aGlzIGNvbmNl cHQgaXM6IG91dC1vZi1zY29wZSAoSU1PKSwgDQo+IHVubmVjZXNzYXJ5IGFuZCBzaG91bGQgYmUg ZnVsbHkgcmVtb3ZlZCBmcm9tIHRoZSBkcmFmdCBhbmQgZnVydGhlciANCj4gZGlzY3Vzc2lvbnMg b24gdGhpcyBsaXN0Lg0KPiANCj4gCVBhdWwNCj4gDQo+IA0KPiAJUGF1bCBBLiBMYW1iZXJ0IHwg TWFydmVsbCBTZW1pY29uZHVjdG9yIHwgKzEtNjUwLTc4Ny05MTQxDQo+IA0KPiAJRnJvbTogcGF3 cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgDQo+IE9mIFp1bmlnYSwgSnVhbiBDYXJsb3MNCj4gCVNlbnQ6IFR1ZXNkYXksIE1hcmNoIDEz LCAyMDEyIDY6NDMgUE0NCj4gCVRvOiBwYXdzQGlldGYub3JnDQo+IAlTdWJqZWN0OiBSZTogW3Bh d3NdIFRpbWUgdG8gcHJlc2VudCBteSBJRCBpbiBJRVRGIFBhcmlzIG1lZXRpbmcNCj4gDQo+IAlV bmZvcnR1bmF0ZWx5IHdlIGRvbqGvdCBoYXZlIGEgcmVmZXJlbmNlIGFyY2hpdGVjdHVyZSB0byB3 b3JrIHVwb24sIHNvIA0KPiBwZW9wbGUgd2lsbCBtYWtlIHRoZSBwcm9wb3NhbHMgYW5kIGNvbW1l bnRzIGJhc2VkIG9uIHdoYXQgdGhleSANCj4gdW5kZXJzdGFuZC4NCj4gDQo+IAlXZSBoYXZlIGFn cmVlZCBiZWZvcmUgdG8gbGltaXQgdGhlIHRlcm1pbm9sb2d5IHRvIKGwV1NEIDwtPiBXU0RCobEN Cj4gdG8ga2VlcCBpdCBzaW1wbGUuDQo+IA0KPiAJV2Uga25vdyB0aGF0IFdTRCB3aWxsIGJlIGEg ZGV2aWNlIGFuZCBXU0RCIGEgc2VydmVyLWJhc2VkIHNlcnZpY2UgDQo+IHByb3ZpZGVkIGJ5IGEg V1MgU2VydmljZSBQcm92aWRlciAobW9zdCBsaWtlbHkgbm90IHRoZSBSZWd1bGF0b3IpLg0KPiAN Cj4gCVRoaXMgaXMgYSBwcm9wb3NhbCBkZWZpbmluZyBhIHByb3RvY29sIGJldHdlZW4gV1NEIGFu ZCBXU0RCLCBzbyBJIA0KPiBiZWxpZXZlIGl0IGlzIGluIHNjb3BlLiBQZXJoYXBzIGlmIHdlIHdh bnRlZCB0byBwcm92aWRlIGNvbnN0cnVjdGl2ZSANCj4gZmVlZGJhY2sgdG8gdGhlIGF1dGhvcnMg d2UgY291bGQgc3VnZ2VzdCByZXZpc2luZyB0aGUgdGVybWlub2xvZ3kgb2YgDQo+IHRoZWlyIGRy YWZ0Lg0KPiANCj4gCUpjDQo+IA0KPiAJRnJvbTogcGF3cy1ib3VuY2VzQGlldGYub3JnIFttYWls dG86cGF3cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgDQo+IE9mIEJhc2F2YXJhai5QYXRp bEBub2tpYS5jb20NCj4gCVNlbnQ6IFR1ZXNkYXksIE1hcmNoIDEzLCAyMDEyIDI6MDYgUE0NCj4g CVRvOiBHYWJvci5CYWprb0Bub2tpYS5jb207IHBhd3NAaWV0Zi5vcmcNCj4gCVN1YmplY3Q6IFJl OiBbcGF3c10gVGltZSB0byBwcmVzZW50IG15IElEIGluIElFVEYgUGFyaXMgbWVldGluZw0KPiAN Cj4gCT5XaHkgd291bGQgdGhlIGNoYWlycyBtZWRpYXRlIHRoaXMgZGlzY3Vzc2lvbj8NCj4gDQo+ IAlJbiBvcmRlciB0byBlbnN1cmUgd2UgYXJlIG5vdCB3YXN0aW5nIGJhbmR3aWR0aCBvbiB0b3Bp Y3MgdGhhdCBhcmUgDQo+IGNsZWFybHkgb3V0c2lkZSB0aGUgV0cgc2NvcGUuLi4NCj4gCUFuZCBp dCBpcyB5b3VyIHJlc3BvbnNpYmlsaXR5IHRvIG1vZGVyYXRlIHRvIGVuc3VyZSB3ZSBhcmUgbWFr aW5nIA0KPiBmb3J3YXJkIHByb2dyZXNzLi4NCj4gCUFuZCBiZWNhdXNlIHlvdSBnZXQgdG8gd2Vh ciB0aGUgYmx1ZSBkb3QgOykNCj4gDQo+IAlTZW50IGZyb20gbXkgTHVtaWEgODAwDQo+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiANCj4gDQo+IAlGcm9tOiBCYWprbyBH YWJvciAoTm9raWEtQ0lDL1NpbGljb25WYWxsZXkpDQo+IAlTZW50OiAzLzEzLzIwMTIgNjo0MyBQ TQ0KPiAJVG86IHBhd3NAaWV0Zi5vcmcNCj4gCVN1YmplY3Q6IFJlOiBbcGF3c10gVGltZSB0byBw cmVzZW50IG15IElEIGluIElFVEYgUGFyaXMgbWVldGluZw0KPiANCj4gCVdoeSB3b3VsZCB0aGUg Y2hhaXJzIG1lZGlhdGUgdGhpcyBkaXNjdXNzaW9uPyBUaGVyZaGvcyBhbiBpbmRpdmlkdWFsIA0K PiBzdWJtaXNzaW9uIGFuZCB0aGUgYXV0aG9yIGlzIHNlZWtpbmcgY29tbWVudHMgb24gdGhlIGxp c3QgYmVmb3JlIHRoZSANCj4gcHJlc2VudGF0aW9uIGluIHRoZSBmMmYuDQo+IAlUaGF0IGlzIGhv dyBpZXRmIHdvcmtzLCB3ZSBuZWVkIGNvbW1lbnRzIHRvIHRoZSBsaXN0IHRvIG1ha2UgcHJvZ3Jl c3MgDQo+IG9uZSB3YXkgb3IgdGhlIG90aGVyLg0KPiANCj4gCS0gICAgICAgICAgR2Fib3INCj4g DQo+IAlGcm9tOiBwYXdzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwYXdzLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiANCj4gT2YgZXh0IFBhdWwgTGFtYmVydA0KPiAJU2VudDogVHVlc2Rh eSwgTWFyY2ggMTMsIDIwMTIgMjozMiBQTQ0KPiAJVG86IFpodUxlaTsgcGF3c0BpZXRmLm9yZw0K PiAJU3ViamVjdDogUmU6IFtwYXdzXSBUaW1lIHRvIHByZXNlbnQgbXkgSUQgaW4gSUVURiBQYXJp cyBtZWV0aW5nDQo+IA0KPiAJSGkgWmh1LA0KPiANCj4gCT4gSSBhbSBub3Qgc3VyZSB0aGF0IHlv dSB3b3VsZCBzdXBwb3J0IHRoaXMgaWRlYSwgYnV0IHRoZSB0ZXh0IA0KPiBkZXNjcmliaW5nIHRo aXMgY2FuIG1ha2UgdGhpbmdzIGNsZWFyZXIgd2hlbiB0YWxraW5nIGFib3V0IHRoaXMuDQo+IA0K PiAJTm8gSSBkbyBub3Qgc3VwcG9ydCB0aGUgaWRlYSBvZiBhZGRpdGlvbmFsIGxheWVycyBvZiCh sGNvb3JkaW5hdGluZyANCj4gZGF0YWJhc2WhsS4gIEVzcGVjaWFsbHkgZm9yIGRldGFpbGVkIGRl c2lnbnMgdXNpbmcgSFRUUFMuDQo+IA0KPiAJPiBJIHdvdWxkIG5vdCBpbWFnZSBvbmUgZGF0YWJh c2Ugc2VydmluZyBodWdlIG51bWJlciBvZiBNYXN0ZXIgDQo+IGRldmljZXMuIEZvciBzb21lIHJl YXNvbnMsIHJlZ3VsYXRvcg0KPiAJPm1heSBhdXRob3JpemUgYnJhbmNoZXMgdG8gYWRtaW5pc3Ry YXRlIG9yIG1haW50YWluIHdoaXRlIHNwYWNlIGRhdGEgDQo+IGJhc2Ugd2hpY2ggZG9taW5hdGVz IGEgcGFydGljdWxhciByZWdpb24uDQo+IA0KPiAJT3V0LW9mLXNjb3BlIGFuZCBjb21wbGV0ZWx5 IHVubmVjZXNzYXJ5LiAgV2hlbiB5b3UgdXNlIFNTTCB0byBhY2Nlc3MgDQo+IGEgYmFuayBhY2Nv dW50IGRvIHlvdSBjYXJlIHRoYXQgdGhlcmUgbWF5IGJlIG11bHRpcGxlIHNlcnZlcnMNCj4gdGhh dCBsb29rIGxpa2UgYSBzaW5nbGUgZW50aXR5IHRvIHRoZSB1c2VyPyAgIE5ldyBsYXllcnMgb2Yg YWJzdHJhY3Rpb24NCj4gYXJlIG5vdCByZXF1aXJlZCBmb3Igc2NhbGFiaWxpdHkuICBUaGUgc2Ft ZSBwcm90b2NvbCBjYW4gYmUgdXNlZCB0byANCj4gb25lIG9yIG11bHRpcGxlIHNlcnZlcnMuICBZ ZXMsIHNvbWUgY29uc2lkZXJhdGlvbnMgbmVlZCB0byBiZSANCj4gZGlzY3Vzc2VkIGFib3V0IGF1 dGhlbnRpY2F0aW9uLiAgTm8gbmV3IGVudGl0aWVzLCBsYXllcnMsIA0KPiBhcmNoaXRlY3R1cmFs IGJsb2NrcywgY29uY2VwdHMsIGZyYW1ld29ya3Mgb3IgcHJvdG9jb2xzIGFyZSByZXF1aXJlZCAN Cj4gZm9yIKGwc2VydmluZyBhIGh1Z2UgbnVtYmVyIKGtIKGwLg0KPiANCj4gCUkgYWxzbyBzZWUg dGhhdCB3ZSB3YXN0ZSBhIGxvdCBvZiB3b3JkcyBvbiB0aGUgbGlzdCBvbiB0aGlzIHRvcGljIA0K PiB0aGF0IG1heSBiZSBvdXQgb2Ygc2NvcGUgKHVwIHRvIGNoYWlyIHRvIG1lZGlhdGUgoa0pLiAg VGhlIHB1cnBvc2Ugb2YgDQo+IHRoZSByZXF1aXJlbWVudHMgYW5kIHVzZSBjYXNlIHByb2Nlc3Mg aXMgdG8gY3JlYXRlIGNvbnNlbnN1cyBmcm9tIHRoZSANCj4gdG9wIGRvd24gdG8gZmFjaWxpdGF0 ZSB0aGUgY3JlYXRpb24gIG9mIGEgc3BlY2lmaWNhdGlvbiBvZiB0aGUgYmVzdCANCj4gcG9zc2li bGUgZG9jdW1lbnQgZnJvbSB0aGUgd29ya2luZyBncm91cC4gIFdlIHNob3VsZCBpZ25vcmUgYW55 IA0KPiBkaXNjdXNzaW9ucyBhbmQgY29udHJpYnV0aW9ucyBvbiBvdXQtb2Ytc2NvcGUgY29udHJp YnV0aW9ucyBhbmQgZm9jdXMgDQo+IG9uIHRoZSBjdXJyZW50IHNjb3BlIGFuZCB3b3JrIGl0ZW1z Lg0KPiANCj4gCVBhdWwNCj4gDQo+IA0KPiAJUGF1bCBBLiBMYW1iZXJ0IHwgTWFydmVsbCBTZW1p Y29uZHVjdG9yIHwgKzEtNjUwLTc4Ny05MTQxDQo+IA0KPiAJRnJvbTogWmh1TGVpIFttYWlsdG86 bGVpLnpodUBodWF3ZWkuY29tXQ0KPiAJU2VudDogVHVlc2RheSwgTWFyY2ggMTMsIDIwMTIgMTo0 NyBBTQ0KPiAJVG86IFBhdWwgTGFtYmVydDsgcGF3c0BpZXRmLm9yZw0KPiAJU3ViamVjdDogUkU6 IFRpbWUgdG8gcHJlc2VudCBteSBJRCBpbiBJRVRGIFBhcmlzIG1lZXRpbmcNCj4gDQo+IAlIaSBQ YXVsLA0KPiANCj4gCURvIHlvdSBwcmVmZXIgdG8gcmVtb3ZlIHRoaXMgaW50ZXJtZWRpYXJ5IGZ1 bmN0aW9uPyBUaGUgaW50ZW50aW9uIG9mIA0KPiB0aGlzIGRyYWZ0IGlzIHN0aWxsIHRvIHByb3Zp ZGUgYSBwcm9wb3NhbCBvZiBmcmFtZXdvcmsgYW5kIHByb3RvY29sLCANCj4gcHJvYmFibHkgaW5j bHVkaW5nIHdob2xlIHBpY3R1cmUgd2l0aCBlc3NlbnRpYWwgZWxlbWVudHMsIGRpc2NvdmVyeSwg DQo+IHF1ZXJ5LCB1cGRhdGUgZXRjLg0KPiANCj4gCUFzIHdoYXQgaXMgbWVudGlvbmVkIGluIGUt bWFpbCBsaXN0IGFuZCBsYXN0IEYyRiBtZWV0aW5nLCBwb3NzaWJseSwgDQo+IHRoZSBQQVdTIG1p Z2h0IGJlIHZlcnkgZXh0ZW5zaWJsZSBzaW5jZSB0aGUgYmFzaWMgY29uY2VwdHMsIHNjZW5hcmlv cyANCj4gYW5kIHJlcXVpcmVtZW50cyBhcmUgZXN0YWJsaXNoZWQgdXBvbiB0aGUgRkNDIGFuZCBv dGhlciByZWd1bGF0b3Jzoa8NCj4gcHJvY2VzcyBvZiB3aGl0ZSBzcGFjZS4gV2Ugc3RpbGwgaGF2 ZSBzb21lIHBvdGVudGlhbCBuZWVkcyBkb2luZyANCj4gZnVydGhlciBhdCBmZWF0dXJlIGxldmVs IG9yIGV2ZW4gYXJjaGl0ZWN0dXJlIGxldmVsLiBBdCBsZWFzdCwgdGhlIA0KPiBkZXNpZ24gb2Yg dGhpcyBwcm90b2NvbCBzaG91bGQgbWFrZSBzdXJlIHRoaXMgbmVlZC4gRnJvbSB0aGlzIA0KPiBw ZXJzcGVjdGl2ZSwgYXV0aGVudGljYXRpb24gYW5kIGNvbnRlbnQgcHJvdGVjdGlvbiBtaWdodCBi ZSBjb25zaWRlcmVkIA0KPiBmdXJ0aGVyLCBob3BlZnVsbHksIHdlIGFyZSBhYmxlIHRvIGRpc2N1 c3Mgc2VjdXJpdHkgaW4gUGFyaXMuDQo+IA0KPiAJV2UgYWxzbyByZWFsbHkgbWV0IHZhcnkgc2l0 dWF0aW9ucyBvZiBkaWZmZXJlbnQgYXJlYXMgYW5kIHJlZ2lvbnMgd2hvIA0KPiBkb21pbmF0ZSBh IHF1aXRlIG51bWJlciBvZiBNYXN0ZXIgZGV2aWNlcy4gSSB3b3VsZCBub3QgaW1hZ2Ugb25lIA0K PiBkYXRhYmFzZSBzZXJ2aW5nIGh1Z2UgbnVtYmVyIG9mIE1hc3RlciBkZXZpY2VzLiBGb3Igc29t ZSByZWFzb25zLCANCj4gcmVndWxhdG9yIG1heSBhdXRob3JpemUgYnJhbmNoZXMgdG8gYWRtaW5p c3RyYXRlIG9yIG1haW50YWluIHdoaXRlIA0KPiBzcGFjZSBkYXRhIGJhc2Ugd2hpY2ggZG9taW5h dGVzIGEgcGFydGljdWxhciByZWdpb24uIEkgZG8gbm90IHRoaW5rIA0KPiB0aGUgbXVsdGlwbGUg ZGF0YSBiYXNlcyBvciBkaXN0cmlidXRlZCBkYXRhIG1vZGVsIGZyYW1ld29yayBhcmUgDQo+IGNv bnRyb3ZlcnNpYWwgdG8gdXMsIGJ1dCB0aGUgYWRkaXRpb25hbCBmdW5jdGlvbnMgb2YgdGhpcyBj b29yZGluYXRpbmcgDQo+IGRhdGEgYmFzZS4gVGhpcyBpbnRlcm1lZGlhdGUgbm9kZSB3aXRoIHdo aXRlIHNwYWNlIHNwZWN0cnVtIGRlY2lzaW9uIA0KPiBtYWtpbmcgZnVuY3Rpb24gaXMgdGhlIGlz c3VlIG9mIGV4dGVuc2liaWxpdHksIHdoaWNoIGNhbiBiZSBoZWxwZnVsIA0KPiB3aGVuIGFkZGlu ZyBzb21lIGZlYXR1cmUgd2hpY2ggaXMgbm90IGRlc2lyZWQgdG8gbWFpbiBkYXRhIGJhc2UuDQo+ IERlY2lzaW9uIG1ha2luZyBmdW5jdGlvbiBjb3VsZCBiZSBub3QgYSBmdW5jdGlvbmFsaXR5IG9m IG1haW4gZGF0YSANCj4gYmFzZSB3aGljaCBuZWVkcyB0byBiZSB2ZXJ5IHN0YWJsZSBhbmQgc3Rh dGljLiBJZiB3ZSByZWFsbHkgZXh0ZW50IA0KPiBjb2V4aXN0ZW5jZSBvciBpbnRlcmZlcmVuY2Ug YXZvaWRhbmNlIHJvbGUgdG8gUEFXUyBwcm90b2NvbCwgaXQgd291bGQgDQo+IGJlIGVhc2llciB0 byBleHRlbnQgaW50ZXJtZWRpYXJ5IGZ1bmN0aW9uIHdpdGhvdXQgaW1wYWN0cyBvbiBmcmFtZXdv cmsgDQo+IG9mIFBBV1MsIGFuZCwgc3RydWN0dXJlIGFuZCBwcm90b2NvbCBvZiBQQVdTLiBUaGlz IG5vZGUgaXMgYmVsaWV2ZWQgdG8gDQo+IGV4aXN0IGZvciB0aGlzIHB1cnBvc2UuDQo+IA0KPiAJ SSBhbSBub3Qgc3VyZSB0aGF0IHlvdSB3b3VsZCBzdXBwb3J0IHRoaXMgaWRlYSwgYnV0IHRoZSB0 ZXh0IA0KPiBkZXNjcmliaW5nIHRoaXMgY2FuIG1ha2UgdGhpbmdzIGNsZWFyZXIgd2hlbiB0YWxr aW5nIGFib3V0IHRoaXMuDQo+IA0KPiAJQmVzdCByZWdhcmRzLA0KPiAJWmh1IExlaQ0KPiANCj4g DQo+IAm3orz+yMs6IFBhdWwgTGFtYmVydCBbbWFpbHRvOnBhdWxAbWFydmVsbC5jb21dDQo+IAm3 osvNyrG85DogMjAxMsTqM9TCMTPI1SAxNToyOA0KPiAJytW8/sjLOiBaaHVMZWk7IHBhd3NAaWV0 Zi5vcmcNCj4gCdb3zOI6IFJFOiBUaW1lIHRvIHByZXNlbnQgbXkgSUQgaW4gSUVURiBQYXJpcyBt ZWV0aW5nDQo+IA0KPiANCj4gCURpZCBvdXIgY29uc2Vuc3VzIHByb2Nlc3MgaW5jbHVkZSBhIGNv b3JkaW5hdGluZyBpbnRlcm1lZGlhcnkgZnVuY3Rpb24/DQo+IA0KPiAJICAgVGhlIGNvb3JkaW5h dGluZyBkYXRhYmFzZSBjYW4gZ2V0IHdoaXRlIHNwYWNlIGNoYW5uZWxzIGZyb20NCj4gZGF0YWJh c2UsIAkgICByZWNlaXZlIHRoZSB3aGl0ZSBzcGFjZSBxdWVyeWluZyBtZXNzYWdlIGZyb20gbWFz dGVyDQo+IGRldmljZSBhbmQgCSAgIHByb3ZpZGUgdGhlIGF2YWlsYWJsZSB3aGl0ZSBzcGFjZSBj aGFubmVscyBmb3IgbWFzdGVyDQo+IGRldmljZXMgd2l0aCAJICAgc29tZSBkZWdyZWUgZGVjaXNp b24gbWFraW5nIHByb2Nlc3MuICBUaGVzZSBkZWNpc2lvbg0KPiBtYWtpbmcgcHJvY2VzcyAJICAg bWlnaHQgcHJvdmlkZSBmdW5jdGlvbmFsaXR5IG9mIHdoaXRlIHNwYWNlIGFjY2Vzcw0KPiBwcm90 b2NvbCBwb3dlciB0byAJICAgcmVzcG9uc2UgYXZhaWxhYmxlIGNoYW5uZWxzIGFjY29yZGluZyB0 byByZWNlaXZlZA0KPiBkZXZpY2UgcGFyYW1ldGVycyAJICAgKGUuZy4gcG93ZXIsIFJGIHBhcmFt ZXRlciksIGxvY2F0aW9uDQo+IGluZm9ybWF0aW9uKGUuZy4gYWx0aXR1ZGUsIAkgICBwb3NpdGlv biBhbmQgZGlyZWN0aW9uIG9mIGFudGVubmEgKSBhbmQNCj4gc29tZSBwYXJ0aWN1bGFyIHdoaXRl IHNwYWNlIAkgICBzcGVjdHJ1bSBkZWNpc2lvbiBtYWtpbmcgcG9saWNpZXMuDQo+IA0KPiAJRG9u oa90IHNlZSB0aGF0IHRoaXMgaXMgaW4gc2NvcGUuIFNlZW1zIGluYXBwcm9wcmlhdGUgdG8gY3Jl YXRlIA0KPiBjb21wbGV0ZSBJRHMgd2l0aCBmZWF0dXJlcyB0aGF0IGFyZSBvdXQtb2Ytc2NvcGUu DQo+IA0KPiAJUGF1bA0KPiANCj4gDQo+IAlGcm9tOiBwYXdzLWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiANCj4gT2YgWmh1TGVpDQo+IAlT ZW50OiBUdWVzZGF5LCBNYXJjaCAxMywgMjAxMiAxMjowMiBBTQ0KPiAJVG86IHBhd3NAaWV0Zi5v cmcNCj4gCVN1YmplY3Q6IFtwYXdzXSBUaW1lIHRvIHByZXNlbnQgbXkgSUQgaW4gSUVURiBQYXJp cyBtZWV0aW5nDQo+IA0KPiAJSGkgRm9sa3MgYW5kIGNoYWlycywNCj4gDQo+IAlBcyB3aGF0IHlv dSBtaWdodCBub3RpY2UsIEkgdXBsb2FkZWQgYSBJRCBvbiBQQVdTIGZyYW1ld29yayBhbmQgDQo+ IHByb3RvY29sIHdoaWNoIGlzIHRvIGZ1bGZpbGwgUEFXUyByZXF1aXJlbWVudHMgYW5kIHJlZ3Vs YXRvcnOhrw0KPiByZXF1aXJlbWVudHMsIKGwd3d3LmlldGYub3JnL2lkL2RyYWZ0LWxlaS1wYXdz LWZyYW1ld29yay1kYXRhbW9kZWwtDQo+IDAwLnR4dKGxLiAgSSB3b3VsZCB2ZXJ5IGxpa2UgdG8g cmVxdWVzdCAyNSBtaW51dGVzIHByZXNlbnRpbmcgYW5kIA0KPiBkaXNjdXNzaW5nIGl0IGR1cmlu ZyBJRVRGIFBhcmlzIG1lZXRpbmcuDQo+IA0KPiAJQmVzdCByZWdhcmRzLA0KPiAJWmh1IExlaQ0K PiAJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gCXBh d3MgbWFpbGluZyBsaXN0DQo+IAlwYXdzQGlldGYub3JnDQo+IAlodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4gDQo+DQoNCg0KDQo= From paul@marvell.com Fri Mar 9 16:01:42 2012 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 1D2BF21F85FF for ; Fri, 9 Mar 2012 16:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.087 X-Spam-Level: X-Spam-Status: No, score=-3.087 tagged_above=-999 required=5 tests=[AWL=-3.115, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, 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 g4vSDDXNJfzt for ; Fri, 9 Mar 2012 16:01:39 -0800 (PST) Received: from psmtp.com (na3sys009aog135.obsmtp.com [74.125.149.84]) by ietfa.amsl.com (Postfix) with ESMTP id A1FF721F8565 for ; Fri, 9 Mar 2012 16:01:36 -0800 (PST) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob135.postini.com ([74.125.148.12]) with SMTP ID DSNKT1qZy3mW10CPG8d6hKoan+7jRWCsQEit@postini.com; Fri, 09 Mar 2012 16:01:38 PST Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Fri, 9 Mar 2012 15:58:55 -0800 From: Paul Lambert To: "Joel M. Halpern" , "chris.cheeseman@bt.com" Date: Fri, 9 Mar 2012 15:58:54 -0800 Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting Thread-Index: Acz+Da5aXfr6bZS8Q0SNpa6oBU7ISQAQiQpA Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D0157A034D48@SC-VEXCH2.marvell.com> References: , <7BAC95F5A7E67643AAFB2C31BEE662D0157A034B37@SC-VEXCH2.marvell.com> <4F5A28F7.4070905@joelhalpern.com> In-Reply-To: <4F5A28F7.4070905@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 19 Mar 2012 08:01:14 -0700 Cc: "Reza.Karimi@ofcom.org.uk" , "paws@ietf.org" , "johnny.dixon@bt.com" , "presnick@qualcomm.com" Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting 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, 10 Mar 2012 00:01:42 -0000 +1 to all of Joels comments Why would a third ack message ever be different from the original request? There's been no time to connect clients or make any other interesting choic= es that would change the way the spectrum would be used. The ack is a usel= ess message and any such informative information about the capabilities or = plans of a device to use a range of spectrum should have been carried in th= e first message. Paul >-----Original Message----- >From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >Sent: Friday, March 09, 2012 8:00 AM >To: chris.cheeseman@bt.com >Cc: Paul Lambert; sdas@appcomsci.com; SiewYoon.Tan@ofcom.org.uk; >JuanCarlos.Zuniga@InterDigital.com; Basavaraj.Patil@nokia.com; >gerald.chouinard@sympatico.ca; scott.probasco@nokia.com; paws@ietf.org; >presnick@qualcomm.com; Reza.Karimi@ofcom.org.uk; johnny.dixon@bt.com >Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >rqmts-03:channel reporting > >I am having trouble connecting the goal of the requirement, the expected >protocol behavior, and the expected real-world operation. > >Lets keep it simple. A master, connected by wired internet to the >World. A set of slaves who want to use whitespace to talk to the >master. All within a small physical space. All within the the time >limit of whatever answer the master gets from the database. > >The Ofcom requirement is described as being important for understanding >interference effects. Therefore, presumably, it needs to relate to >actual spectrum usage. > >The stated protocol behavior is that the master would reply to the >shitespace database with an ack indicating what it expects to use, at >what power level. >The way folks are writing this, I believe the intention is "respond >once". > >As I understand such master / slave behavior (and I am by no means a >radio expert), the actual usage of spectrum, within the whitespace band, >will depend upon how many slaves are active, and possibly on what they >are doing. > >If the actual usage is going to depend upon the slave device population >/ behavior, then the only answer the master can correctly provide is "I >will use all of the whitespace you have identified, with the highest >power I might use. > >Such an answer is a valid answer in terms of protocol and in terms of >the stated regulatory requirements. However, it is utterly useless in >terms of the stated goal. >As an engineer, I am very uncomfortable designing a protocol messaging >exchange which I know will not meet the end-users needs. > >Note1: If I have mischaracterized ro misunderstood what folks ahve >explained, I apologize. > >Note2: If instead the intention is for the master to update the database >every time it changes the spectrum usage pattern, then this is NOT an >acknowledgment of the reply from the database. It is a dynamic behavior >reporting requirement. > >Yours, >Joel > >On 3/9/2012 6:36 AM, chris.cheeseman@bt.com wrote: >> Hi >> >> My reading of the UK regulatory requirements that Ofcom has made >available is that the Acknowledgement message that must be communicated >back to the database from the white space device is simply the frequency >range (or ranges) and maximum eirp density that the device intends to >use (a subset of what it would have been offered by the database). I >don't believe there is any intent to limit modulation schemes etc. as >part of this exchange. This seems a relatively straightforward >requirement and the PAWS protocol should accommodate this if it is to be >relevant for the UK regulatory environment. >> >> Regards, >> >> Chris >> >> -----Original Message----- >> From: Paul Lambert [mailto:paul@marvell.com] >> Sent: 09 March 2012 02:15 >> To: Das, Subir; 'Siew Yoon Tan'; Zuniga, Juan Carlos; >Basavaraj.Patil@nokia.com; gerald.chouinard@sympatico.ca; >jmh@joelhalpern.com; scott.probasco@nokia.com >> Cc: paws@ietf.org; presnick@qualcomm.com; Reza Karimi; >Dixon,JS,Johnny,COD R; Cheeseman,CJ,Chris,COD R >> Subject: RE: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >rqmts-03:channel reporting >> >> >> >> >> >> >>> I have a question here. Is it really an acknowledgement or we would >>> like to see a kind of notification message that includes channel, and >>> other parameters? >> >> What if it's multiple channels? What happens if the device adapts and >changes between modulation technique or bandwidth? Does every change >over the air need to be indicated to the GDB? >> >> This Channel acknowledgement does not seem useful and would limit real >world behaviors (like channel and modulation adaptation). >> >> If viewed as a potential regulatory requirement - does this imply we >need to parameterize the protocol to have different behaviors in >different regions? >> >> Paul >> >> >> >>> >>> Regards, >>> _Subir >>> >>> -----Original Message----- >>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >Of >>> Siew Yoon Tan >>> Sent: Thursday, March 08, 2012 4:06 PM >>> To: Zuniga, Juan Carlos; Basavaraj.Patil@nokia.com; >>> gerald.chouinard@sympatico.ca; jmh@joelhalpern.com; >>> scott.probasco@nokia.com >>> Cc: paws@ietf.org; presnick@qualcomm.com; Reza Karimi; >>> johnny.dixon@bt.com; chris.cheeseman@bt.com >>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >>> rqmts-03:channel reporting >>> >>> Dear All, >>> >>> Regarding Ofcom's requirement to have a return channel as part of the >>> protocol between the WSD and WSDB, I would like to confirm to >following >>> sequence of messaging >>> >>> Channel request >>> Channel response >>> Channel acknowledgement >>> >>> which was raised in an earlier email to this list. >>> >>> Our view is that it would be beneficial to define the protocol >between >>> WSD and WSDB that supports this requirement even though how the >>> information could be used is still subject to discussion in the UK. >>> >>> >>> Best regards, >>> >>> Siew Yoon >>> >>> >>> ________________________________________ >>> From: paws-bounces@ietf.org [paws-bounces@ietf.org] on behalf of >>> Zuniga, Juan Carlos [JuanCarlos.Zuniga@InterDigital.com] >>> Sent: 08 March 2012 20:41 >>> To: Basavaraj.Patil@nokia.com; gerald.chouinard@sympatico.ca; >>> jmh@joelhalpern.com; scott.probasco@nokia.com >>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>> chris.cheeseman@bt.com >>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- >usecases- >>> rqmts-03:channel reporting >>> >>> Hi Raj, >>> >>> I was reusing the language used from Gerald (which I know is familiar >>> to people working on IEEE 802 WS groups): >>> >>>>> [GC] You got it. This would be useless for spectrum regulators. >One >>>>> should realize that, from the spectrum regulator's point of view, >>>>> the second and third messages could be iterated upon to optimize >the >>>>> spectrum use. >>>>> Knowing >>>>> what channels the systems in an area are using, the spectrum >>>>> regulators and/or other entities such as those taking care of >>>>> coexistence could use the database in near-real-time to iterate on >>>>> the two last messages to reduce the range of channels that some >>>>> systems may use once they know precisely what channels are being >>>>> used in the area. The PAWS protocol would carry the information >back >>>>> and forth but would not be involved in such spectrum use >optimization. >>> >>> Having said that, I have no issue sticking to the WSDB terminology. I >>> like keeping things simple :) >>> >>> JC >>> >>>> -----Original Message----- >>>> From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] >>>> Sent: Thursday, March 08, 2012 3:33 PM >>>> To: Zuniga, Juan Carlos; gerald.chouinard@sympatico.ca; >>>> jmh@joelhalpern.com; scott.probasco@nokia.com >>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>>> chris.cheeseman@bt.com >>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >>>> rqmts-03:channel reporting >>>> >>>> >>>> Hi JC, >>>> >>>> Where/why did the coexistence manager come into the picture? Your >>>> comment about "communicating back to the WSDB/coexistence manager" >>>> may result in further misunderstanding. If we simply stick to to >WSDB >>>> I think we are okay. >>>> >>>> -Raj >>>> >>>> On 3/8/12 2:25 PM, "ext Zuniga, Juan Carlos" >>>> wrote: >>>> >>>>> So, from Gerald and Andy's comments, it seems like from the point >of >>>> view >>>>> of (at least) two regulatory entities it is important for the >>>>> protocol >>>> to >>>>> allow communicating back to the WSDB/coexistence manager the actual >>>>> channel usage after the first query is made. >>>>> >>>>> This is to me a very clear requirement. >>>>> >>>>> The actual messages/IEs that would carry this information should be >>>>> discussed as part of the solution document, and not the >requirements. >>>>> >>>>> JC >>>>> >>>>>> -----Original Message----- >>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >>>>>> Behalf >>>> Of >>>>>> Gerald Chouinard >>>>>> Sent: Thursday, March 08, 2012 1:59 PM >>>>>> To: 'Joel M. Halpern'; scott.probasco@nokia.com >>>>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>>>>> chris.cheeseman@bt.com >>>>>> Subject: Re: [paws] WGLC for >>>>>> draft-ietf-paws-problem-stmt-usecases- >>>>>> rqmts-03:channel reporting >>>>>> >>>>>> Joel, Scott, >>>>>> >>>>>> Interesting discussion! See my comments in line below. >>>>>> >>>>>> Gerald >>>>>> >>>>>> -----Original Message----- >>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >>>>>> Behalf >>>> Of >>>>>> Joel >>>>>> M. Halpern >>>>>> Sent: Thursday, 08 March, 2012 13:17 >>>>>> To: scott.probasco@nokia.com >>>>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>>>>> chris.cheeseman@bt.com >>>>>> Subject: Re: [paws] WGLC for >>>>>> draft-ietf-paws-problem-stmt-usecases- >>>>>> rqmts-03: >>>>>> channel reporting >>>>>> >>>>>> So why won't the device simply say "I will use all of this?" >>>>>> [GC] This would defeat the purpose of the acknowledgement message. >>>>>> After all, that way it needs to do less work with the database. >>>>>> And >>>> it >>>>>> can change frequencies when it wants. >>>>>> Given that the stated goal of the Ofcom requriement was to be able >>>> to >>>>>> analyze interference effects, it seems that this will not actually >>>> lead >>>>>> to them getting what they want, even if it does comply with the >>>>>> regulations. >>>>>> [GC] You got it. This would be useless for spectrum regulators. >>>>>> One should realize that, from the spectrum regulator's point of >>>>>> view, the >>>> second >>>>>> and >>>>>> third messages could be iterated upon to optimize the spectrum >use. >>>>>> Knowing >>>>>> what channels the systems in an area are using, the spectrum >>>> regulators >>>>>> and/or other entities such as those taking care of coexistence >>>>>> could use the database in near-real-time to iterate on the two >>>>>> last messages to reduce the range of channels that some systems >>>>>> may use once they know precisely what channels are being used in >the area. >>>>>> The PAWS protocol would carry >>>> the >>>>>> information back and forth but would not be involved in such >>>> spectrum >>>>>> use >>>>>> optimization. >>>>>> >>>>>> Yours, >>>>>> joel >>>>>> >>>>>> On 3/8/2012 1:09 PM, scott.probasco@nokia.com wrote: >>>>>>> Hi Peter, >>>>>>> >>>>>>> Answers below. >>>>>>> >>>>>>> Kind Regards, >>>>>>> Scott >>>>>>> >>>>>>> On 3/8/12 11:39 AM, "ext Peter Saint-Andre" >>>>>> wrote: >>>>>>> >>>>>>>> Hi Scott, I have two clarifying questions: >>>>>>>> >>>>>>>> 1. Does the device know, when it receives the channel response, >>>>>> which >>>>>>>> channel it will actually use? >>>>>>> Scott->This is all new and I am not aware of any existing >>>>>> implementations. >>>>>>> I would argue that the device must decide what channel(s) it >>>>>>> will >>>> use >>>>>> when >>>>>>> it receives the channel response. >>>>>> [GC] Agree with Scott but this is only a portion of the >>>> considerations. >>>>>> If a >>>>>> device was to operate on its own, this would be true but a >>>>>> communication device usually implies at least 2 devices to >>>>>> communicate. Hence, the choice of the channel to be used will need >>>>>> to be negotiated between the two devices before a choice can be >>>>>> made. The chosen channel will belong to the >>>> set >>>>>> of >>>>>> available channels that is common to both devices. Remember that >>>> some >>>>>> channels may be available at one device and not at the other >>>>>> because >>>> of >>>>>> their geolocation or other reason. Extending this concept to a >>>>>> star network topology, the channel that will be selected by this >>>>>> network will >>>> have >>>>>> to >>>>>> belong to the set of channels that are available to all devices. >>>> Each >>>>>> device >>>>>> will not be able to decide by itself which channel it wants to >use. >>>>>> >>>>>> This is why in such a star topology, it makes sense that the slave >>>>>> devices to a base station or access point be represented by the >>>>>> base station acting as the master on their behalf to query the >>>>>> database and receive the list of available channels (and/or >>>>>> maximum EIRP per channel). It is then the responsibility of the >>>>>> base station to identify the set of available channels that is >>>>>> common for itself and all its slaves to decide on the >>>> channel >>>>>> that >>>>>> the network will use. As you can see, in this case, there is no >>>>>> need for each slave to receive its list of available channels. On >>>>>> its own, it would not know what to do with it. The only thing that >>>>>> needs to be sent >>>> from >>>>>> the >>>>>> master device to its slaves is the resulting operating channel. >>>>>> >>>>>> I a more sophisticated operation, the master device may add one or >>>>>> a few backup channels extracted from the common set of available >>>>>> channel >>>> to >>>>>> the >>>>>> message going to its slave so that if a change in channel >>>> availability >>>>>> occurs, an instantaneous switch to the next backup channel can be >>>> made >>>>>> without any further signaling, thus providing for a channel switch >>>> that >>>>>> is >>>>>> transparent to the user. It is the scheme that has been included >>>>>> in >>>> the >>>>>> IEEE >>>>>> 802.22-2011 Standard. This is why I don't believe that PAWS should >>>> get >>>>>> involved in defining this signaling between the base station and >>>>>> its slaves devices. >>>>>>>> >>>>>>>> 2. If the device then uses another channel or a different >>>> channel, >>>>>> does >>>>>>>> it need to report that change to the database? >>>>>>> Scott->My interpretation of section 3.18 is that the device can >>>> only >>>>>>> transmit within the upper& lower frequencies returned in the >>>>>>> acknowledgment. I do not (quickly) find any reference in the >>>>>> requirements >>>>>>> to changing channels. Thus operationally it could be that the >>>> channel >>>>>>> request process must be repeated before the device can use a >>>>>> different >>>>>>> channel (frequencies). >>>>>> [GC] If the process involves 2 messages, then, the device and its >>>>>> associated devices could change channels at will as long as all >>>>>> these channels belong to the set of available channel. However, if >>>>>> the third message is added, it would make sense that the master >>>>>> device reports to the database any channel change that would occur >>>>>> to the database, otherwise, the status of >>>> the >>>>>> spectrum occupation would be wrong at any moment and would be >>>> useless >>>>>> for >>>>>> the purpose of any spectrum usage optimization such as >coexistence. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> Peter >>>>>>>> >>>>>>>> On 3/8/12 10:17 AM, scott.probasco@nokia.com wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> The point from Brian is very relevant: >>>>>>>>> >>>>>>>>> Channel request >>>>>>>>> Channel response >>>>>>>>> Channel acknowledgement >>>>>>>>> >>>>>>>>> What Ofcom does with the information in the acknowledgement >>>>>>>>> does >>>>>> not >>>>>>>>> matter. As the regulator in UK, they write rules that must be >>>>>> followed >>>>>>>>> in >>>>>>>>> order to operate a whitespace radio in the UK. I believe the >>>> scope >>>>>> of >>>>>>>>> the >>>>>>>>> WG must be focused on a working solution. If this is simple >>>> channel >>>>>>>>> request& response in one regulator's domain, PAWS can support >>>>>> this. If >>>>>>>>> it >>>>>>>>> means a channel request, response and acknowledgement in >>>>>>>>> another regulator's domain, PAWS can support this. As a >>>>>>>>> participating >>>>>> member of >>>>>>>>> the work group, I believe the scope should be basic working >>>>>> solution, >>>>>>>>> not >>>>>>>>> limited to a specific number of messages. >>>>>>>>> >>>>>>>>> Kind Regards, >>>>>>>>> Scott >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 3/8/12 11:11 AM, "ext Zuniga, Juan Carlos" >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Peter, Nancy, >>>>>>>>>> >>>>>>>>>> I agree should design a protocol with the best of our current >>>>>>>>>> knowledge, and that should be accounting for all the known >>>>>>>>>> regulations at >>>>>> present >>>>>>>>>> time. We should not limit the scope with the purpose of >>>> designing >>>>>> a >>>>>>>>>> protocol 'faster'. Our goal is not only to design a WSDB >>>> protocol. >>>>>> Our >>>>>>>>>> goal is to design a WSDB protocol that is USEFUL to the >>>> community. >>>>>>>>>> >>>>>>>>>> The charter does state that >>>>>>>>>> >>>>>>>>>> "...the group should also reach out to other potential >>>>>>>>>> "customers" for a white space database access method and >>>> consider >>>>>> input >>>>>>>>> >from regulatory entities that are involved in the >>>>>>>>>> specification >>>> of >>>>>> the >>>>>>>>>> rules for secondary use of spectrum in specific radio bands. " >>>>>>>>>> >>>>>>>>>> I think that is exactly what we are doing now. >>>>>>>>>> >>>>>>>>>> Regarding whether the types of requirements belong to #1 or >>>>>>>>>> #2, >>>> I >>>>>>>>>> believe >>>>>>>>>> it is more of #1 type, as the information to be exchanged >>>>>>>>>> would >>>> be >>>>>>>>>> known >>>>>>>>>> after the initial query/response. >>>>>>>>>> >>>>>>>>>> If we know it today, I see no reason why we should not work >>>>>>>>>> on >>>> it >>>>>> in >>>>>>>>>> the >>>>>>>>>> first phase of the work. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Juan Carlos >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] >>>>>>>>>>> On >>>>>> Behalf >>>>>>>>>>> Of >>>>>>>>>>> Peter Saint-Andre >>>>>>>>>>> Sent: Thursday, March 08, 2012 11:59 AM >>>>>>>>>>> To: Nancy Bravin >>>>>>>>>>> Cc: paws@ietf.org; johnny.dixon@bt.com; >>>> chris.cheeseman@bt.com; >>>>>> Pete >>>>>>>>>>> Resnick >>>>>>>>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- >>>>>> usecases- >>>>>>>>>>> rqmts-03: channel reporting >>>>>>>>>>> >>>>>>>>>>> Hi Nancy, >>>>>>>>>>> >>>>>>>>>>> You are absolutely right that different locales will have >>>>>> different >>>>>>>>>>> rules and requirements. We need to understand those, and >>>>>>>>>>> work >>>> to >>>>>>>>>>> address >>>>>>>>>>> them if possible (although we don't necessarily need to >>>> address >>>>>> them >>>>>>>>>>> all >>>>>>>>>>> at the same time). I see several kinds of requirements: >>>>>>>>>>> >>>>>>>>>>> 1. Some requirements might lead to features beyond the >>>>>> query/response >>>>>>>>>>> protocol we've envisioned so far. One example might be real- >>>> time >>>>>>>>>>> reporting about the channels that a device is actually using. >>>> In >>>>>> my >>>>>>>>>>> opinion, it would be best to handle those in the next phase >>>>>>>>>>> of >>>>>> work, >>>>>>>>>>> because as far as I can see they are outside the scope of >>>>>>>>>>> our >>>>>> charter. >>>>>>>>>>> >>>>>>>>>>> 2. Some requirements might be handled through by defining >>>>>> additional >>>>>>>>>>> fields that can be included in the query or response. We >>>>>> definitely >>>>>>>>>>> planned for that when working on the charter with the IESG: >>>>>>>>>>> >>>>>>>>>>> In addition, the particular >>>>>>>>>>> data exchanged between a device and a database might >>>>>>>>>>> depend >>>> on >>>>>> the >>>>>>>>>>> ranges of radio spectrum that are to be used, the >>>> requirements >>>>>> of >>>>>>>>>>> the >>>>>>>>>>> database operators and their governing regulations, and >>>> other >>>>>>>>>>> factors. >>>>>>>>>>> Therefore, the database access method and the >>>> query/response >>>>>> data >>>>>>>>>>> formats that are exchanged using that method need to be >>>>>> designed >>>>>> for >>>>>>>>>>> extensibility rather than being tied to any specific >>>> spectrum, >>>>>>>>>>> country, or phy/mac/air interface. >>>>>>>>>>> >>>>>>>>>>> It's unclear to me right now if the Ofcom requirement fits >>>> into >>>>>> #1 or >>>>>>>>>>> #2, which is why we're having this discussion. :) >>>>>>>>>>> >>>>>>>>>>> Peter >>>>>>>>>>> >>>>>>>>>>> On 3/7/12 8:17 PM, Nancy Bravin wrote: >>>>>>>>>>>> Peter and all, >>>>>>>>>>>> >>>>>>>>>>>> I agree that it is important to revisit now, so that in the >>>>>> future, >>>>>>>>>>>> it will be easy to align things in their proper place. >>>>>>>>>>>> Every >>>>>> country >>>>>>>>>>>> may have different regulations, spectrum, policy and what >>>>>>>>>>>> responsibility is in the domain of the system, and what >>>>>>>>>>>> comes >>>>>> under >>>>>>>>>>>> the PAWS charter is important. Maybe some separation might >>>> be >>>>>>>>>>>> possible, and dividing and clarifying issues now will help >>>>>>>>>>>> in >>>>>> the >>>>>>>>>>>> future. Certainly it seems that the FCC may change some >>>> rules, >>>>>> and >>>>>>>>>>>> we know that Ofcom is not yet finished with their >>>> regulations. >>>>>> Canada >>>>>>>>>>>> has their own, and other countries are working on this as >>>> well. >>>>>> Just >>>>>>>>>>>> a thought...Sharing is a realistic goal...as is off >>>> loading... >>>>>> Or you >>>>>>>>>>>> slim line and every 6 months decide what to incorporate in >>>> the >>>>>>>>>>>> protocol based on new information, new ideas, new >>>>>>>>>>>> innovation >>>> new >>>>>>>>>>>> regulations and maybe spend more time than you could if >>>>>> addressed >>>>>>>>>>>> now. >>>>>>>>>>>> >>>>>>>>>>>> That way you leave the door open and outside of referencing >>>> what >>>>>> is >>>>>>>>>>>> known today, by referencing regulations i.e. Ofcom, FCC, >>>>>> Industry >>>>>>>>>>>> Canada etc as of XX-XX-XXXX date. Out of scope not >>>>>>>>>>>> something >>>> we >>>>>> know >>>>>>>>>>>> enough about to say at this point, In my opinion. >>>>>>>>>>>> >>>>>>>>>>>> My 2 cents.. >>>>>>>>>>>> >>>>>>>>>>>> Sincerely, Nancy >>>>>>>>>>>> >>>>>>>>>>>> On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> As your responsible Area Director (until March 28, when >>>>>>>>>>>>> Pete Resnick will take over from me), I have reviewed this >>>> thread. >>>>>>>>>>>>> >>>>>>>>>>>>> In my opinion (I am happy to be proven wrong), this new >>>>>> requirement >>>>>>>>>>>>> goes beyond what the charter defined as the scope of this >>>>>> working >>>>>>>>>>>>> group, which was to enable a device to discover the white >>>> space >>>>>>>>>>>>> available to it in its current location. Reporting usage >>>> back >>>>>> to >>>>>>>>>>>>> the database is simply not mentioned in the charter. >>>>>>>>>>>>> >>>>>>>>>>>>> Earlier in this thread, Andy Sago wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> There's no language I can find in the charter that >>>> explicitly >>>>>> puts >>>>>>>>>>>>> this out of scope. >>>>>>>>>>>>> >>>>>>>>>>>>> An IETF charter defines what the working group shall work >>>> on. >>>>>> Many >>>>>>>>>>>>> interesting features could be developed here. However, it >>>>>>>>>>>>> is >>>>>> not >>>>>>>>>>>>> the job of the charter to mention explicitly that each of >>>> those >>>>>>>>>>>>> interesting features is out of scope. >>>>>>>>>>>>> >>>>>>>>>>>>> The charter does say: >>>>>>>>>>>>> >>>>>>>>>>>>> Once the device learns of the available white space (e.g., >>>> in a >>>>>> TV >>>>>>>>>>>>> white space implementation, the list of available channels >>>> at >>>>>> that >>>>>>>>>>>>> location), it can then select one of the bands from the >>>>>>>>>>>>> list >>>>>> and >>>>>>>>>>>>> begin to transmit and receive on the selected band. >>>>>>>>>>>>> >>>>>>>>>>>>> This text might have assumed that no further communication >>>> or >>>>>>>>>>>>> authorization was required in order to select one of the >>>> bands >>>>>> from >>>>>>>>>>>>> the list and then transmit/receive. Perhaps that >>>>>>>>>>>>> assumption >>>> was >>>>>>>>>>>>> mistaken. If so, it would be good to have a discussion >>>>>>>>>>>>> about >>>>>> that, >>>>>>>>>>>>> so we can determine if we need to revisit the assumptions >>>>>>>>>>>>> we >>>>>> made >>>>>>>>>>>>> early on. If in fact we made some faulty or limited >>>>>> assumptions, >>>>>>>>>>>>> then let's get that out in the open. >>>>>>>>>>>>> >>>>>>>>>>>>> Peter >>>>>>>>>>>>> >>>>>>>>>>>>> On 3/7/12 9:40 AM, Rosen, Brian wrote: >>>>>>>>>>>>>> I'd also suggest that >>>> our >>>>>>>>>>>>>> charter limitation is really support for sharing of >>>> whitespace >>>>>> by >>>>>>>>>>>>>> whitespace devices. Reporting what you use is not >>>>>>>>>>>>>> sharing, >>>>>> it's >>>>>>>>>>>>>> just data gathering. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The point of excluding sharing was to eliminate the >>>>>> complexities >>>>>>>>>>>>>> of what constituted fairness, and what kinds of >>>> communication >>>>>>>>>>>>>> might be needed between databases, where more than one >>>> could >>>>>>>>>>>>>> supply available whitespace in a band. This doesn't have >>>> any >>>>>> of >>>>>>>>>>>>>> those issues, As long as it's just sending information, I >>>>>> don't >>>>>>>>>>>>>> have a problem. Once the database is supposed to do >>>> anything >>>>>>>>>>>>>> with it that involves changing what spectrum it reports, >>>> then >>>>>> I >>>>>>>>>>>>>> think we cross the line. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Brian >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mar 6, 2012, at 12:28 PM, >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Joel >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Indeed, the regulator has not described the process or >>>>>> provided >>>>>>>>>>>>>>> a flow diagram, so there may be some wrinkles, but we >>>>>>>>>>>>>>> need >>>> to >>>>>>>>>>>>>>> provide for their intent. To answer your question, the >>>>>> channels >>>>>>>>>>>>>>> that the master will use are sent in a separate message >>>>>>>>>>>>>>> (described in P.12 ter), that occurs after the master >>>>>> receives >>>>>>>>>>>>>>> the response to its channel request, but before the >>>>>>>>>>>>>>> master >>>>>> can >>>>>>>>>>>>>>> transmit. At this point, it knows what channels are >>>>>> available, >>>>>>>>>>>>>>> and which one it will use. As far as the slaves are >>>>>> concerned, >>>>>>>>>>>>>>> as they associate, the master will need to gather their >>>>>> details >>>>>>>>>>>>>>> and send further channel usage messages to the database >>>>>>>>>>>>>>> on their behalf. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Andy >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- From: paws-bounces@ietf.org >>>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] On Behalf Of Joel M. >>>> Halpern >>>>>>>>>>>>>>> Sent: 06 March 2012 17:05 To: scott.probasco@nokia.com >>> Cc: >>>>>>>>>>>>>>> paws@ietf.org; Cheeseman,CJ,Chris,COD R; >>>> Dixon,JS,Johnny,COD >>>>>> R >>>>>>>>>>>>>>> Subject: Re: [paws] WGLC for >>>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel >>>>>>>>>>>>>>> reporting >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Ahh. I think I see where the request and my >>>>>>>>>>>>>>> understanding divurge. If the idea here is that the >>>>>>>>>>>>>>> master must provide, >>>> in >>>>>>>>>>>>>>> the request, an indication of what channels it expects >>>>>>>>>>>>>>> to >>>>>> use, >>>>>>>>>>>>>>> I can at least understand that. I will return to >>>> technical >>>>>>>>>>>>>>> concerns in a moment. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> However, when you say "provide channel usage >>>>>>>>>>>>>>> information, >>>> in >>>>>>>>>>>>>>> order to evaluate interference", what that says to me is >>>>>>>>>>>>>>> providing, during operation, information as to what >>>> channels >>>>>>>>>>>>>>> are being used, and at what power levels. That is what >>>> would >>>>>>>>>>>>>>> be needed to analyze actual interference effects. And >>>>>>>>>>>>>>> that >>>> is >>>>>>>>>>>>>>> out of scope as I understand our scope. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I do see a technical difficulty with having the master >>>>>> provide, >>>>>>>>>>>>>>> as part of either registering or requesting spectrum >>>>>>>>>>>>>>> information, what channels it intends to use. It >>>>>>>>>>>>>>> doesn;t >>>>>> know >>>>>>>>>>>>>>> what channels it intends to use. It intends to use some >>>>>> number >>>>>>>>>>>>>>> of available channels. It will figure out which ones >>>>>>>>>>>>>>> when >>>> it >>>>>>>>>>>>>>> is told what is available. How can it send that >>>> information >>>>>> in >>>>>>>>>>>>>>> the request? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> There is a similarity here with device ID. In context >>>>>>>>>>>>>>>> of >>>>>> PAWS >>>>>>>>>>>>>>>> we are not concerned with why a device ID is required >>>>>>>>>>>>>>>> by >>>> a >>>>>>>>>>>>>>>> regulator, we accept it is a requirement from a >>>>>>>>>>>>>>>> regulator >>>>>> and >>>>>>>>>>>>>>>> include it to the protocol. Ofcom identifies in 3.18& >>>> 3.19 >>>>>>>>>>>>>>>> that channel usage information is required and thus we >>>> need >>>>>>>>>>>>>>>> to include this information. Since the master must >>>> provide >>>>>>>>>>>>>>>> this information prior to transmitting, PAWS will not >>>>>>>>>>>>>>>> function in the UK without this information and thus I >>>>>>>>>>>>>>>> believe channel usage information is integral to the >>>> channel >>>>>>>>>>>>>>>> request& response messaging. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Kind Regards, Scott >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 3/6/12 10:30 AM, "ext Joel M. >>>>>>>>>>>>>>>> Halpern" wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I would draw a distinction. Ofcom regulations about >>>>>>>>>>>>>>>>> whitespace requests are very much relevant. Ofcom >>>>>>>>>>>>>>>>> regulations about notification of dynamic behavior >>>> (which >>>>>>>>>>>>>>>>> spectrum is being used) are not in scope as I >>>>>>>>>>>>>>>>> understand the earlier discussions, particularly the >>>>>>>>>>>>>>>>> chartering discussions. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The ofcom requirements are very much relevant to the >>>>>>>>>>>>>>>>>> scope of the PAWS WG. The only other regulatory >>>>>>>>>>>>>>>>>> requirements that we have today is the FCC. Ofcom >>>>>>>>>>>>>>>>>> requirements are a good addition to the set. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -Raj >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 3/6/12 10:03 AM, "ext >>>>>>>>>>>>>>>>>> andy.sago@bt.com" wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hi Joel >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> There's no language I can find in the charter that >>>>>>>>>>>>>>>>>>> explicitly puts this out of scope. On the other >>>>>>>>>>>>>>>>>>> hand, the charter says that the group will "consider >>>>>>>>>>>>>>>>>>> input from regulatory entities", and this is one of >>>>>>>>>>>>>>>>>>> the requirements from Ofcom that they have just >>> published. >>>>>>>>>>>>>>>>>>> The protocol will be worthless for the UK if it >>>>>>>>>>>>>>>>>>> omits some requirements. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Andy >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -----Original Message----- From: Joel M. Halpern >>>>>>>>>>>>>>>>>>> [mailto:jmh@joelhalpern.com] Sent: 06 March 2012 >>>>>>>>>>>>>>>>>>> 15:53 >>>>>>>>>>>>>>>>>>> To: Sago,AJ,Andy,COD R Cc: paws@ietf.org; >>>>>>>>>>>>>>>>>>> Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for >>>>>>>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: >>>> channel >>>>>>>>>>>>>>>>>>> reporting >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> As I understand, the information you are asking for >>>>>>>>>>>>>>>>>>> is explicitly out of scope for the working group. >>>>>>>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >>>>>>>>>>>>>>>>>>>> All >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Comparing the draft with the Ofcom requirements at >>>>>>>>>>>>>>>>>>>> http://www.cept.org/Documents/se- >>>>>>>>>>> 43/4161/SE43(12)Info03_Draft-UK-r >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> egul >>>>>>>>>>>>>>>>>>>> atory-requirements-for-white-space-devices-in-the- >>>> UHF- >>>>>> TV- >>>>>>>>>>> band, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> I believe the WG draft is deficient in the area of reporting >>>>>>>>>>>>>>>>>>>> frequencies and powers actually used by masters and >>>>>>>>>>>>>>>>>>>> slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom >>>>>>>>>>>>>>>>>>>> intends to collect this data to assesses the impact >>>>>>>>>>>>>>>>>>>> of aggregate interference into other services. It >>>>>>>>>>>>>>>>>>>> would also provide usage information (frequency in >>>>>>>>>>>>>>>>>>>> use) that would inform the operation of a kill >>>>>>>>>>>>>>>>>>>> switch capability. I suggest this deficiency can be >>>>>>>>>>>>>>>>>>>> remedied with the following changes: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> New P requirements (probably best placed following >>>>>>>>>>>>>>>>>>>> P.12): >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> P.12bis: The protocol MUST support a channel usage >>>>>>>>>>>>>>>>>>>> message from the slave device to the master device. >>>>>>>>>>>>>>>>>>>> The channel usage message MUST include parameters >>>>>>>>>>>>>>>>>>>> as required by local regulatory requirement. These >>>>>>>>>>>>>>>>>>>> parameters MAY include device ID, manufacturer's >>>>>>>>>>>>>>>>>>>> serial number, channel usage and power level >>>>>>>>>>>>>>>>>>>> information. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> P.12ter: The protocol MUST support a channel usage >>>>>>>>>>>>>>>>>>>> message from the master device to the database. >>>>>>>>>>>>>>>>>>>> The channel usage message MUST include parameters >>>>>>>>>>>>>>>>>>>> as required by local regulatory requirement for the >>>>>>>>>>>>>>>>>>>> master and its associated slaves. These parameters >>>>>>>>>>>>>>>>>>>> MAY include device ID, manufacturer's serial >>>>>>>>>>>>>>>>>>>> number, channel usage and power level information. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> P.12qua: The protocol MUST support a channel usage >>>>>>>>>>>>>>>>>>>> message acknowledgement. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> New O requirements (probably best placed following >>>>>>>>>>>>>>>>>>>> O13): >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> O.13bis: According to local regulatory policy, >>>>>>>>>>>>>>>>>>>> after connecting to a master device's radio network >>>>>>>>>>>>>>>>>>>> a slave device MAY inform the master device of the >>>>>>>>>>>>>>>>>>>> actual channel usage. The slave MUST include >>>>>>>>>>>>>>>>>>>> parameters required by local regulatory policy, e.g. >>>>>>>>>>>>>>>>>>>> device ID, manufacturer's serial number, channel >>>>>>>>>>>>>>>>>>>> usage and power level information. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> O.13ter: According to local regulatory policy, a >>>>>>>>>>>>>>>>>>>> master device MAY inform the database of the actual >>>>>>>>>>>>>>>>>>>> channel usage of the master and its slaves. The >>>>>>>>>>>>>>>>>>>> master MUST include parameters required by local >>>>>>>>>>>>>>>>>>>> regulatory policy, e.g. device ID, manufacturer's >>>>>>>>>>>>>>>>>>>> serial number, channel usage and power level >>>>>>>>>>>>>>>>>>>> information of the master and its slaves. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> New steps could be introduced into one or more use >>>>>>>>>>>>>>>>>>>> cases to cover these Ofcom requirements, e.g. new >>>>>>>>>>>>>>>>>>>> steps 6bis and 9bis in the hotspot use case at >>>>>>>>>>>>>>>>>>>> 4.2.1: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 6bis. Prior to initiating transmission, if required >>>>>>>>>>>>>>>>>>>> by local regulation, the master/AP informs the >>>>>>>>>>>>>>>>>>>> database of the channel and power level it has >>>>>>>>>>>>>>>>>>>> chosen. This is repeated for each slave that >>>>>>>>>>>>>>>>>>>> associated with the master. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 9bis. Prior to initiating transmission, if required >>>>>>>>>>>>>>>>>>>> by local regulation, the slave informs the >>>>>>>>>>>>>>>>>>>> master/AP of the channel and power level it has >>>>>>>>>>>>>>>>>>>> chosen, and the master/AP relays this information >>>>>>>>>>>>>>>>>>>> to the >>> database. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> - end of new text - >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> For information, for those not accessing the url in >>>>>>>>>>>>>>>>>>>> the first paragraph of this email, the full Ofcom >>>>>>>>>>>>>>>>>>>> requirements leading to this new PAWS text are as >>>>>>>>>>>>>>>>>>>> follows: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 3.18 After receiving instructions from a WSDB in >>>>>>>>>>>>>>>>>>>> relation to the maximum permitted EIRPs over the >>>>>>>>>>>>>>>>>>>> DTT channels, and prior to initiating transmissions >>>>>>>>>>>>>>>>>>>> within the UHF TV band, a master WSD must >>>>>>>>>>>>>>>>>>>> communicate to the WSDB the following information: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 3.18.1 The lower and upper frequency boundaries^13 >>>>>>>>>>>>>>>>>>>> of the in-block emissions of the master WSD, and >>>>>>>>>>>>>>>>>>>> those of the in-block emissions of its associated >>>>>>>>>>>>>>>>>>>> slaves. A lower frequency will be specified as (470 >>>>>>>>>>>>>>>>>>>> + 8k + >>>>>>>>>>>>>>>>>>>> 0.2n) MHz, with the corresponding upper frequency >>>>>>>>>>>>>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3?4 k >>> 3?4 >>>>>>>>>>>>>>>>>>>> 39, 0 3?4 n 3?4 39, 1 3?4 m 3?4 40, and n< m. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 3.18.2 The maximum in-block EIRP spectral densities >>>>>>>>>>>>>>>>>>>> (in dBm/(0.2 MHz)) that the master WSD, and its >>>>>>>>>>>>>>>>>>>> associated slaves, actually radiate between each >>>>>>>>>>>>>>>>>>>> reported lower frequency boundary and its >>>>>>>>>>>>>>>>>>>> corresponding upper frequency boundary. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Footnote 13 states: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> The use of upper and lower frequency boundaries >>>>>>>>>>>>>>>>>>>> (defined over a 200 kHz raster) allows a WSDB to >>>>>>>>>>>>>>>>>>>> collect more granular information with regards to >>>>>>>>>>>>>>>>>>>> the usage of the frequency resource by narrowband >>>>>>>>>>>>>>>>>>>> WSD technologies. The upper and lower frequencies >>>>>>>>>>>>>>>>>>>> of a boundary pair do not straddle a DTT channel >>> boundary. >>>>>>>>>>>>>>>>>>>> Note that a WSD may transmit over multiple, >>>>>>>>>>>>>>>>>>>> non-contiguous, whole DTT channels or fractions of >>>>>>>>>>>>>>>>>>>> DTT channels. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 3.19 A master WSD must be able to receive the >>>>>>>>>>>>>>>>>>>> following information^14 from a WSDB: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in the >>>>>>>>>>>>>>>>>>>> context of 3.18, that the reported information on >>>>>>>>>>>>>>>>>>>> the DTT channels and EIRP spectral densities >>>>>>>>>>>>>>>>>>>> actually used by the master and slave WSDs were >>>>>>>>>>>>>>>>>>>> received successfully by the WSDB^18 ]. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Footnote 14 states: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 14 While the communication of some of this >>>>>>>>>>>>>>>>>>>> information from a WSDB to a master WSD is >>>>>>>>>>>>>>>>>>>> optional, master WSDs must be able to receive and >>>>>>>>>>>>>>>>>>>> interpret these. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Footnote 18 states: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 18 This forms part of a handshake protocol and may >>>>>>>>>>>>>>>>>>>> be an area where industry could harmonise without >>>>>>>>>>>>>>>>>>>> the need for an explicit requirement in the >>> regulations. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Andy >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> *From:*paws-bounces@ietf.org >>>>>>>>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] *On Behalf Of >>>>>>>>>>>>>>>>>>>> *Gabor.Bajko@nokia.com *Sent:* 05 March 2012 19:46 >>>>>>>>>>>>>>>>>>>> *To:* paws@ietf.org *Subject:* [paws] WGLC for >>>>>>>>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> The authors of the use cases and requirements draft >>>>>>>>>>>>>>>>>>>> have just posted a new version of the draft and >>>>>>>>>>>>>>>>>>>> indicated that there are no unresolved >>>>>>>>>>>>>>>>>>>> comments/issues they are aware of. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Therefore, I'd like to initiate a WG Last Call for >>>>>>>>>>>>>>>>>>>> comments on >>>>>>>>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-paws >>>>>>>>>>>>>>>>>>>> - >>>>>> problem- >>>>>>>>>>> stmt-u >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> seca >>>>>>>>>>>>>>>>>>>> ses-rqmts-03.txt >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Please review the draft and send your comments to >>>>>>>>>>>>>>>>>>>> the list by March 20th, 2012. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> If you review the draft and have no comments, send >>>>>>>>>>>>>>>>>>>> a note to the list that the draft is good as it is, >>>>>>>>>>>>>>>>>>>> we need these notes as much as we need the actual >>>>>>>>>>>>>>>>>>>> comments. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, Gabor >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> paws mailing list >>>>>>> paws@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>> >>>>>> _______________________________________________ >>>>>> paws mailing list >>>>>> paws@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>> >>>>>> _______________________________________________ >>>>>> paws mailing list >>>>>> paws@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>> _______________________________________________ >>>>> 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 >>> >>> ________________________________ >>> >>> >*********************************************************************** >>> * >>> ****************************************** >>> For more information visit www.ofcom.org.uk >>> >>> This email (and any attachments) is confidential and intended for the >>> use of the addressee only. >>> >>> If you have received this email in error please notify the originator >>> of the message and delete it from your system. >>> >>> This email has been scanned for viruses. However, you open any >>> attachments at your own risk. >>> >>> Any views expressed in this message are those of the individual >sender >>> and do not represent the views or opinions of Ofcom unless expressly >>> stated otherwise. >>> >*********************************************************************** >>> * >>> ****************************************** >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> From brian.rosen@neustar.biz Mon Mar 19 08:17:33 2012 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 83E0D21F87EF for ; Mon, 19 Mar 2012 08:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.861 X-Spam-Level: X-Spam-Status: No, score=-3.861 tagged_above=-999 required=5 tests=[AWL=-1.748, BAYES_20=-0.74, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4, 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 FkbUIeQg6rq8 for ; Mon, 19 Mar 2012 08:17:30 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id A3CDB21F87E5 for ; Mon, 19 Mar 2012 08:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1332170382; x=1647529824; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=gbu2pcFCZ3xUUoHbVqwjH zJAyemq+TTpAhzvitamL6s=; b=ebIpFD8mrp+qJQia2YXOAM0N3L/8+JY7/XRAO EE0OjLRb7NVM7FP8KilzKozaiC1SlW6SicwgvTehKoPBgoTqQ== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.6872002; Mon, 19 Mar 2012 11:19:41 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Mon, 19 Mar 2012 11:17:04 -0400 From: "Rosen, Brian" To: Paul Lambert Date: Mon, 19 Mar 2012 11:17:02 -0400 Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting Thread-Index: Ac0F41bGGP9LGTvARqq2MthLhc0tYA== Message-ID: References: , <7BAC95F5A7E67643AAFB2C31BEE662D0157A034B37@SC-VEXCH2.marvell.com> <4F5A28F7.4070905@joelhalpern.com> <7BAC95F5A7E67643AAFB2C31BEE662D0157A034D48@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D0157A034D48@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: hPqTF1q146pLMvSUQ6jGYg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Reza.Karimi@ofcom.org.uk" , "paws@ietf.org" , "johnny.dixon@bt.com" , "presnick@qualcomm.com" Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting 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, 19 Mar 2012 15:17:33 -0000 Remembering that so far, it appears this discussion is out of scope: While it may be the case that devices dynamically change their choice of wh= at "channels" they will use between queries of the database, it's at least = equally likely that it will get the list of available channels, choose one,= and stick to it. If they wanted to change at some point, it seems very fe= asible to query the database again, since the available spectrum may have c= hanged. The device can't tell the database what it's going to use before it knows w= hat is available. The "ack" sequence would be: Device to DB: What could I use at location x,y? DB to Device: You could use channels 3, 11 or 15 Device to DB: Okay, I'll use channel 11 Brian On Mar 9, 2012, at 6:58 PM, Paul Lambert wrote: > > > +1 to all of Joels comments > > Why would a third ack message ever be different from the original request= ? > > There's been no time to connect clients or make any other interesting cho= ices that would change the way the spectrum would be used. The ack is a us= eless message and any such informative information about the capabilities o= r plans of a device to use a range of spectrum should have been carried in = the first message. > > > Paul > >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Friday, March 09, 2012 8:00 AM >> To: chris.cheeseman@bt.com >> Cc: Paul Lambert; sdas@appcomsci.com; SiewYoon.Tan@ofcom.org.uk; >> JuanCarlos.Zuniga@InterDigital.com; Basavaraj.Patil@nokia.com; >> gerald.chouinard@sympatico.ca; scott.probasco@nokia.com; paws@ietf.org; >> presnick@qualcomm.com; Reza.Karimi@ofcom.org.uk; johnny.dixon@bt.com >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >> rqmts-03:channel reporting >> >> I am having trouble connecting the goal of the requirement, the expected >> protocol behavior, and the expected real-world operation. >> >> Lets keep it simple. A master, connected by wired internet to the >> World. A set of slaves who want to use whitespace to talk to the >> master. All within a small physical space. All within the the time >> limit of whatever answer the master gets from the database. >> >> The Ofcom requirement is described as being important for understanding >> interference effects. Therefore, presumably, it needs to relate to >> actual spectrum usage. >> >> The stated protocol behavior is that the master would reply to the >> shitespace database with an ack indicating what it expects to use, at >> what power level. >> The way folks are writing this, I believe the intention is "respond >> once". >> >> As I understand such master / slave behavior (and I am by no means a >> radio expert), the actual usage of spectrum, within the whitespace band, >> will depend upon how many slaves are active, and possibly on what they >> are doing. >> >> If the actual usage is going to depend upon the slave device population >> / behavior, then the only answer the master can correctly provide is "I >> will use all of the whitespace you have identified, with the highest >> power I might use. >> >> Such an answer is a valid answer in terms of protocol and in terms of >> the stated regulatory requirements. However, it is utterly useless in >> terms of the stated goal. >> As an engineer, I am very uncomfortable designing a protocol messaging >> exchange which I know will not meet the end-users needs. >> >> Note1: If I have mischaracterized ro misunderstood what folks ahve >> explained, I apologize. >> >> Note2: If instead the intention is for the master to update the database >> every time it changes the spectrum usage pattern, then this is NOT an >> acknowledgment of the reply from the database. It is a dynamic behavior >> reporting requirement. >> >> Yours, >> Joel >> >> On 3/9/2012 6:36 AM, chris.cheeseman@bt.com wrote: >>> Hi >>> >>> My reading of the UK regulatory requirements that Ofcom has made >> available is that the Acknowledgement message that must be communicated >> back to the database from the white space device is simply the frequency >> range (or ranges) and maximum eirp density that the device intends to >> use (a subset of what it would have been offered by the database). I >> don't believe there is any intent to limit modulation schemes etc. as >> part of this exchange. This seems a relatively straightforward >> requirement and the PAWS protocol should accommodate this if it is to be >> relevant for the UK regulatory environment. >>> >>> Regards, >>> >>> Chris >>> >>> -----Original Message----- >>> From: Paul Lambert [mailto:paul@marvell.com] >>> Sent: 09 March 2012 02:15 >>> To: Das, Subir; 'Siew Yoon Tan'; Zuniga, Juan Carlos; >> Basavaraj.Patil@nokia.com; gerald.chouinard@sympatico.ca; >> jmh@joelhalpern.com; scott.probasco@nokia.com >>> Cc: paws@ietf.org; presnick@qualcomm.com; Reza Karimi; >> Dixon,JS,Johnny,COD R; Cheeseman,CJ,Chris,COD R >>> Subject: RE: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >> rqmts-03:channel reporting >>> >>> >>> >>> >>> >>> >>>> I have a question here. Is it really an acknowledgement or we would >>>> like to see a kind of notification message that includes channel, and >>>> other parameters? >>> >>> What if it's multiple channels? What happens if the device adapts and >> changes between modulation technique or bandwidth? Does every change >> over the air need to be indicated to the GDB? >>> >>> This Channel acknowledgement does not seem useful and would limit real >> world behaviors (like channel and modulation adaptation). >>> >>> If viewed as a potential regulatory requirement - does this imply we >> need to parameterize the protocol to have different behaviors in >> different regions? >>> >>> Paul >>> >>> >>> >>>> >>>> Regards, >>>> _Subir >>>> >>>> -----Original Message----- >>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >> Of >>>> Siew Yoon Tan >>>> Sent: Thursday, March 08, 2012 4:06 PM >>>> To: Zuniga, Juan Carlos; Basavaraj.Patil@nokia.com; >>>> gerald.chouinard@sympatico.ca; jmh@joelhalpern.com; >>>> scott.probasco@nokia.com >>>> Cc: paws@ietf.org; presnick@qualcomm.com; Reza Karimi; >>>> johnny.dixon@bt.com; chris.cheeseman@bt.com >>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >>>> rqmts-03:channel reporting >>>> >>>> Dear All, >>>> >>>> Regarding Ofcom's requirement to have a return channel as part of the >>>> protocol between the WSD and WSDB, I would like to confirm to >> following >>>> sequence of messaging >>>> >>>> Channel request >>>> Channel response >>>> Channel acknowledgement >>>> >>>> which was raised in an earlier email to this list. >>>> >>>> Our view is that it would be beneficial to define the protocol >> between >>>> WSD and WSDB that supports this requirement even though how the >>>> information could be used is still subject to discussion in the UK. >>>> >>>> >>>> Best regards, >>>> >>>> Siew Yoon >>>> >>>> >>>> ________________________________________ >>>> From: paws-bounces@ietf.org [paws-bounces@ietf.org] on behalf of >>>> Zuniga, Juan Carlos [JuanCarlos.Zuniga@InterDigital.com] >>>> Sent: 08 March 2012 20:41 >>>> To: Basavaraj.Patil@nokia.com; gerald.chouinard@sympatico.ca; >>>> jmh@joelhalpern.com; scott.probasco@nokia.com >>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>>> chris.cheeseman@bt.com >>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- >> usecases- >>>> rqmts-03:channel reporting >>>> >>>> Hi Raj, >>>> >>>> I was reusing the language used from Gerald (which I know is familiar >>>> to people working on IEEE 802 WS groups): >>>> >>>>>> [GC] You got it. This would be useless for spectrum regulators. >> One >>>>>> should realize that, from the spectrum regulator's point of view, >>>>>> the second and third messages could be iterated upon to optimize >> the >>>>>> spectrum use. >>>>>> Knowing >>>>>> what channels the systems in an area are using, the spectrum >>>>>> regulators and/or other entities such as those taking care of >>>>>> coexistence could use the database in near-real-time to iterate on >>>>>> the two last messages to reduce the range of channels that some >>>>>> systems may use once they know precisely what channels are being >>>>>> used in the area. The PAWS protocol would carry the information >> back >>>>>> and forth but would not be involved in such spectrum use >> optimization. >>>> >>>> Having said that, I have no issue sticking to the WSDB terminology. I >>>> like keeping things simple :) >>>> >>>> JC >>>> >>>>> -----Original Message----- >>>>> From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] >>>>> Sent: Thursday, March 08, 2012 3:33 PM >>>>> To: Zuniga, Juan Carlos; gerald.chouinard@sympatico.ca; >>>>> jmh@joelhalpern.com; scott.probasco@nokia.com >>>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>>>> chris.cheeseman@bt.com >>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >>>>> rqmts-03:channel reporting >>>>> >>>>> >>>>> Hi JC, >>>>> >>>>> Where/why did the coexistence manager come into the picture? Your >>>>> comment about "communicating back to the WSDB/coexistence manager" >>>>> may result in further misunderstanding. If we simply stick to to >> WSDB >>>>> I think we are okay. >>>>> >>>>> -Raj >>>>> >>>>> On 3/8/12 2:25 PM, "ext Zuniga, Juan Carlos" >>>>> wrote: >>>>> >>>>>> So, from Gerald and Andy's comments, it seems like from the point >> of >>>>> view >>>>>> of (at least) two regulatory entities it is important for the >>>>>> protocol >>>>> to >>>>>> allow communicating back to the WSDB/coexistence manager the actual >>>>>> channel usage after the first query is made. >>>>>> >>>>>> This is to me a very clear requirement. >>>>>> >>>>>> The actual messages/IEs that would carry this information should be >>>>>> discussed as part of the solution document, and not the >> requirements. >>>>>> >>>>>> JC >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >>>>>>> Behalf >>>>> Of >>>>>>> Gerald Chouinard >>>>>>> Sent: Thursday, March 08, 2012 1:59 PM >>>>>>> To: 'Joel M. Halpern'; scott.probasco@nokia.com >>>>>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>>>>>> chris.cheeseman@bt.com >>>>>>> Subject: Re: [paws] WGLC for >>>>>>> draft-ietf-paws-problem-stmt-usecases- >>>>>>> rqmts-03:channel reporting >>>>>>> >>>>>>> Joel, Scott, >>>>>>> >>>>>>> Interesting discussion! See my comments in line below. >>>>>>> >>>>>>> Gerald >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >>>>>>> Behalf >>>>> Of >>>>>>> Joel >>>>>>> M. Halpern >>>>>>> Sent: Thursday, 08 March, 2012 13:17 >>>>>>> To: scott.probasco@nokia.com >>>>>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>>>>>> chris.cheeseman@bt.com >>>>>>> Subject: Re: [paws] WGLC for >>>>>>> draft-ietf-paws-problem-stmt-usecases- >>>>>>> rqmts-03: >>>>>>> channel reporting >>>>>>> >>>>>>> So why won't the device simply say "I will use all of this?" >>>>>>> [GC] This would defeat the purpose of the acknowledgement message. >>>>>>> After all, that way it needs to do less work with the database. >>>>>>> And >>>>> it >>>>>>> can change frequencies when it wants. >>>>>>> Given that the stated goal of the Ofcom requriement was to be able >>>>> to >>>>>>> analyze interference effects, it seems that this will not actually >>>>> lead >>>>>>> to them getting what they want, even if it does comply with the >>>>>>> regulations. >>>>>>> [GC] You got it. This would be useless for spectrum regulators. >>>>>>> One should realize that, from the spectrum regulator's point of >>>>>>> view, the >>>>> second >>>>>>> and >>>>>>> third messages could be iterated upon to optimize the spectrum >> use. >>>>>>> Knowing >>>>>>> what channels the systems in an area are using, the spectrum >>>>> regulators >>>>>>> and/or other entities such as those taking care of coexistence >>>>>>> could use the database in near-real-time to iterate on the two >>>>>>> last messages to reduce the range of channels that some systems >>>>>>> may use once they know precisely what channels are being used in >> the area. >>>>>>> The PAWS protocol would carry >>>>> the >>>>>>> information back and forth but would not be involved in such >>>>> spectrum >>>>>>> use >>>>>>> optimization. >>>>>>> >>>>>>> Yours, >>>>>>> joel >>>>>>> >>>>>>> On 3/8/2012 1:09 PM, scott.probasco@nokia.com wrote: >>>>>>>> Hi Peter, >>>>>>>> >>>>>>>> Answers below. >>>>>>>> >>>>>>>> Kind Regards, >>>>>>>> Scott >>>>>>>> >>>>>>>> On 3/8/12 11:39 AM, "ext Peter Saint-Andre" >>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Scott, I have two clarifying questions: >>>>>>>>> >>>>>>>>> 1. Does the device know, when it receives the channel response, >>>>>>> which >>>>>>>>> channel it will actually use? >>>>>>>> Scott->This is all new and I am not aware of any existing >>>>>>> implementations. >>>>>>>> I would argue that the device must decide what channel(s) it >>>>>>>> will >>>>> use >>>>>>> when >>>>>>>> it receives the channel response. >>>>>>> [GC] Agree with Scott but this is only a portion of the >>>>> considerations. >>>>>>> If a >>>>>>> device was to operate on its own, this would be true but a >>>>>>> communication device usually implies at least 2 devices to >>>>>>> communicate. Hence, the choice of the channel to be used will need >>>>>>> to be negotiated between the two devices before a choice can be >>>>>>> made. The chosen channel will belong to the >>>>> set >>>>>>> of >>>>>>> available channels that is common to both devices. Remember that >>>>> some >>>>>>> channels may be available at one device and not at the other >>>>>>> because >>>>> of >>>>>>> their geolocation or other reason. Extending this concept to a >>>>>>> star network topology, the channel that will be selected by this >>>>>>> network will >>>>> have >>>>>>> to >>>>>>> belong to the set of channels that are available to all devices. >>>>> Each >>>>>>> device >>>>>>> will not be able to decide by itself which channel it wants to >> use. >>>>>>> >>>>>>> This is why in such a star topology, it makes sense that the slave >>>>>>> devices to a base station or access point be represented by the >>>>>>> base station acting as the master on their behalf to query the >>>>>>> database and receive the list of available channels (and/or >>>>>>> maximum EIRP per channel). It is then the responsibility of the >>>>>>> base station to identify the set of available channels that is >>>>>>> common for itself and all its slaves to decide on the >>>>> channel >>>>>>> that >>>>>>> the network will use. As you can see, in this case, there is no >>>>>>> need for each slave to receive its list of available channels. On >>>>>>> its own, it would not know what to do with it. The only thing that >>>>>>> needs to be sent >>>>> from >>>>>>> the >>>>>>> master device to its slaves is the resulting operating channel. >>>>>>> >>>>>>> I a more sophisticated operation, the master device may add one or >>>>>>> a few backup channels extracted from the common set of available >>>>>>> channel >>>>> to >>>>>>> the >>>>>>> message going to its slave so that if a change in channel >>>>> availability >>>>>>> occurs, an instantaneous switch to the next backup channel can be >>>>> made >>>>>>> without any further signaling, thus providing for a channel switch >>>>> that >>>>>>> is >>>>>>> transparent to the user. It is the scheme that has been included >>>>>>> in >>>>> the >>>>>>> IEEE >>>>>>> 802.22-2011 Standard. This is why I don't believe that PAWS should >>>>> get >>>>>>> involved in defining this signaling between the base station and >>>>>>> its slaves devices. >>>>>>>>> >>>>>>>>> 2. If the device then uses another channel or a different >>>>> channel, >>>>>>> does >>>>>>>>> it need to report that change to the database? >>>>>>>> Scott->My interpretation of section 3.18 is that the device can >>>>> only >>>>>>>> transmit within the upper& lower frequencies returned in the >>>>>>>> acknowledgment. I do not (quickly) find any reference in the >>>>>>> requirements >>>>>>>> to changing channels. Thus operationally it could be that the >>>>> channel >>>>>>>> request process must be repeated before the device can use a >>>>>>> different >>>>>>>> channel (frequencies). >>>>>>> [GC] If the process involves 2 messages, then, the device and its >>>>>>> associated devices could change channels at will as long as all >>>>>>> these channels belong to the set of available channel. However, if >>>>>>> the third message is added, it would make sense that the master >>>>>>> device reports to the database any channel change that would occur >>>>>>> to the database, otherwise, the status of >>>>> the >>>>>>> spectrum occupation would be wrong at any moment and would be >>>>> useless >>>>>>> for >>>>>>> the purpose of any spectrum usage optimization such as >> coexistence. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>>> Peter >>>>>>>>> >>>>>>>>> On 3/8/12 10:17 AM, scott.probasco@nokia.com wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> The point from Brian is very relevant: >>>>>>>>>> >>>>>>>>>> Channel request >>>>>>>>>> Channel response >>>>>>>>>> Channel acknowledgement >>>>>>>>>> >>>>>>>>>> What Ofcom does with the information in the acknowledgement >>>>>>>>>> does >>>>>>> not >>>>>>>>>> matter. As the regulator in UK, they write rules that must be >>>>>>> followed >>>>>>>>>> in >>>>>>>>>> order to operate a whitespace radio in the UK. I believe the >>>>> scope >>>>>>> of >>>>>>>>>> the >>>>>>>>>> WG must be focused on a working solution. If this is simple >>>>> channel >>>>>>>>>> request& response in one regulator's domain, PAWS can support >>>>>>> this. If >>>>>>>>>> it >>>>>>>>>> means a channel request, response and acknowledgement in >>>>>>>>>> another regulator's domain, PAWS can support this. As a >>>>>>>>>> participating >>>>>>> member of >>>>>>>>>> the work group, I believe the scope should be basic working >>>>>>> solution, >>>>>>>>>> not >>>>>>>>>> limited to a specific number of messages. >>>>>>>>>> >>>>>>>>>> Kind Regards, >>>>>>>>>> Scott >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 3/8/12 11:11 AM, "ext Zuniga, Juan Carlos" >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Peter, Nancy, >>>>>>>>>>> >>>>>>>>>>> I agree should design a protocol with the best of our current >>>>>>>>>>> knowledge, and that should be accounting for all the known >>>>>>>>>>> regulations at >>>>>>> present >>>>>>>>>>> time. We should not limit the scope with the purpose of >>>>> designing >>>>>>> a >>>>>>>>>>> protocol 'faster'. Our goal is not only to design a WSDB >>>>> protocol. >>>>>>> Our >>>>>>>>>>> goal is to design a WSDB protocol that is USEFUL to the >>>>> community. >>>>>>>>>>> >>>>>>>>>>> The charter does state that >>>>>>>>>>> >>>>>>>>>>> "...the group should also reach out to other potential >>>>>>>>>>> "customers" for a white space database access method and >>>>> consider >>>>>>> input >>>>>>>>>>> from regulatory entities that are involved in the >>>>>>>>>>> specification >>>>> of >>>>>>> the >>>>>>>>>>> rules for secondary use of spectrum in specific radio bands. " >>>>>>>>>>> >>>>>>>>>>> I think that is exactly what we are doing now. >>>>>>>>>>> >>>>>>>>>>> Regarding whether the types of requirements belong to #1 or >>>>>>>>>>> #2, >>>>> I >>>>>>>>>>> believe >>>>>>>>>>> it is more of #1 type, as the information to be exchanged >>>>>>>>>>> would >>>>> be >>>>>>>>>>> known >>>>>>>>>>> after the initial query/response. >>>>>>>>>>> >>>>>>>>>>> If we know it today, I see no reason why we should not work >>>>>>>>>>> on >>>>> it >>>>>>> in >>>>>>>>>>> the >>>>>>>>>>> first phase of the work. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> Juan Carlos >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] >>>>>>>>>>>> On >>>>>>> Behalf >>>>>>>>>>>> Of >>>>>>>>>>>> Peter Saint-Andre >>>>>>>>>>>> Sent: Thursday, March 08, 2012 11:59 AM >>>>>>>>>>>> To: Nancy Bravin >>>>>>>>>>>> Cc: paws@ietf.org; johnny.dixon@bt.com; >>>>> chris.cheeseman@bt.com; >>>>>>> Pete >>>>>>>>>>>> Resnick >>>>>>>>>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- >>>>>>> usecases- >>>>>>>>>>>> rqmts-03: channel reporting >>>>>>>>>>>> >>>>>>>>>>>> Hi Nancy, >>>>>>>>>>>> >>>>>>>>>>>> You are absolutely right that different locales will have >>>>>>> different >>>>>>>>>>>> rules and requirements. We need to understand those, and >>>>>>>>>>>> work >>>>> to >>>>>>>>>>>> address >>>>>>>>>>>> them if possible (although we don't necessarily need to >>>>> address >>>>>>> them >>>>>>>>>>>> all >>>>>>>>>>>> at the same time). I see several kinds of requirements: >>>>>>>>>>>> >>>>>>>>>>>> 1. Some requirements might lead to features beyond the >>>>>>> query/response >>>>>>>>>>>> protocol we've envisioned so far. One example might be real- >>>>> time >>>>>>>>>>>> reporting about the channels that a device is actually using. >>>>> In >>>>>>> my >>>>>>>>>>>> opinion, it would be best to handle those in the next phase >>>>>>>>>>>> of >>>>>>> work, >>>>>>>>>>>> because as far as I can see they are outside the scope of >>>>>>>>>>>> our >>>>>>> charter. >>>>>>>>>>>> >>>>>>>>>>>> 2. Some requirements might be handled through by defining >>>>>>> additional >>>>>>>>>>>> fields that can be included in the query or response. We >>>>>>> definitely >>>>>>>>>>>> planned for that when working on the charter with the IESG: >>>>>>>>>>>> >>>>>>>>>>>> In addition, the particular >>>>>>>>>>>> data exchanged between a device and a database might >>>>>>>>>>>> depend >>>>> on >>>>>>> the >>>>>>>>>>>> ranges of radio spectrum that are to be used, the >>>>> requirements >>>>>>> of >>>>>>>>>>>> the >>>>>>>>>>>> database operators and their governing regulations, and >>>>> other >>>>>>>>>>>> factors. >>>>>>>>>>>> Therefore, the database access method and the >>>>> query/response >>>>>>> data >>>>>>>>>>>> formats that are exchanged using that method need to be >>>>>>> designed >>>>>>> for >>>>>>>>>>>> extensibility rather than being tied to any specific >>>>> spectrum, >>>>>>>>>>>> country, or phy/mac/air interface. >>>>>>>>>>>> >>>>>>>>>>>> It's unclear to me right now if the Ofcom requirement fits >>>>> into >>>>>>> #1 or >>>>>>>>>>>> #2, which is why we're having this discussion. :) >>>>>>>>>>>> >>>>>>>>>>>> Peter >>>>>>>>>>>> >>>>>>>>>>>> On 3/7/12 8:17 PM, Nancy Bravin wrote: >>>>>>>>>>>>> Peter and all, >>>>>>>>>>>>> >>>>>>>>>>>>> I agree that it is important to revisit now, so that in the >>>>>>> future, >>>>>>>>>>>>> it will be easy to align things in their proper place. >>>>>>>>>>>>> Every >>>>>>> country >>>>>>>>>>>>> may have different regulations, spectrum, policy and what >>>>>>>>>>>>> responsibility is in the domain of the system, and what >>>>>>>>>>>>> comes >>>>>>> under >>>>>>>>>>>>> the PAWS charter is important. Maybe some separation might >>>>> be >>>>>>>>>>>>> possible, and dividing and clarifying issues now will help >>>>>>>>>>>>> in >>>>>>> the >>>>>>>>>>>>> future. Certainly it seems that the FCC may change some >>>>> rules, >>>>>>> and >>>>>>>>>>>>> we know that Ofcom is not yet finished with their >>>>> regulations. >>>>>>> Canada >>>>>>>>>>>>> has their own, and other countries are working on this as >>>>> well. >>>>>>> Just >>>>>>>>>>>>> a thought...Sharing is a realistic goal...as is off >>>>> loading... >>>>>>> Or you >>>>>>>>>>>>> slim line and every 6 months decide what to incorporate in >>>>> the >>>>>>>>>>>>> protocol based on new information, new ideas, new >>>>>>>>>>>>> innovation >>>>> new >>>>>>>>>>>>> regulations and maybe spend more time than you could if >>>>>>> addressed >>>>>>>>>>>>> now. >>>>>>>>>>>>> >>>>>>>>>>>>> That way you leave the door open and outside of referencing >>>>> what >>>>>>> is >>>>>>>>>>>>> known today, by referencing regulations i.e. Ofcom, FCC, >>>>>>> Industry >>>>>>>>>>>>> Canada etc as of XX-XX-XXXX date. Out of scope not >>>>>>>>>>>>> something >>>>> we >>>>>>> know >>>>>>>>>>>>> enough about to say at this point, In my opinion. >>>>>>>>>>>>> >>>>>>>>>>>>> My 2 cents.. >>>>>>>>>>>>> >>>>>>>>>>>>> Sincerely, Nancy >>>>>>>>>>>>> >>>>>>>>>>>>> On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> As your responsible Area Director (until March 28, when >>>>>>>>>>>>>> Pete Resnick will take over from me), I have reviewed this >>>>> thread. >>>>>>>>>>>>>> >>>>>>>>>>>>>> In my opinion (I am happy to be proven wrong), this new >>>>>>> requirement >>>>>>>>>>>>>> goes beyond what the charter defined as the scope of this >>>>>>> working >>>>>>>>>>>>>> group, which was to enable a device to discover the white >>>>> space >>>>>>>>>>>>>> available to it in its current location. Reporting usage >>>>> back >>>>>>> to >>>>>>>>>>>>>> the database is simply not mentioned in the charter. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Earlier in this thread, Andy Sago wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> There's no language I can find in the charter that >>>>> explicitly >>>>>>> puts >>>>>>>>>>>>>> this out of scope. >>>>>>>>>>>>>> >>>>>>>>>>>>>> An IETF charter defines what the working group shall work >>>>> on. >>>>>>> Many >>>>>>>>>>>>>> interesting features could be developed here. However, it >>>>>>>>>>>>>> is >>>>>>> not >>>>>>>>>>>>>> the job of the charter to mention explicitly that each of >>>>> those >>>>>>>>>>>>>> interesting features is out of scope. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The charter does say: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Once the device learns of the available white space (e.g., >>>>> in a >>>>>>> TV >>>>>>>>>>>>>> white space implementation, the list of available channels >>>>> at >>>>>>> that >>>>>>>>>>>>>> location), it can then select one of the bands from the >>>>>>>>>>>>>> list >>>>>>> and >>>>>>>>>>>>>> begin to transmit and receive on the selected band. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This text might have assumed that no further communication >>>>> or >>>>>>>>>>>>>> authorization was required in order to select one of the >>>>> bands >>>>>>> from >>>>>>>>>>>>>> the list and then transmit/receive. Perhaps that >>>>>>>>>>>>>> assumption >>>>> was >>>>>>>>>>>>>> mistaken. If so, it would be good to have a discussion >>>>>>>>>>>>>> about >>>>>>> that, >>>>>>>>>>>>>> so we can determine if we need to revisit the assumptions >>>>>>>>>>>>>> we >>>>>>> made >>>>>>>>>>>>>> early on. If in fact we made some faulty or limited >>>>>>> assumptions, >>>>>>>>>>>>>> then let's get that out in the open. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Peter >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 3/7/12 9:40 AM, Rosen, Brian wrote: >>>>>>>>>>>>>>> I'd also suggest that >>>>> our >>>>>>>>>>>>>>> charter limitation is really support for sharing of >>>>> whitespace >>>>>>> by >>>>>>>>>>>>>>> whitespace devices. Reporting what you use is not >>>>>>>>>>>>>>> sharing, >>>>>>> it's >>>>>>>>>>>>>>> just data gathering. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The point of excluding sharing was to eliminate the >>>>>>> complexities >>>>>>>>>>>>>>> of what constituted fairness, and what kinds of >>>>> communication >>>>>>>>>>>>>>> might be needed between databases, where more than one >>>>> could >>>>>>>>>>>>>>> supply available whitespace in a band. This doesn't have >>>>> any >>>>>>> of >>>>>>>>>>>>>>> those issues, As long as it's just sending information, I >>>>>>> don't >>>>>>>>>>>>>>> have a problem. Once the database is supposed to do >>>>> anything >>>>>>>>>>>>>>> with it that involves changing what spectrum it reports, >>>>> then >>>>>>> I >>>>>>>>>>>>>>> think we cross the line. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Brian >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mar 6, 2012, at 12:28 PM, >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Joel >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Indeed, the regulator has not described the process or >>>>>>> provided >>>>>>>>>>>>>>>> a flow diagram, so there may be some wrinkles, but we >>>>>>>>>>>>>>>> need >>>>> to >>>>>>>>>>>>>>>> provide for their intent. To answer your question, the >>>>>>> channels >>>>>>>>>>>>>>>> that the master will use are sent in a separate message >>>>>>>>>>>>>>>> (described in P.12 ter), that occurs after the master >>>>>>> receives >>>>>>>>>>>>>>>> the response to its channel request, but before the >>>>>>>>>>>>>>>> master >>>>>>> can >>>>>>>>>>>>>>>> transmit. At this point, it knows what channels are >>>>>>> available, >>>>>>>>>>>>>>>> and which one it will use. As far as the slaves are >>>>>>> concerned, >>>>>>>>>>>>>>>> as they associate, the master will need to gather their >>>>>>> details >>>>>>>>>>>>>>>> and send further channel usage messages to the database >>>>>>>>>>>>>>>> on their behalf. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Andy >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -----Original Message----- From: paws-bounces@ietf.org >>>>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] On Behalf Of Joel M. >>>>> Halpern >>>>>>>>>>>>>>>> Sent: 06 March 2012 17:05 To: scott.probasco@nokia.com >>>> Cc: >>>>>>>>>>>>>>>> paws@ietf.org; Cheeseman,CJ,Chris,COD R; >>>>> Dixon,JS,Johnny,COD >>>>>>> R >>>>>>>>>>>>>>>> Subject: Re: [paws] WGLC for >>>>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel >>>>>>>>>>>>>>>> reporting >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Ahh. I think I see where the request and my >>>>>>>>>>>>>>>> understanding divurge. If the idea here is that the >>>>>>>>>>>>>>>> master must provide, >>>>> in >>>>>>>>>>>>>>>> the request, an indication of what channels it expects >>>>>>>>>>>>>>>> to >>>>>>> use, >>>>>>>>>>>>>>>> I can at least understand that. I will return to >>>>> technical >>>>>>>>>>>>>>>> concerns in a moment. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> However, when you say "provide channel usage >>>>>>>>>>>>>>>> information, >>>>> in >>>>>>>>>>>>>>>> order to evaluate interference", what that says to me is >>>>>>>>>>>>>>>> providing, during operation, information as to what >>>>> channels >>>>>>>>>>>>>>>> are being used, and at what power levels. That is what >>>>> would >>>>>>>>>>>>>>>> be needed to analyze actual interference effects. And >>>>>>>>>>>>>>>> that >>>>> is >>>>>>>>>>>>>>>> out of scope as I understand our scope. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I do see a technical difficulty with having the master >>>>>>> provide, >>>>>>>>>>>>>>>> as part of either registering or requesting spectrum >>>>>>>>>>>>>>>> information, what channels it intends to use. It >>>>>>>>>>>>>>>> doesn;t >>>>>>> know >>>>>>>>>>>>>>>> what channels it intends to use. It intends to use some >>>>>>> number >>>>>>>>>>>>>>>> of available channels. It will figure out which ones >>>>>>>>>>>>>>>> when >>>>> it >>>>>>>>>>>>>>>> is told what is available. How can it send that >>>>> information >>>>>>> in >>>>>>>>>>>>>>>> the request? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> There is a similarity here with device ID. In context >>>>>>>>>>>>>>>>> of >>>>>>> PAWS >>>>>>>>>>>>>>>>> we are not concerned with why a device ID is required >>>>>>>>>>>>>>>>> by >>>>> a >>>>>>>>>>>>>>>>> regulator, we accept it is a requirement from a >>>>>>>>>>>>>>>>> regulator >>>>>>> and >>>>>>>>>>>>>>>>> include it to the protocol. Ofcom identifies in 3.18& >>>>> 3.19 >>>>>>>>>>>>>>>>> that channel usage information is required and thus we >>>>> need >>>>>>>>>>>>>>>>> to include this information. Since the master must >>>>> provide >>>>>>>>>>>>>>>>> this information prior to transmitting, PAWS will not >>>>>>>>>>>>>>>>> function in the UK without this information and thus I >>>>>>>>>>>>>>>>> believe channel usage information is integral to the >>>>> channel >>>>>>>>>>>>>>>>> request& response messaging. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Kind Regards, Scott >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 3/6/12 10:30 AM, "ext Joel M. >>>>>>>>>>>>>>>>> Halpern" wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I would draw a distinction. Ofcom regulations about >>>>>>>>>>>>>>>>>> whitespace requests are very much relevant. Ofcom >>>>>>>>>>>>>>>>>> regulations about notification of dynamic behavior >>>>> (which >>>>>>>>>>>>>>>>>> spectrum is being used) are not in scope as I >>>>>>>>>>>>>>>>>> understand the earlier discussions, particularly the >>>>>>>>>>>>>>>>>> chartering discussions. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The ofcom requirements are very much relevant to the >>>>>>>>>>>>>>>>>>> scope of the PAWS WG. The only other regulatory >>>>>>>>>>>>>>>>>>> requirements that we have today is the FCC. Ofcom >>>>>>>>>>>>>>>>>>> requirements are a good addition to the set. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -Raj >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 3/6/12 10:03 AM, "ext >>>>>>>>>>>>>>>>>>> andy.sago@bt.com" wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hi Joel >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> There's no language I can find in the charter that >>>>>>>>>>>>>>>>>>>> explicitly puts this out of scope. On the other >>>>>>>>>>>>>>>>>>>> hand, the charter says that the group will "consider >>>>>>>>>>>>>>>>>>>> input from regulatory entities", and this is one of >>>>>>>>>>>>>>>>>>>> the requirements from Ofcom that they have just >>>> published. >>>>>>>>>>>>>>>>>>>> The protocol will be worthless for the UK if it >>>>>>>>>>>>>>>>>>>> omits some requirements. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Andy >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -----Original Message----- From: Joel M. Halpern >>>>>>>>>>>>>>>>>>>> [mailto:jmh@joelhalpern.com] Sent: 06 March 2012 >>>>>>>>>>>>>>>>>>>> 15:53 >>>>>>>>>>>>>>>>>>>> To: Sago,AJ,Andy,COD R Cc: paws@ietf.org; >>>>>>>>>>>>>>>>>>>> Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for >>>>>>>>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: >>>>> channel >>>>>>>>>>>>>>>>>>>> reporting >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> As I understand, the information you are asking for >>>>>>>>>>>>>>>>>>>> is explicitly out of scope for the working group. >>>>>>>>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >>>>>>>>>>>>>>>>>>>>> All >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Comparing the draft with the Ofcom requirements at >>>>>>>>>>>>>>>>>>>>> http://www.cept.org/Documents/se- >>>>>>>>>>>> 43/4161/SE43(12)Info03_Draft-UK-r >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> egul >>>>>>>>>>>>>>>>>>>>> atory-requirements-for-white-space-devices-in-the- >>>>> UHF- >>>>>>> TV- >>>>>>>>>>>> band, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> I believe the WG draft is deficient in the area of reporting >>>>>>>>>>>>>>>>>>>>> frequencies and powers actually used by masters and >>>>>>>>>>>>>>>>>>>>> slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom >>>>>>>>>>>>>>>>>>>>> intends to collect this data to assesses the impact >>>>>>>>>>>>>>>>>>>>> of aggregate interference into other services. It >>>>>>>>>>>>>>>>>>>>> would also provide usage information (frequency in >>>>>>>>>>>>>>>>>>>>> use) that would inform the operation of a kill >>>>>>>>>>>>>>>>>>>>> switch capability. I suggest this deficiency can be >>>>>>>>>>>>>>>>>>>>> remedied with the following changes: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> New P requirements (probably best placed following >>>>>>>>>>>>>>>>>>>>> P.12): >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> P.12bis: The protocol MUST support a channel usage >>>>>>>>>>>>>>>>>>>>> message from the slave device to the master device. >>>>>>>>>>>>>>>>>>>>> The channel usage message MUST include parameters >>>>>>>>>>>>>>>>>>>>> as required by local regulatory requirement. These >>>>>>>>>>>>>>>>>>>>> parameters MAY include device ID, manufacturer's >>>>>>>>>>>>>>>>>>>>> serial number, channel usage and power level >>>>>>>>>>>>>>>>>>>>> information. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> P.12ter: The protocol MUST support a channel usage >>>>>>>>>>>>>>>>>>>>> message from the master device to the database. >>>>>>>>>>>>>>>>>>>>> The channel usage message MUST include parameters >>>>>>>>>>>>>>>>>>>>> as required by local regulatory requirement for the >>>>>>>>>>>>>>>>>>>>> master and its associated slaves. These parameters >>>>>>>>>>>>>>>>>>>>> MAY include device ID, manufacturer's serial >>>>>>>>>>>>>>>>>>>>> number, channel usage and power level information. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> P.12qua: The protocol MUST support a channel usage >>>>>>>>>>>>>>>>>>>>> message acknowledgement. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> New O requirements (probably best placed following >>>>>>>>>>>>>>>>>>>>> O13): >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> O.13bis: According to local regulatory policy, >>>>>>>>>>>>>>>>>>>>> after connecting to a master device's radio network >>>>>>>>>>>>>>>>>>>>> a slave device MAY inform the master device of the >>>>>>>>>>>>>>>>>>>>> actual channel usage. The slave MUST include >>>>>>>>>>>>>>>>>>>>> parameters required by local regulatory policy, e.g. >>>>>>>>>>>>>>>>>>>>> device ID, manufacturer's serial number, channel >>>>>>>>>>>>>>>>>>>>> usage and power level information. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> O.13ter: According to local regulatory policy, a >>>>>>>>>>>>>>>>>>>>> master device MAY inform the database of the actual >>>>>>>>>>>>>>>>>>>>> channel usage of the master and its slaves. The >>>>>>>>>>>>>>>>>>>>> master MUST include parameters required by local >>>>>>>>>>>>>>>>>>>>> regulatory policy, e.g. device ID, manufacturer's >>>>>>>>>>>>>>>>>>>>> serial number, channel usage and power level >>>>>>>>>>>>>>>>>>>>> information of the master and its slaves. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> New steps could be introduced into one or more use >>>>>>>>>>>>>>>>>>>>> cases to cover these Ofcom requirements, e.g. new >>>>>>>>>>>>>>>>>>>>> steps 6bis and 9bis in the hotspot use case at >>>>>>>>>>>>>>>>>>>>> 4.2.1: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 6bis. Prior to initiating transmission, if required >>>>>>>>>>>>>>>>>>>>> by local regulation, the master/AP informs the >>>>>>>>>>>>>>>>>>>>> database of the channel and power level it has >>>>>>>>>>>>>>>>>>>>> chosen. This is repeated for each slave that >>>>>>>>>>>>>>>>>>>>> associated with the master. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 9bis. Prior to initiating transmission, if required >>>>>>>>>>>>>>>>>>>>> by local regulation, the slave informs the >>>>>>>>>>>>>>>>>>>>> master/AP of the channel and power level it has >>>>>>>>>>>>>>>>>>>>> chosen, and the master/AP relays this information >>>>>>>>>>>>>>>>>>>>> to the >>>> database. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> - end of new text - >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> For information, for those not accessing the url in >>>>>>>>>>>>>>>>>>>>> the first paragraph of this email, the full Ofcom >>>>>>>>>>>>>>>>>>>>> requirements leading to this new PAWS text are as >>>>>>>>>>>>>>>>>>>>> follows: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 3.18 After receiving instructions from a WSDB in >>>>>>>>>>>>>>>>>>>>> relation to the maximum permitted EIRPs over the >>>>>>>>>>>>>>>>>>>>> DTT channels, and prior to initiating transmissions >>>>>>>>>>>>>>>>>>>>> within the UHF TV band, a master WSD must >>>>>>>>>>>>>>>>>>>>> communicate to the WSDB the following information: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 3.18.1 The lower and upper frequency boundaries^13 >>>>>>>>>>>>>>>>>>>>> of the in-block emissions of the master WSD, and >>>>>>>>>>>>>>>>>>>>> those of the in-block emissions of its associated >>>>>>>>>>>>>>>>>>>>> slaves. A lower frequency will be specified as (470 >>>>>>>>>>>>>>>>>>>>> + 8k + >>>>>>>>>>>>>>>>>>>>> 0.2n) MHz, with the corresponding upper frequency >>>>>>>>>>>>>>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3?4 k >>>> 3?4 >>>>>>>>>>>>>>>>>>>>> 39, 0 3?4 n 3?4 39, 1 3?4 m 3?4 40, and n< m. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 3.18.2 The maximum in-block EIRP spectral densities >>>>>>>>>>>>>>>>>>>>> (in dBm/(0.2 MHz)) that the master WSD, and its >>>>>>>>>>>>>>>>>>>>> associated slaves, actually radiate between each >>>>>>>>>>>>>>>>>>>>> reported lower frequency boundary and its >>>>>>>>>>>>>>>>>>>>> corresponding upper frequency boundary. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Footnote 13 states: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> The use of upper and lower frequency boundaries >>>>>>>>>>>>>>>>>>>>> (defined over a 200 kHz raster) allows a WSDB to >>>>>>>>>>>>>>>>>>>>> collect more granular information with regards to >>>>>>>>>>>>>>>>>>>>> the usage of the frequency resource by narrowband >>>>>>>>>>>>>>>>>>>>> WSD technologies. The upper and lower frequencies >>>>>>>>>>>>>>>>>>>>> of a boundary pair do not straddle a DTT channel >>>> boundary. >>>>>>>>>>>>>>>>>>>>> Note that a WSD may transmit over multiple, >>>>>>>>>>>>>>>>>>>>> non-contiguous, whole DTT channels or fractions of >>>>>>>>>>>>>>>>>>>>> DTT channels. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 3.19 A master WSD must be able to receive the >>>>>>>>>>>>>>>>>>>>> following information^14 from a WSDB: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in the >>>>>>>>>>>>>>>>>>>>> context of 3.18, that the reported information on >>>>>>>>>>>>>>>>>>>>> the DTT channels and EIRP spectral densities >>>>>>>>>>>>>>>>>>>>> actually used by the master and slave WSDs were >>>>>>>>>>>>>>>>>>>>> received successfully by the WSDB^18 ]. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Footnote 14 states: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 14 While the communication of some of this >>>>>>>>>>>>>>>>>>>>> information from a WSDB to a master WSD is >>>>>>>>>>>>>>>>>>>>> optional, master WSDs must be able to receive and >>>>>>>>>>>>>>>>>>>>> interpret these. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Footnote 18 states: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 18 This forms part of a handshake protocol and may >>>>>>>>>>>>>>>>>>>>> be an area where industry could harmonise without >>>>>>>>>>>>>>>>>>>>> the need for an explicit requirement in the >>>> regulations. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Andy >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> *From:*paws-bounces@ietf.org >>>>>>>>>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] *On Behalf Of >>>>>>>>>>>>>>>>>>>>> *Gabor.Bajko@nokia.com *Sent:* 05 March 2012 19:46 >>>>>>>>>>>>>>>>>>>>> *To:* paws@ietf.org *Subject:* [paws] WGLC for >>>>>>>>>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> The authors of the use cases and requirements draft >>>>>>>>>>>>>>>>>>>>> have just posted a new version of the draft and >>>>>>>>>>>>>>>>>>>>> indicated that there are no unresolved >>>>>>>>>>>>>>>>>>>>> comments/issues they are aware of. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Therefore, I'd like to initiate a WG Last Call for >>>>>>>>>>>>>>>>>>>>> comments on >>>>>>>>>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-paws >>>>>>>>>>>>>>>>>>>>> - >>>>>>> problem- >>>>>>>>>>>> stmt-u >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> seca >>>>>>>>>>>>>>>>>>>>> ses-rqmts-03.txt >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Please review the draft and send your comments to >>>>>>>>>>>>>>>>>>>>> the list by March 20th, 2012. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> If you review the draft and have no comments, send >>>>>>>>>>>>>>>>>>>>> a note to the list that the draft is good as it is, >>>>>>>>>>>>>>>>>>>>> we need these notes as much as we need the actual >>>>>>>>>>>>>>>>>>>>> comments. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, Gabor >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> paws mailing list >>>>>>>> paws@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> paws mailing list >>>>>>> paws@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>> >>>>>>> _______________________________________________ >>>>>>> paws mailing list >>>>>>> paws@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> ________________________________ >>>> >>>> >> *********************************************************************** >>>> * >>>> ****************************************** >>>> For more information visit www.ofcom.org.uk >>>> >>>> This email (and any attachments) is confidential and intended for the >>>> use of the addressee only. >>>> >>>> If you have received this email in error please notify the originator >>>> of the message and delete it from your system. >>>> >>>> This email has been scanned for viruses. However, you open any >>>> attachments at your own risk. >>>> >>>> Any views expressed in this message are those of the individual >> sender >>>> and do not represent the views or opinions of Ofcom unless expressly >>>> stated otherwise. >>>> >> *********************************************************************** >>>> * >>>> ****************************************** >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>> > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From teco@inf-net.nl Mon Mar 19 09:04:34 2012 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 CFC2C21F8798 for ; Mon, 19 Mar 2012 09:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=-0.114, 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 jivE5HL7DS4Q for ; Mon, 19 Mar 2012 09:04:33 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 4C20821F8790 for ; Mon, 19 Mar 2012 09:04:33 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so3190642wib.13 for ; Mon, 19 Mar 2012 09:04:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=H/uBv0gVrhzUY4kvZkBdHBQ+ZaC/I8LkWI95XBMRA8A=; b=eiErNpon9mrEsqr5bQ++sIMflfIxVF9xFYE6Z0FQngfZYhDtrcyaoYbIGRz1W5mwyz KcQnEPpefRu6NY3HYqeH90hPeux3xnJg9/gNHDZAH3caECkSm1nnkl9aagwHrIK/KIya nzbnH4UV0m++PoCkgXCVpCvWLAv9DIvHDOvbjmtnbZlFEyy4mYu9ItaN3nr/f0tUx44e 95TWLE+KWdisQhtjbtfcCHVUvXCxBcGJskJb5Sw6r/ZtZc0bCWZYlgYiEu77AbcWbCbM l9b/pppOHs/LULC9bmdahvDJU9oc4FlPWedgkjQW0T3iYShztpZFeagRYr9N0PA/mLnC PYLQ== Received: by 10.180.97.41 with SMTP id dx9mr20989901wib.9.1332173072400; Mon, 19 Mar 2012 09:04:32 -0700 (PDT) Received: from [10.87.39.232] ([80.187.201.33]) by mx.google.com with ESMTPS id ff2sm42769361wib.9.2012.03.19.09.04.30 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Mar 2012 09:04:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601E1E216@008-AM1MPN1-006.mgdnok.nokia.com> Date: Mon, 19 Mar 2012 17:04:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <627E419D-EF38-40A1-8C0E-A42115BD7CC0@inf-net.nl> References: , <7BAC95F5A7E67643AAFB2C31BEE662D0157A034B37@SC-VEXCH2.marvell.com> <2D1F0F0C-F3B9-43ED-8195-0962DF863AC8@neustar.biz> <4F5A2841.4030506@qualcomm.com> <1ECAFF543A2FED4EA2BEB6CACE08E47601E1E216@008-AM1MPN1-006.mgdnok.nokia.com> To: X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkIoI61fSeKKpu3NNdetVhhbJX1oquqRmTKWLDzZ42TjM6PmP8rEfH4g3CWZIaA84dYsi9n Cc: paws@ietf.org Subject: Re: [paws] WGLC fordraft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting 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, 19 Mar 2012 16:04:35 -0000 I don't prefer any delay in getting out a first release of a PAWS = protocol. We already know the protocol must be extendable and new = requirements from regulators will be on the horizon. So I suggest to = continue with our work, based on current charter. Meanwhile, we can = discuss extensions. On 1: I don't play soccer. Let's continue fulfilling our current task. On 2: We can work on new documents for additional requirements and = protocol extensions. No WG adoption yet. On 3: Let's do this in parallel. When having candidate documents and a = new charter, it shouldn't take much time to get this published. Thanks, Teco Op 10 mrt. 2012, om 08:44 heeft = het volgende geschreven: > When we started this paws effort not that long ago, the whole purpose = was to define a protocol which can help devices make use of white = spaces, according to rules set by the regulators. The charter we came up = with covered the regulatory requirements available at the time of = writing, and we did not anticipate requirements like the one Ofcom came = up with recently. That is why we do not have, as Pete pointed out, = explicitly listed an item for the client devices to report back anything = to the server. We do have, however, the following sentence in the = charter:=20 > " In order to ensure that the WG takes into account a broad range of = possible use cases and > requirements, the group should also reach out to other potential > "customers" for a white space database access method and consider = input > from regulatory entities that are involved in the specification of the = rules " > It just does not say how the inputs from regulatory entities are to be = considered ... >=20 > I would put aside the solution proposals on whether the client should = use an acknowledgement message or a separate transaction for reporting = back, what exactly to report, etc, and consider for the time being that = we have a requirements document and this whole thread started with Andy = proposing new requirements the be added there to meet Ofcom = requirements. >=20 > I see the following possibilities: > 1. ignore the Ofcom requirements on channel reporting back to the db. = I believe, if we choose this path, then the protocol we'll design will = not meet the original goals, and we may just as well go home and play = soccer instead > 2. try to fit the Ofcom requirements into the charter. One could argue = this is possible, as the Ofcom requirements do not specify what the db = is supposed to do with that data, we could consider it is just for = informational purposes. We've seen both pro and con opinions on this on = the list, so we could continue to argue. But since both the outgoing and = incoming AD thinks this is not the way to go, I do not see much hope we = can succeed on this path. > 3. go back to iesg and modify the charter to include the channel = reporting back to the db aspect. If we do this, we can then include the = relevant requirements into the reqs draft, issue a new wglc and start = the work on the protocol itself. I see this the fastest and least = controversial (at least from the ADs pow) path. >=20 > So what do folks, who believe they know the ietf process well enough, = prefer? I am just trying to get the wg out of this deadlock situation, = so please be constructive. >=20 > - Gabor >=20 >=20 >=20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of ext Pete Resnick > Sent: Friday, March 09, 2012 7:57 AM > To: Gerald Chouinard > Cc: paws@ietf.org > Subject: Re: [paws] WGLC = fordraft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting >=20 > Folks, >=20 > Fair warning as your incoming AD, but also as a current AD who thought = he understood what work this group was chartered to do: >=20 > The group is chartered to do (1) database discovery, (2) database = access, (3) data formats for that database access, and (4) security for = that database access. The charter also describes what that database = access is like: (a) provide geolocation and other info to query the = database, and (b) receive the whitespace that can be used. >=20 > Insofar as what this charter only allows for protocol that is about = database discovery and database access, the so-called "acknowledgment"=20= > you all are talking is either writing back to the database (if the = "acknowledgment" data gets saved into the same database) or is = non-database-access protocol to talk to a third party. In either case, = I, as an AD, would be extremely surprised to find out either that the = database was writeable by the client (that was not my understanding of = the query described in the "rough outline of the protocol" section of = the charter) or that there was to be additional protocol that sent data = from the client to a third party. There is a whole new set of = considerations on such protocol (e.g., Does the information sent back = from the client need TTL values? Is there a renewal process on the data = after some time? What if there are multiple clients accessing at the = same time and they choose the same value? Can the response get back an = error and the client has to choose something different?). >=20 > If you wish to take on this work, you need to go back to the IESG and = re-charter. That's fine: If the WG feels that this piece of protocol is = required in order to make the rest of the protocol at all useful, now is = the time to tell the IESG that and figure out how to write it into the = charter. But doing this work without a charter change is going to cause = heartache later. >=20 > pr >=20 > -- > Pete Resnick > Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: = (858)651-1102 >=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 nbravin@earthlink.net Mon Mar 19 09:35:16 2012 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 A9C2E21F885E for ; Mon, 19 Mar 2012 09:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.782 X-Spam-Level: X-Spam-Status: No, score=-1.782 tagged_above=-999 required=5 tests=[AWL=0.590, 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 ROjzkWWZnecD for ; Mon, 19 Mar 2012 09:35:15 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 930A021F8846 for ; Mon, 19 Mar 2012 09:35:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=olxTZ+n+hAFwsRHIpIJhPVEQ6IbMPoU0eK0o7caJckB5EUtEkapsWWTZzMFvBYom; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [98.150.41.129] (helo=[10.0.1.2]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1S9fY7-0005Nl-NP; Mon, 19 Mar 2012 12:35:12 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Nancy Bravin In-Reply-To: <627E419D-EF38-40A1-8C0E-A42115BD7CC0@inf-net.nl> Date: Mon, 19 Mar 2012 09:35:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <35F5BD9E-D7E0-4D1F-8D89-FEC9F463749F@earthlink.net> References: , <7BAC95F5A7E67643AAFB2C31BEE662D0157A034B37@SC-VEXCH2.marvell.com> <2D1F0F0C-F3B9-43ED-8195-0962DF863AC8@neustar.biz> <4F5A2841.4030506@qualcomm.com> <1ECAFF543A2FED4EA2BEB6CACE08E47601E1E216@008-AM1MPN1-006.mgdnok.nokia.com> <627E419D-EF38-40A1-8C0E-A42115BD7CC0@inf-net.nl> To: Gabor Bajko X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad8638d6d00a747d0eb949325948549ae154350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.150.41.129 Cc: paws@ietf.org Subject: Re: [paws] WGLC fordraft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting 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, 19 Mar 2012 16:35:16 -0000 I will of course go along with the consensus, however, there is one = advantage in going back to the IESG now, because the "sentence" allows = for additional Regulatory changes/input it should be a quick decision since Ofcom is = probably the most advanced in implementing a DB(s) and WSD's. The FCC is probably going to have changes but more slowly, Industry = Canada also implementing regulations. If one looks at the Ofcom model of licensed, only 4 TV stations, one = could assume that what they are doing may be similar to other countries that may have a similar model, or those that have State run TV with = limited channels. If we do not are we making ourselves irrelevant to = Ofcom now=85and will have to play catch up not only with what is already known now, but what will be changing in = the future?=20 The next round will assumably start on more detailed work=85why not = clear that path now? And once cleared we can do both=85in parallel? Sincerely, Nancy On Mar 19, 2012, at 9:04 AM, Teco Boot wrote: > I don't prefer any delay in getting out a first release of a PAWS = protocol. We already know the protocol must be extendable and new = requirements from regulators will be on the horizon. So I suggest to = continue with our work, based on current charter. Meanwhile, we can = discuss extensions. >=20 > On 1: I don't play soccer. Let's continue fulfilling our current task. > On 2: We can work on new documents for additional requirements and = protocol extensions. No WG adoption yet. > On 3: Let's do this in parallel. When having candidate documents and a = new charter, it shouldn't take much time to get this published. >=20 > Thanks, Teco >=20 > Op 10 mrt. 2012, om 08:44 heeft = het volgende geschreven: >=20 >> When we started this paws effort not that long ago, the whole purpose = was to define a protocol which can help devices make use of white = spaces, according to rules set by the regulators. The charter we came up = with covered the regulatory requirements available at the time of = writing, and we did not anticipate requirements like the one Ofcom came = up with recently. That is why we do not have, as Pete pointed out, = explicitly listed an item for the client devices to report back anything = to the server. We do have, however, the following sentence in the = charter:=20 >> " In order to ensure that the WG takes into account a broad range of = possible use cases and >> requirements, the group should also reach out to other potential >> "customers" for a white space database access method and consider = input >> from regulatory entities that are involved in the specification of = the rules " >> It just does not say how the inputs from regulatory entities are to = be considered ... >>=20 >> I would put aside the solution proposals on whether the client should = use an acknowledgement message or a separate transaction for reporting = back, what exactly to report, etc, and consider for the time being that = we have a requirements document and this whole thread started with Andy = proposing new requirements the be added there to meet Ofcom = requirements. >>=20 >> I see the following possibilities: >> 1. ignore the Ofcom requirements on channel reporting back to the db. = I believe, if we choose this path, then the protocol we'll design will = not meet the original goals, and we may just as well go home and play = soccer instead >> 2. try to fit the Ofcom requirements into the charter. One could = argue this is possible, as the Ofcom requirements do not specify what = the db is supposed to do with that data, we could consider it is just = for informational purposes. We've seen both pro and con opinions on this = on the list, so we could continue to argue. But since both the outgoing = and incoming AD thinks this is not the way to go, I do not see much hope = we can succeed on this path. >> 3. go back to iesg and modify the charter to include the channel = reporting back to the db aspect. If we do this, we can then include the = relevant requirements into the reqs draft, issue a new wglc and start = the work on the protocol itself. I see this the fastest and least = controversial (at least from the ADs pow) path. >>=20 >> So what do folks, who believe they know the ietf process well enough, = prefer? I am just trying to get the wg out of this deadlock situation, = so please be constructive. >>=20 >> - Gabor >>=20 >>=20 >>=20 >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of ext Pete Resnick >> Sent: Friday, March 09, 2012 7:57 AM >> To: Gerald Chouinard >> Cc: paws@ietf.org >> Subject: Re: [paws] WGLC = fordraft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting >>=20 >> Folks, >>=20 >> Fair warning as your incoming AD, but also as a current AD who = thought he understood what work this group was chartered to do: >>=20 >> The group is chartered to do (1) database discovery, (2) database = access, (3) data formats for that database access, and (4) security for = that database access. The charter also describes what that database = access is like: (a) provide geolocation and other info to query the = database, and (b) receive the whitespace that can be used. >>=20 >> Insofar as what this charter only allows for protocol that is about = database discovery and database access, the so-called "acknowledgment"=20= >> you all are talking is either writing back to the database (if the = "acknowledgment" data gets saved into the same database) or is = non-database-access protocol to talk to a third party. In either case, = I, as an AD, would be extremely surprised to find out either that the = database was writeable by the client (that was not my understanding of = the query described in the "rough outline of the protocol" section of = the charter) or that there was to be additional protocol that sent data = from the client to a third party. There is a whole new set of = considerations on such protocol (e.g., Does the information sent back = from the client need TTL values? Is there a renewal process on the data = after some time? What if there are multiple clients accessing at the = same time and they choose the same value? Can the response get back an = error and the client has to choose something different?). >>=20 >> If you wish to take on this work, you need to go back to the IESG and = re-charter. That's fine: If the WG feels that this piece of protocol is = required in order to make the rest of the protocol at all useful, now is = the time to tell the IESG that and figure out how to write it into the = charter. But doing this work without a charter change is going to cause = heartache later. >>=20 >> pr >>=20 >> -- >> Pete Resnick >> Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: = (858)651-1102 >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From paul@marvell.com Mon Mar 19 11:59:23 2012 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 8766E21F88D7 for ; Mon, 19 Mar 2012 11:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.823 X-Spam-Level: X-Spam-Status: No, score=-4.823 tagged_above=-999 required=5 tests=[AWL=-0.851, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4, 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 ZfFFPxjw7SKm for ; Mon, 19 Mar 2012 11:59:20 -0700 (PDT) Received: from na3sys009aog123.obsmtp.com (na3sys009aog123.obsmtp.com [74.125.149.149]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBFF21F8822 for ; Mon, 19 Mar 2012 11:59:17 -0700 (PDT) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob123.postini.com ([74.125.148.12]) with SMTP ID DSNKT2eB/wocdN+hVl6nj0bpLyBHBkuk88hf@postini.com; Mon, 19 Mar 2012 11:59:19 PDT Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Mon, 19 Mar 2012 11:58:43 -0700 From: Paul Lambert To: "Rosen, Brian" Date: Mon, 19 Mar 2012 11:58:41 -0700 Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting Thread-Index: Ac0F41bGGP9LGTvARqq2MthLhc0tYAAHilYw Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D015E331E56C@SC-VEXCH2.marvell.com> References: , <7BAC95F5A7E67643AAFB2C31BEE662D0157A034B37@SC-VEXCH2.marvell.com> <4F5A28F7.4070905@joelhalpern.com> <7BAC95F5A7E67643AAFB2C31BEE662D0157A034D48@SC-VEXCH2.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Reza.Karimi@ofcom.org.uk" , "paws@ietf.org" , "johnny.dixon@bt.com" , "presnick@qualcomm.com" Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting 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, 19 Mar 2012 18:59:23 -0000 >-----Original Message----- >From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >Sent: Monday, March 19, 2012 8:17 AM >To: Paul Lambert >Cc: Joel M. Halpern; chris.cheeseman@bt.com; Reza.Karimi@ofcom.org.uk; >paws@ietf.org; johnny.dixon@bt.com; presnick@qualcomm.com >Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >rqmts-03:channel reporting > > >Remembering that so far, it appears this discussion is out of scope: > >While it may be the case that devices dynamically change their choice of >what "channels" they will use between queries of the database, it's at >least equally likely that it will get the list of available channels, >choose one, and stick to it. If they wanted to change at some point, it >seems very feasible to query the database again, since the available >spectrum may have changed. > >The device can't tell the database what it's going to use before it >knows what is available. > >The "ack" sequence would be: >Device to DB: What could I use at location x,y? >DB to Device: You could use channels 3, 11 or 15 >Device to DB: Okay, I'll use channel 11 But the "ack" in this sequence occurs right after the "you could use" messa= ge. Any intelligent AP/Master might some time to evaluate each channel and= pick one later that has the lowest utilization. It would not have this kn= owledge in time for an "ack". If it picked a channel for the ack, it would= likely change soon to another channel. Given that the "ack" has only informative information that will change - th= ere is nothing useful that can be done by the DB with this information. Un= less the Master provides continuous updates of channel utilization - there = is no reason to have this information carried in an ack. We should not create extra messages to carry information that will not be u= sed in any processing. Paul > >Brian > >On Mar 9, 2012, at 6:58 PM, Paul Lambert wrote: > >> >> >> +1 to all of Joels comments >> >> Why would a third ack message ever be different from the original >request? >> >> There's been no time to connect clients or make any other interesting >choices that would change the way the spectrum would be used. The ack >is a useless message and any such informative information about the >capabilities or plans of a device to use a range of spectrum should have >been carried in the first message. >> >> >> Paul >> >>> -----Original Message----- >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>> Sent: Friday, March 09, 2012 8:00 AM >>> To: chris.cheeseman@bt.com >>> Cc: Paul Lambert; sdas@appcomsci.com; SiewYoon.Tan@ofcom.org.uk; >>> JuanCarlos.Zuniga@InterDigital.com; Basavaraj.Patil@nokia.com; >>> gerald.chouinard@sympatico.ca; scott.probasco@nokia.com; >paws@ietf.org; >>> presnick@qualcomm.com; Reza.Karimi@ofcom.org.uk; johnny.dixon@bt.com >>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >>> rqmts-03:channel reporting >>> >>> I am having trouble connecting the goal of the requirement, the >expected >>> protocol behavior, and the expected real-world operation. >>> >>> Lets keep it simple. A master, connected by wired internet to the >>> World. A set of slaves who want to use whitespace to talk to the >>> master. All within a small physical space. All within the the time >>> limit of whatever answer the master gets from the database. >>> >>> The Ofcom requirement is described as being important for >understanding >>> interference effects. Therefore, presumably, it needs to relate to >>> actual spectrum usage. >>> >>> The stated protocol behavior is that the master would reply to the >>> shitespace database with an ack indicating what it expects to use, at >>> what power level. >>> The way folks are writing this, I believe the intention is "respond >>> once". >>> >>> As I understand such master / slave behavior (and I am by no means a >>> radio expert), the actual usage of spectrum, within the whitespace >band, >>> will depend upon how many slaves are active, and possibly on what >they >>> are doing. >>> >>> If the actual usage is going to depend upon the slave device >population >>> / behavior, then the only answer the master can correctly provide is >"I >>> will use all of the whitespace you have identified, with the highest >>> power I might use. >>> >>> Such an answer is a valid answer in terms of protocol and in terms of >>> the stated regulatory requirements. However, it is utterly useless >in >>> terms of the stated goal. >>> As an engineer, I am very uncomfortable designing a protocol >messaging >>> exchange which I know will not meet the end-users needs. >>> >>> Note1: If I have mischaracterized ro misunderstood what folks ahve >>> explained, I apologize. >>> >>> Note2: If instead the intention is for the master to update the >database >>> every time it changes the spectrum usage pattern, then this is NOT an >>> acknowledgment of the reply from the database. It is a dynamic >behavior >>> reporting requirement. >>> >>> Yours, >>> Joel >>> >>> On 3/9/2012 6:36 AM, chris.cheeseman@bt.com wrote: >>>> Hi >>>> >>>> My reading of the UK regulatory requirements that Ofcom has made >>> available is that the Acknowledgement message that must be >communicated >>> back to the database from the white space device is simply the >frequency >>> range (or ranges) and maximum eirp density that the device intends to >>> use (a subset of what it would have been offered by the database). I >>> don't believe there is any intent to limit modulation schemes etc. as >>> part of this exchange. This seems a relatively straightforward >>> requirement and the PAWS protocol should accommodate this if it is to >be >>> relevant for the UK regulatory environment. >>>> >>>> Regards, >>>> >>>> Chris >>>> >>>> -----Original Message----- >>>> From: Paul Lambert [mailto:paul@marvell.com] >>>> Sent: 09 March 2012 02:15 >>>> To: Das, Subir; 'Siew Yoon Tan'; Zuniga, Juan Carlos; >>> Basavaraj.Patil@nokia.com; gerald.chouinard@sympatico.ca; >>> jmh@joelhalpern.com; scott.probasco@nokia.com >>>> Cc: paws@ietf.org; presnick@qualcomm.com; Reza Karimi; >>> Dixon,JS,Johnny,COD R; Cheeseman,CJ,Chris,COD R >>>> Subject: RE: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >>> rqmts-03:channel reporting >>>> >>>> >>>> >>>> >>>> >>>> >>>>> I have a question here. Is it really an acknowledgement or we would >>>>> like to see a kind of notification message that includes channel, >and >>>>> other parameters? >>>> >>>> What if it's multiple channels? What happens if the device adapts >and >>> changes between modulation technique or bandwidth? Does every change >>> over the air need to be indicated to the GDB? >>>> >>>> This Channel acknowledgement does not seem useful and would limit >real >>> world behaviors (like channel and modulation adaptation). >>>> >>>> If viewed as a potential regulatory requirement - does this imply we >>> need to parameterize the protocol to have different behaviors in >>> different regions? >>>> >>>> Paul >>>> >>>> >>>> >>>>> >>>>> Regards, >>>>> _Subir >>>>> >>>>> -----Original Message----- >>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >Behalf >>> Of >>>>> Siew Yoon Tan >>>>> Sent: Thursday, March 08, 2012 4:06 PM >>>>> To: Zuniga, Juan Carlos; Basavaraj.Patil@nokia.com; >>>>> gerald.chouinard@sympatico.ca; jmh@joelhalpern.com; >>>>> scott.probasco@nokia.com >>>>> Cc: paws@ietf.org; presnick@qualcomm.com; Reza Karimi; >>>>> johnny.dixon@bt.com; chris.cheeseman@bt.com >>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >>>>> rqmts-03:channel reporting >>>>> >>>>> Dear All, >>>>> >>>>> Regarding Ofcom's requirement to have a return channel as part of >the >>>>> protocol between the WSD and WSDB, I would like to confirm to >>> following >>>>> sequence of messaging >>>>> >>>>> Channel request >>>>> Channel response >>>>> Channel acknowledgement >>>>> >>>>> which was raised in an earlier email to this list. >>>>> >>>>> Our view is that it would be beneficial to define the protocol >>> between >>>>> WSD and WSDB that supports this requirement even though how the >>>>> information could be used is still subject to discussion in the UK. >>>>> >>>>> >>>>> Best regards, >>>>> >>>>> Siew Yoon >>>>> >>>>> >>>>> ________________________________________ >>>>> From: paws-bounces@ietf.org [paws-bounces@ietf.org] on behalf of >>>>> Zuniga, Juan Carlos [JuanCarlos.Zuniga@InterDigital.com] >>>>> Sent: 08 March 2012 20:41 >>>>> To: Basavaraj.Patil@nokia.com; gerald.chouinard@sympatico.ca; >>>>> jmh@joelhalpern.com; scott.probasco@nokia.com >>>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>>>> chris.cheeseman@bt.com >>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- >>> usecases- >>>>> rqmts-03:channel reporting >>>>> >>>>> Hi Raj, >>>>> >>>>> I was reusing the language used from Gerald (which I know is >familiar >>>>> to people working on IEEE 802 WS groups): >>>>> >>>>>>> [GC] You got it. This would be useless for spectrum regulators. >>> One >>>>>>> should realize that, from the spectrum regulator's point of view, >>>>>>> the second and third messages could be iterated upon to optimize >>> the >>>>>>> spectrum use. >>>>>>> Knowing >>>>>>> what channels the systems in an area are using, the spectrum >>>>>>> regulators and/or other entities such as those taking care of >>>>>>> coexistence could use the database in near-real-time to iterate >on >>>>>>> the two last messages to reduce the range of channels that some >>>>>>> systems may use once they know precisely what channels are being >>>>>>> used in the area. The PAWS protocol would carry the information >>> back >>>>>>> and forth but would not be involved in such spectrum use >>> optimization. >>>>> >>>>> Having said that, I have no issue sticking to the WSDB terminology. >I >>>>> like keeping things simple :) >>>>> >>>>> JC >>>>> >>>>>> -----Original Message----- >>>>>> From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] >>>>>> Sent: Thursday, March 08, 2012 3:33 PM >>>>>> To: Zuniga, Juan Carlos; gerald.chouinard@sympatico.ca; >>>>>> jmh@joelhalpern.com; scott.probasco@nokia.com >>>>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>>>>> chris.cheeseman@bt.com >>>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- >usecases- >>>>>> rqmts-03:channel reporting >>>>>> >>>>>> >>>>>> Hi JC, >>>>>> >>>>>> Where/why did the coexistence manager come into the picture? Your >>>>>> comment about "communicating back to the WSDB/coexistence manager" >>>>>> may result in further misunderstanding. If we simply stick to to >>> WSDB >>>>>> I think we are okay. >>>>>> >>>>>> -Raj >>>>>> >>>>>> On 3/8/12 2:25 PM, "ext Zuniga, Juan Carlos" >>>>>> wrote: >>>>>> >>>>>>> So, from Gerald and Andy's comments, it seems like from the point >>> of >>>>>> view >>>>>>> of (at least) two regulatory entities it is important for the >>>>>>> protocol >>>>>> to >>>>>>> allow communicating back to the WSDB/coexistence manager the >actual >>>>>>> channel usage after the first query is made. >>>>>>> >>>>>>> This is to me a very clear requirement. >>>>>>> >>>>>>> The actual messages/IEs that would carry this information should >be >>>>>>> discussed as part of the solution document, and not the >>> requirements. >>>>>>> >>>>>>> JC >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >>>>>>>> Behalf >>>>>> Of >>>>>>>> Gerald Chouinard >>>>>>>> Sent: Thursday, March 08, 2012 1:59 PM >>>>>>>> To: 'Joel M. Halpern'; scott.probasco@nokia.com >>>>>>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>>>>>>> chris.cheeseman@bt.com >>>>>>>> Subject: Re: [paws] WGLC for >>>>>>>> draft-ietf-paws-problem-stmt-usecases- >>>>>>>> rqmts-03:channel reporting >>>>>>>> >>>>>>>> Joel, Scott, >>>>>>>> >>>>>>>> Interesting discussion! See my comments in line below. >>>>>>>> >>>>>>>> Gerald >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >>>>>>>> Behalf >>>>>> Of >>>>>>>> Joel >>>>>>>> M. Halpern >>>>>>>> Sent: Thursday, 08 March, 2012 13:17 >>>>>>>> To: scott.probasco@nokia.com >>>>>>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>>>>>>> chris.cheeseman@bt.com >>>>>>>> Subject: Re: [paws] WGLC for >>>>>>>> draft-ietf-paws-problem-stmt-usecases- >>>>>>>> rqmts-03: >>>>>>>> channel reporting >>>>>>>> >>>>>>>> So why won't the device simply say "I will use all of this?" >>>>>>>> [GC] This would defeat the purpose of the acknowledgement >message. >>>>>>>> After all, that way it needs to do less work with the database. >>>>>>>> And >>>>>> it >>>>>>>> can change frequencies when it wants. >>>>>>>> Given that the stated goal of the Ofcom requriement was to be >able >>>>>> to >>>>>>>> analyze interference effects, it seems that this will not >actually >>>>>> lead >>>>>>>> to them getting what they want, even if it does comply with the >>>>>>>> regulations. >>>>>>>> [GC] You got it. This would be useless for spectrum regulators. >>>>>>>> One should realize that, from the spectrum regulator's point of >>>>>>>> view, the >>>>>> second >>>>>>>> and >>>>>>>> third messages could be iterated upon to optimize the spectrum >>> use. >>>>>>>> Knowing >>>>>>>> what channels the systems in an area are using, the spectrum >>>>>> regulators >>>>>>>> and/or other entities such as those taking care of coexistence >>>>>>>> could use the database in near-real-time to iterate on the two >>>>>>>> last messages to reduce the range of channels that some systems >>>>>>>> may use once they know precisely what channels are being used in >>> the area. >>>>>>>> The PAWS protocol would carry >>>>>> the >>>>>>>> information back and forth but would not be involved in such >>>>>> spectrum >>>>>>>> use >>>>>>>> optimization. >>>>>>>> >>>>>>>> Yours, >>>>>>>> joel >>>>>>>> >>>>>>>> On 3/8/2012 1:09 PM, scott.probasco@nokia.com wrote: >>>>>>>>> Hi Peter, >>>>>>>>> >>>>>>>>> Answers below. >>>>>>>>> >>>>>>>>> Kind Regards, >>>>>>>>> Scott >>>>>>>>> >>>>>>>>> On 3/8/12 11:39 AM, "ext Peter Saint-Andre" >>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi Scott, I have two clarifying questions: >>>>>>>>>> >>>>>>>>>> 1. Does the device know, when it receives the channel >response, >>>>>>>> which >>>>>>>>>> channel it will actually use? >>>>>>>>> Scott->This is all new and I am not aware of any existing >>>>>>>> implementations. >>>>>>>>> I would argue that the device must decide what channel(s) it >>>>>>>>> will >>>>>> use >>>>>>>> when >>>>>>>>> it receives the channel response. >>>>>>>> [GC] Agree with Scott but this is only a portion of the >>>>>> considerations. >>>>>>>> If a >>>>>>>> device was to operate on its own, this would be true but a >>>>>>>> communication device usually implies at least 2 devices to >>>>>>>> communicate. Hence, the choice of the channel to be used will >need >>>>>>>> to be negotiated between the two devices before a choice can be >>>>>>>> made. The chosen channel will belong to the >>>>>> set >>>>>>>> of >>>>>>>> available channels that is common to both devices. Remember that >>>>>> some >>>>>>>> channels may be available at one device and not at the other >>>>>>>> because >>>>>> of >>>>>>>> their geolocation or other reason. Extending this concept to a >>>>>>>> star network topology, the channel that will be selected by this >>>>>>>> network will >>>>>> have >>>>>>>> to >>>>>>>> belong to the set of channels that are available to all devices. >>>>>> Each >>>>>>>> device >>>>>>>> will not be able to decide by itself which channel it wants to >>> use. >>>>>>>> >>>>>>>> This is why in such a star topology, it makes sense that the >slave >>>>>>>> devices to a base station or access point be represented by the >>>>>>>> base station acting as the master on their behalf to query the >>>>>>>> database and receive the list of available channels (and/or >>>>>>>> maximum EIRP per channel). It is then the responsibility of the >>>>>>>> base station to identify the set of available channels that is >>>>>>>> common for itself and all its slaves to decide on the >>>>>> channel >>>>>>>> that >>>>>>>> the network will use. As you can see, in this case, there is no >>>>>>>> need for each slave to receive its list of available channels. >On >>>>>>>> its own, it would not know what to do with it. The only thing >that >>>>>>>> needs to be sent >>>>>> from >>>>>>>> the >>>>>>>> master device to its slaves is the resulting operating channel. >>>>>>>> >>>>>>>> I a more sophisticated operation, the master device may add one >or >>>>>>>> a few backup channels extracted from the common set of available >>>>>>>> channel >>>>>> to >>>>>>>> the >>>>>>>> message going to its slave so that if a change in channel >>>>>> availability >>>>>>>> occurs, an instantaneous switch to the next backup channel can >be >>>>>> made >>>>>>>> without any further signaling, thus providing for a channel >switch >>>>>> that >>>>>>>> is >>>>>>>> transparent to the user. It is the scheme that has been included >>>>>>>> in >>>>>> the >>>>>>>> IEEE >>>>>>>> 802.22-2011 Standard. This is why I don't believe that PAWS >should >>>>>> get >>>>>>>> involved in defining this signaling between the base station and >>>>>>>> its slaves devices. >>>>>>>>>> >>>>>>>>>> 2. If the device then uses another channel or a different >>>>>> channel, >>>>>>>> does >>>>>>>>>> it need to report that change to the database? >>>>>>>>> Scott->My interpretation of section 3.18 is that the device can >>>>>> only >>>>>>>>> transmit within the upper& lower frequencies returned in the >>>>>>>>> acknowledgment. I do not (quickly) find any reference in the >>>>>>>> requirements >>>>>>>>> to changing channels. Thus operationally it could be that the >>>>>> channel >>>>>>>>> request process must be repeated before the device can use a >>>>>>>> different >>>>>>>>> channel (frequencies). >>>>>>>> [GC] If the process involves 2 messages, then, the device and >its >>>>>>>> associated devices could change channels at will as long as all >>>>>>>> these channels belong to the set of available channel. However, >if >>>>>>>> the third message is added, it would make sense that the master >>>>>>>> device reports to the database any channel change that would >occur >>>>>>>> to the database, otherwise, the status of >>>>>> the >>>>>>>> spectrum occupation would be wrong at any moment and would be >>>>>> useless >>>>>>>> for >>>>>>>> the purpose of any spectrum usage optimization such as >>> coexistence. >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>>> Peter >>>>>>>>>> >>>>>>>>>> On 3/8/12 10:17 AM, scott.probasco@nokia.com wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> The point from Brian is very relevant: >>>>>>>>>>> >>>>>>>>>>> Channel request >>>>>>>>>>> Channel response >>>>>>>>>>> Channel acknowledgement >>>>>>>>>>> >>>>>>>>>>> What Ofcom does with the information in the acknowledgement >>>>>>>>>>> does >>>>>>>> not >>>>>>>>>>> matter. As the regulator in UK, they write rules that must be >>>>>>>> followed >>>>>>>>>>> in >>>>>>>>>>> order to operate a whitespace radio in the UK. I believe the >>>>>> scope >>>>>>>> of >>>>>>>>>>> the >>>>>>>>>>> WG must be focused on a working solution. If this is simple >>>>>> channel >>>>>>>>>>> request& response in one regulator's domain, PAWS can >support >>>>>>>> this. If >>>>>>>>>>> it >>>>>>>>>>> means a channel request, response and acknowledgement in >>>>>>>>>>> another regulator's domain, PAWS can support this. As a >>>>>>>>>>> participating >>>>>>>> member of >>>>>>>>>>> the work group, I believe the scope should be basic working >>>>>>>> solution, >>>>>>>>>>> not >>>>>>>>>>> limited to a specific number of messages. >>>>>>>>>>> >>>>>>>>>>> Kind Regards, >>>>>>>>>>> Scott >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 3/8/12 11:11 AM, "ext Zuniga, Juan Carlos" >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Peter, Nancy, >>>>>>>>>>>> >>>>>>>>>>>> I agree should design a protocol with the best of our >current >>>>>>>>>>>> knowledge, and that should be accounting for all the known >>>>>>>>>>>> regulations at >>>>>>>> present >>>>>>>>>>>> time. We should not limit the scope with the purpose of >>>>>> designing >>>>>>>> a >>>>>>>>>>>> protocol 'faster'. Our goal is not only to design a WSDB >>>>>> protocol. >>>>>>>> Our >>>>>>>>>>>> goal is to design a WSDB protocol that is USEFUL to the >>>>>> community. >>>>>>>>>>>> >>>>>>>>>>>> The charter does state that >>>>>>>>>>>> >>>>>>>>>>>> "...the group should also reach out to other potential >>>>>>>>>>>> "customers" for a white space database access method and >>>>>> consider >>>>>>>> input >>>>>>>>>>>> from regulatory entities that are involved in the >>>>>>>>>>>> specification >>>>>> of >>>>>>>> the >>>>>>>>>>>> rules for secondary use of spectrum in specific radio bands. >" >>>>>>>>>>>> >>>>>>>>>>>> I think that is exactly what we are doing now. >>>>>>>>>>>> >>>>>>>>>>>> Regarding whether the types of requirements belong to #1 or >>>>>>>>>>>> #2, >>>>>> I >>>>>>>>>>>> believe >>>>>>>>>>>> it is more of #1 type, as the information to be exchanged >>>>>>>>>>>> would >>>>>> be >>>>>>>>>>>> known >>>>>>>>>>>> after the initial query/response. >>>>>>>>>>>> >>>>>>>>>>>> If we know it today, I see no reason why we should not work >>>>>>>>>>>> on >>>>>> it >>>>>>>> in >>>>>>>>>>>> the >>>>>>>>>>>> first phase of the work. >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> >>>>>>>>>>>> Juan Carlos >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] >>>>>>>>>>>>> On >>>>>>>> Behalf >>>>>>>>>>>>> Of >>>>>>>>>>>>> Peter Saint-Andre >>>>>>>>>>>>> Sent: Thursday, March 08, 2012 11:59 AM >>>>>>>>>>>>> To: Nancy Bravin >>>>>>>>>>>>> Cc: paws@ietf.org; johnny.dixon@bt.com; >>>>>> chris.cheeseman@bt.com; >>>>>>>> Pete >>>>>>>>>>>>> Resnick >>>>>>>>>>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- >>>>>>>> usecases- >>>>>>>>>>>>> rqmts-03: channel reporting >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Nancy, >>>>>>>>>>>>> >>>>>>>>>>>>> You are absolutely right that different locales will have >>>>>>>> different >>>>>>>>>>>>> rules and requirements. We need to understand those, and >>>>>>>>>>>>> work >>>>>> to >>>>>>>>>>>>> address >>>>>>>>>>>>> them if possible (although we don't necessarily need to >>>>>> address >>>>>>>> them >>>>>>>>>>>>> all >>>>>>>>>>>>> at the same time). I see several kinds of requirements: >>>>>>>>>>>>> >>>>>>>>>>>>> 1. Some requirements might lead to features beyond the >>>>>>>> query/response >>>>>>>>>>>>> protocol we've envisioned so far. One example might be >real- >>>>>> time >>>>>>>>>>>>> reporting about the channels that a device is actually >using. >>>>>> In >>>>>>>> my >>>>>>>>>>>>> opinion, it would be best to handle those in the next phase >>>>>>>>>>>>> of >>>>>>>> work, >>>>>>>>>>>>> because as far as I can see they are outside the scope of >>>>>>>>>>>>> our >>>>>>>> charter. >>>>>>>>>>>>> >>>>>>>>>>>>> 2. Some requirements might be handled through by defining >>>>>>>> additional >>>>>>>>>>>>> fields that can be included in the query or response. We >>>>>>>> definitely >>>>>>>>>>>>> planned for that when working on the charter with the IESG: >>>>>>>>>>>>> >>>>>>>>>>>>> In addition, the particular >>>>>>>>>>>>> data exchanged between a device and a database might >>>>>>>>>>>>> depend >>>>>> on >>>>>>>> the >>>>>>>>>>>>> ranges of radio spectrum that are to be used, the >>>>>> requirements >>>>>>>> of >>>>>>>>>>>>> the >>>>>>>>>>>>> database operators and their governing regulations, and >>>>>> other >>>>>>>>>>>>> factors. >>>>>>>>>>>>> Therefore, the database access method and the >>>>>> query/response >>>>>>>> data >>>>>>>>>>>>> formats that are exchanged using that method need to be >>>>>>>> designed >>>>>>>> for >>>>>>>>>>>>> extensibility rather than being tied to any specific >>>>>> spectrum, >>>>>>>>>>>>> country, or phy/mac/air interface. >>>>>>>>>>>>> >>>>>>>>>>>>> It's unclear to me right now if the Ofcom requirement fits >>>>>> into >>>>>>>> #1 or >>>>>>>>>>>>> #2, which is why we're having this discussion. :) >>>>>>>>>>>>> >>>>>>>>>>>>> Peter >>>>>>>>>>>>> >>>>>>>>>>>>> On 3/7/12 8:17 PM, Nancy Bravin wrote: >>>>>>>>>>>>>> Peter and all, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I agree that it is important to revisit now, so that in >the >>>>>>>> future, >>>>>>>>>>>>>> it will be easy to align things in their proper place. >>>>>>>>>>>>>> Every >>>>>>>> country >>>>>>>>>>>>>> may have different regulations, spectrum, policy and what >>>>>>>>>>>>>> responsibility is in the domain of the system, and what >>>>>>>>>>>>>> comes >>>>>>>> under >>>>>>>>>>>>>> the PAWS charter is important. Maybe some separation >might >>>>>> be >>>>>>>>>>>>>> possible, and dividing and clarifying issues now will help >>>>>>>>>>>>>> in >>>>>>>> the >>>>>>>>>>>>>> future. Certainly it seems that the FCC may change some >>>>>> rules, >>>>>>>> and >>>>>>>>>>>>>> we know that Ofcom is not yet finished with their >>>>>> regulations. >>>>>>>> Canada >>>>>>>>>>>>>> has their own, and other countries are working on this as >>>>>> well. >>>>>>>> Just >>>>>>>>>>>>>> a thought...Sharing is a realistic goal...as is off >>>>>> loading... >>>>>>>> Or you >>>>>>>>>>>>>> slim line and every 6 months decide what to incorporate in >>>>>> the >>>>>>>>>>>>>> protocol based on new information, new ideas, new >>>>>>>>>>>>>> innovation >>>>>> new >>>>>>>>>>>>>> regulations and maybe spend more time than you could if >>>>>>>> addressed >>>>>>>>>>>>>> now. >>>>>>>>>>>>>> >>>>>>>>>>>>>> That way you leave the door open and outside of >referencing >>>>>> what >>>>>>>> is >>>>>>>>>>>>>> known today, by referencing regulations i.e. Ofcom, FCC, >>>>>>>> Industry >>>>>>>>>>>>>> Canada etc as of XX-XX-XXXX date. Out of scope not >>>>>>>>>>>>>> something >>>>>> we >>>>>>>> know >>>>>>>>>>>>>> enough about to say at this point, In my opinion. >>>>>>>>>>>>>> >>>>>>>>>>>>>> My 2 cents.. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sincerely, Nancy >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> As your responsible Area Director (until March 28, when >>>>>>>>>>>>>>> Pete Resnick will take over from me), I have reviewed >this >>>>>> thread. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In my opinion (I am happy to be proven wrong), this new >>>>>>>> requirement >>>>>>>>>>>>>>> goes beyond what the charter defined as the scope of this >>>>>>>> working >>>>>>>>>>>>>>> group, which was to enable a device to discover the white >>>>>> space >>>>>>>>>>>>>>> available to it in its current location. Reporting usage >>>>>> back >>>>>>>> to >>>>>>>>>>>>>>> the database is simply not mentioned in the charter. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Earlier in this thread, Andy Sago wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There's no language I can find in the charter that >>>>>> explicitly >>>>>>>> puts >>>>>>>>>>>>>>> this out of scope. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> An IETF charter defines what the working group shall work >>>>>> on. >>>>>>>> Many >>>>>>>>>>>>>>> interesting features could be developed here. However, it >>>>>>>>>>>>>>> is >>>>>>>> not >>>>>>>>>>>>>>> the job of the charter to mention explicitly that each of >>>>>> those >>>>>>>>>>>>>>> interesting features is out of scope. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The charter does say: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Once the device learns of the available white space >(e.g., >>>>>> in a >>>>>>>> TV >>>>>>>>>>>>>>> white space implementation, the list of available >channels >>>>>> at >>>>>>>> that >>>>>>>>>>>>>>> location), it can then select one of the bands from the >>>>>>>>>>>>>>> list >>>>>>>> and >>>>>>>>>>>>>>> begin to transmit and receive on the selected band. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This text might have assumed that no further >communication >>>>>> or >>>>>>>>>>>>>>> authorization was required in order to select one of the >>>>>> bands >>>>>>>> from >>>>>>>>>>>>>>> the list and then transmit/receive. Perhaps that >>>>>>>>>>>>>>> assumption >>>>>> was >>>>>>>>>>>>>>> mistaken. If so, it would be good to have a discussion >>>>>>>>>>>>>>> about >>>>>>>> that, >>>>>>>>>>>>>>> so we can determine if we need to revisit the assumptions >>>>>>>>>>>>>>> we >>>>>>>> made >>>>>>>>>>>>>>> early on. If in fact we made some faulty or limited >>>>>>>> assumptions, >>>>>>>>>>>>>>> then let's get that out in the open. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Peter >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 3/7/12 9:40 AM, Rosen, Brian wrote: >>>>>>>>>>>>>>>> I'd also suggest >that >>>>>> our >>>>>>>>>>>>>>>> charter limitation is really support for sharing of >>>>>> whitespace >>>>>>>> by >>>>>>>>>>>>>>>> whitespace devices. Reporting what you use is not >>>>>>>>>>>>>>>> sharing, >>>>>>>> it's >>>>>>>>>>>>>>>> just data gathering. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The point of excluding sharing was to eliminate the >>>>>>>> complexities >>>>>>>>>>>>>>>> of what constituted fairness, and what kinds of >>>>>> communication >>>>>>>>>>>>>>>> might be needed between databases, where more than one >>>>>> could >>>>>>>>>>>>>>>> supply available whitespace in a band. This doesn't >have >>>>>> any >>>>>>>> of >>>>>>>>>>>>>>>> those issues, As long as it's just sending information, >I >>>>>>>> don't >>>>>>>>>>>>>>>> have a problem. Once the database is supposed to do >>>>>> anything >>>>>>>>>>>>>>>> with it that involves changing what spectrum it reports, >>>>>> then >>>>>>>> I >>>>>>>>>>>>>>>> think we cross the line. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Brian >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Mar 6, 2012, at 12:28 PM, >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Joel >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Indeed, the regulator has not described the process or >>>>>>>> provided >>>>>>>>>>>>>>>>> a flow diagram, so there may be some wrinkles, but we >>>>>>>>>>>>>>>>> need >>>>>> to >>>>>>>>>>>>>>>>> provide for their intent. To answer your question, the >>>>>>>> channels >>>>>>>>>>>>>>>>> that the master will use are sent in a separate message >>>>>>>>>>>>>>>>> (described in P.12 ter), that occurs after the master >>>>>>>> receives >>>>>>>>>>>>>>>>> the response to its channel request, but before the >>>>>>>>>>>>>>>>> master >>>>>>>> can >>>>>>>>>>>>>>>>> transmit. At this point, it knows what channels are >>>>>>>> available, >>>>>>>>>>>>>>>>> and which one it will use. As far as the slaves are >>>>>>>> concerned, >>>>>>>>>>>>>>>>> as they associate, the master will need to gather their >>>>>>>> details >>>>>>>>>>>>>>>>> and send further channel usage messages to the database >>>>>>>>>>>>>>>>> on their behalf. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Andy >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -----Original Message----- From: paws-bounces@ietf.org >>>>>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] On Behalf Of Joel M. >>>>>> Halpern >>>>>>>>>>>>>>>>> Sent: 06 March 2012 17:05 To: scott.probasco@nokia.com >>>>> Cc: >>>>>>>>>>>>>>>>> paws@ietf.org; Cheeseman,CJ,Chris,COD R; >>>>>> Dixon,JS,Johnny,COD >>>>>>>> R >>>>>>>>>>>>>>>>> Subject: Re: [paws] WGLC for >>>>>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel >>>>>>>>>>>>>>>>> reporting >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Ahh. I think I see where the request and my >>>>>>>>>>>>>>>>> understanding divurge. If the idea here is that the >>>>>>>>>>>>>>>>> master must provide, >>>>>> in >>>>>>>>>>>>>>>>> the request, an indication of what channels it expects >>>>>>>>>>>>>>>>> to >>>>>>>> use, >>>>>>>>>>>>>>>>> I can at least understand that. I will return to >>>>>> technical >>>>>>>>>>>>>>>>> concerns in a moment. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> However, when you say "provide channel usage >>>>>>>>>>>>>>>>> information, >>>>>> in >>>>>>>>>>>>>>>>> order to evaluate interference", what that says to me >is >>>>>>>>>>>>>>>>> providing, during operation, information as to what >>>>>> channels >>>>>>>>>>>>>>>>> are being used, and at what power levels. That is what >>>>>> would >>>>>>>>>>>>>>>>> be needed to analyze actual interference effects. And >>>>>>>>>>>>>>>>> that >>>>>> is >>>>>>>>>>>>>>>>> out of scope as I understand our scope. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I do see a technical difficulty with having the master >>>>>>>> provide, >>>>>>>>>>>>>>>>> as part of either registering or requesting spectrum >>>>>>>>>>>>>>>>> information, what channels it intends to use. It >>>>>>>>>>>>>>>>> doesn;t >>>>>>>> know >>>>>>>>>>>>>>>>> what channels it intends to use. It intends to use >some >>>>>>>> number >>>>>>>>>>>>>>>>> of available channels. It will figure out which ones >>>>>>>>>>>>>>>>> when >>>>>> it >>>>>>>>>>>>>>>>> is told what is available. How can it send that >>>>>> information >>>>>>>> in >>>>>>>>>>>>>>>>> the request? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: >>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> There is a similarity here with device ID. In context >>>>>>>>>>>>>>>>>> of >>>>>>>> PAWS >>>>>>>>>>>>>>>>>> we are not concerned with why a device ID is required >>>>>>>>>>>>>>>>>> by >>>>>> a >>>>>>>>>>>>>>>>>> regulator, we accept it is a requirement from a >>>>>>>>>>>>>>>>>> regulator >>>>>>>> and >>>>>>>>>>>>>>>>>> include it to the protocol. Ofcom identifies in 3.18& >>>>>> 3.19 >>>>>>>>>>>>>>>>>> that channel usage information is required and thus we >>>>>> need >>>>>>>>>>>>>>>>>> to include this information. Since the master must >>>>>> provide >>>>>>>>>>>>>>>>>> this information prior to transmitting, PAWS will not >>>>>>>>>>>>>>>>>> function in the UK without this information and thus I >>>>>>>>>>>>>>>>>> believe channel usage information is integral to the >>>>>> channel >>>>>>>>>>>>>>>>>> request& response messaging. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Kind Regards, Scott >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 3/6/12 10:30 AM, "ext Joel M. >>>>>>>>>>>>>>>>>> Halpern" wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I would draw a distinction. Ofcom regulations about >>>>>>>>>>>>>>>>>>> whitespace requests are very much relevant. Ofcom >>>>>>>>>>>>>>>>>>> regulations about notification of dynamic behavior >>>>>> (which >>>>>>>>>>>>>>>>>>> spectrum is being used) are not in scope as I >>>>>>>>>>>>>>>>>>> understand the earlier discussions, particularly the >>>>>>>>>>>>>>>>>>> chartering discussions. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com >wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> The ofcom requirements are very much relevant to the >>>>>>>>>>>>>>>>>>>> scope of the PAWS WG. The only other regulatory >>>>>>>>>>>>>>>>>>>> requirements that we have today is the FCC. Ofcom >>>>>>>>>>>>>>>>>>>> requirements are a good addition to the set. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -Raj >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 3/6/12 10:03 AM, "ext >>>>>>>>>>>>>>>>>>>> andy.sago@bt.com" wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hi Joel >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> There's no language I can find in the charter that >>>>>>>>>>>>>>>>>>>>> explicitly puts this out of scope. On the other >>>>>>>>>>>>>>>>>>>>> hand, the charter says that the group will >"consider >>>>>>>>>>>>>>>>>>>>> input from regulatory entities", and this is one of >>>>>>>>>>>>>>>>>>>>> the requirements from Ofcom that they have just >>>>> published. >>>>>>>>>>>>>>>>>>>>> The protocol will be worthless for the UK if it >>>>>>>>>>>>>>>>>>>>> omits some requirements. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Andy >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -----Original Message----- From: Joel M. Halpern >>>>>>>>>>>>>>>>>>>>> [mailto:jmh@joelhalpern.com] Sent: 06 March 2012 >>>>>>>>>>>>>>>>>>>>> 15:53 >>>>>>>>>>>>>>>>>>>>> To: Sago,AJ,Andy,COD R Cc: paws@ietf.org; >>>>>>>>>>>>>>>>>>>>> Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for >>>>>>>>>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: >>>>>> channel >>>>>>>>>>>>>>>>>>>>> reporting >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> As I understand, the information you are asking for >>>>>>>>>>>>>>>>>>>>> is explicitly out of scope for the working group. >>>>>>>>>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >>>>>>>>>>>>>>>>>>>>>> All >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Comparing the draft with the Ofcom requirements at >>>>>>>>>>>>>>>>>>>>>> http://www.cept.org/Documents/se- >>>>>>>>>>>>> 43/4161/SE43(12)Info03_Draft-UK-r >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> egul >>>>>>>>>>>>>>>>>>>>>> atory-requirements-for-white-space-devices-in-the- >>>>>> UHF- >>>>>>>> TV- >>>>>>>>>>>>> band, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> I believe the WG draft is deficient in the area of >reporting >>>>>>>>>>>>>>>>>>>>>> frequencies and powers actually used by masters >and >>>>>>>>>>>>>>>>>>>>>> slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom >>>>>>>>>>>>>>>>>>>>>> intends to collect this data to assesses the >impact >>>>>>>>>>>>>>>>>>>>>> of aggregate interference into other services. It >>>>>>>>>>>>>>>>>>>>>> would also provide usage information (frequency in >>>>>>>>>>>>>>>>>>>>>> use) that would inform the operation of a kill >>>>>>>>>>>>>>>>>>>>>> switch capability. I suggest this deficiency can >be >>>>>>>>>>>>>>>>>>>>>> remedied with the following changes: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> New P requirements (probably best placed following >>>>>>>>>>>>>>>>>>>>>> P.12): >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> P.12bis: The protocol MUST support a channel usage >>>>>>>>>>>>>>>>>>>>>> message from the slave device to the master >device. >>>>>>>>>>>>>>>>>>>>>> The channel usage message MUST include parameters >>>>>>>>>>>>>>>>>>>>>> as required by local regulatory requirement. >These >>>>>>>>>>>>>>>>>>>>>> parameters MAY include device ID, manufacturer's >>>>>>>>>>>>>>>>>>>>>> serial number, channel usage and power level >>>>>>>>>>>>>>>>>>>>>> information. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> P.12ter: The protocol MUST support a channel usage >>>>>>>>>>>>>>>>>>>>>> message from the master device to the database. >>>>>>>>>>>>>>>>>>>>>> The channel usage message MUST include parameters >>>>>>>>>>>>>>>>>>>>>> as required by local regulatory requirement for >the >>>>>>>>>>>>>>>>>>>>>> master and its associated slaves. These >parameters >>>>>>>>>>>>>>>>>>>>>> MAY include device ID, manufacturer's serial >>>>>>>>>>>>>>>>>>>>>> number, channel usage and power level information. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> P.12qua: The protocol MUST support a channel usage >>>>>>>>>>>>>>>>>>>>>> message acknowledgement. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> New O requirements (probably best placed following >>>>>>>>>>>>>>>>>>>>>> O13): >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> O.13bis: According to local regulatory policy, >>>>>>>>>>>>>>>>>>>>>> after connecting to a master device's radio >network >>>>>>>>>>>>>>>>>>>>>> a slave device MAY inform the master device of the >>>>>>>>>>>>>>>>>>>>>> actual channel usage. The slave MUST include >>>>>>>>>>>>>>>>>>>>>> parameters required by local regulatory policy, >e.g. >>>>>>>>>>>>>>>>>>>>>> device ID, manufacturer's serial number, channel >>>>>>>>>>>>>>>>>>>>>> usage and power level information. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> O.13ter: According to local regulatory policy, a >>>>>>>>>>>>>>>>>>>>>> master device MAY inform the database of the >actual >>>>>>>>>>>>>>>>>>>>>> channel usage of the master and its slaves. The >>>>>>>>>>>>>>>>>>>>>> master MUST include parameters required by local >>>>>>>>>>>>>>>>>>>>>> regulatory policy, e.g. device ID, manufacturer's >>>>>>>>>>>>>>>>>>>>>> serial number, channel usage and power level >>>>>>>>>>>>>>>>>>>>>> information of the master and its slaves. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> New steps could be introduced into one or more use >>>>>>>>>>>>>>>>>>>>>> cases to cover these Ofcom requirements, e.g. new >>>>>>>>>>>>>>>>>>>>>> steps 6bis and 9bis in the hotspot use case at >>>>>>>>>>>>>>>>>>>>>> 4.2.1: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 6bis. Prior to initiating transmission, if >required >>>>>>>>>>>>>>>>>>>>>> by local regulation, the master/AP informs the >>>>>>>>>>>>>>>>>>>>>> database of the channel and power level it has >>>>>>>>>>>>>>>>>>>>>> chosen. This is repeated for each slave that >>>>>>>>>>>>>>>>>>>>>> associated with the master. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 9bis. Prior to initiating transmission, if >required >>>>>>>>>>>>>>>>>>>>>> by local regulation, the slave informs the >>>>>>>>>>>>>>>>>>>>>> master/AP of the channel and power level it has >>>>>>>>>>>>>>>>>>>>>> chosen, and the master/AP relays this information >>>>>>>>>>>>>>>>>>>>>> to the >>>>> database. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> - end of new text - >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> For information, for those not accessing the url >in >>>>>>>>>>>>>>>>>>>>>> the first paragraph of this email, the full Ofcom >>>>>>>>>>>>>>>>>>>>>> requirements leading to this new PAWS text are as >>>>>>>>>>>>>>>>>>>>>> follows: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 3.18 After receiving instructions from a WSDB in >>>>>>>>>>>>>>>>>>>>>> relation to the maximum permitted EIRPs over the >>>>>>>>>>>>>>>>>>>>>> DTT channels, and prior to initiating >transmissions >>>>>>>>>>>>>>>>>>>>>> within the UHF TV band, a master WSD must >>>>>>>>>>>>>>>>>>>>>> communicate to the WSDB the following information: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 3.18.1 The lower and upper frequency boundaries^13 >>>>>>>>>>>>>>>>>>>>>> of the in-block emissions of the master WSD, and >>>>>>>>>>>>>>>>>>>>>> those of the in-block emissions of its associated >>>>>>>>>>>>>>>>>>>>>> slaves. A lower frequency will be specified as >(470 >>>>>>>>>>>>>>>>>>>>>> + 8k + >>>>>>>>>>>>>>>>>>>>>> 0.2n) MHz, with the corresponding upper frequency >>>>>>>>>>>>>>>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3?4 k >>>>> 3?4 >>>>>>>>>>>>>>>>>>>>>> 39, 0 3?4 n 3?4 39, 1 3?4 m 3?4 40, and n< m. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 3.18.2 The maximum in-block EIRP spectral >densities >>>>>>>>>>>>>>>>>>>>>> (in dBm/(0.2 MHz)) that the master WSD, and its >>>>>>>>>>>>>>>>>>>>>> associated slaves, actually radiate between each >>>>>>>>>>>>>>>>>>>>>> reported lower frequency boundary and its >>>>>>>>>>>>>>>>>>>>>> corresponding upper frequency boundary. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Footnote 13 states: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> The use of upper and lower frequency boundaries >>>>>>>>>>>>>>>>>>>>>> (defined over a 200 kHz raster) allows a WSDB to >>>>>>>>>>>>>>>>>>>>>> collect more granular information with regards to >>>>>>>>>>>>>>>>>>>>>> the usage of the frequency resource by narrowband >>>>>>>>>>>>>>>>>>>>>> WSD technologies. The upper and lower frequencies >>>>>>>>>>>>>>>>>>>>>> of a boundary pair do not straddle a DTT channel >>>>> boundary. >>>>>>>>>>>>>>>>>>>>>> Note that a WSD may transmit over multiple, >>>>>>>>>>>>>>>>>>>>>> non-contiguous, whole DTT channels or fractions of >>>>>>>>>>>>>>>>>>>>>> DTT channels. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 3.19 A master WSD must be able to receive the >>>>>>>>>>>>>>>>>>>>>> following information^14 from a WSDB: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in >the >>>>>>>>>>>>>>>>>>>>>> context of 3.18, that the reported information on >>>>>>>>>>>>>>>>>>>>>> the DTT channels and EIRP spectral densities >>>>>>>>>>>>>>>>>>>>>> actually used by the master and slave WSDs were >>>>>>>>>>>>>>>>>>>>>> received successfully by the WSDB^18 ]. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Footnote 14 states: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 14 While the communication of some of this >>>>>>>>>>>>>>>>>>>>>> information from a WSDB to a master WSD is >>>>>>>>>>>>>>>>>>>>>> optional, master WSDs must be able to receive and >>>>>>>>>>>>>>>>>>>>>> interpret these. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Footnote 18 states: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 18 This forms part of a handshake protocol and may >>>>>>>>>>>>>>>>>>>>>> be an area where industry could harmonise without >>>>>>>>>>>>>>>>>>>>>> the need for an explicit requirement in the >>>>> regulations. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Andy >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> *From:*paws-bounces@ietf.org >>>>>>>>>>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] *On Behalf Of >>>>>>>>>>>>>>>>>>>>>> *Gabor.Bajko@nokia.com *Sent:* 05 March 2012 19:46 >>>>>>>>>>>>>>>>>>>>>> *To:* paws@ietf.org *Subject:* [paws] WGLC for >>>>>>>>>>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> The authors of the use cases and requirements >draft >>>>>>>>>>>>>>>>>>>>>> have just posted a new version of the draft and >>>>>>>>>>>>>>>>>>>>>> indicated that there are no unresolved >>>>>>>>>>>>>>>>>>>>>> comments/issues they are aware of. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Therefore, I'd like to initiate a WG Last Call for >>>>>>>>>>>>>>>>>>>>>> comments on >>>>>>>>>>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf- >paws >>>>>>>>>>>>>>>>>>>>>> - >>>>>>>> problem- >>>>>>>>>>>>> stmt-u >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> seca >>>>>>>>>>>>>>>>>>>>>> ses-rqmts-03.txt >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Please review the draft and send your comments to >>>>>>>>>>>>>>>>>>>>>> the list by March 20th, 2012. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> If you review the draft and have no comments, send >>>>>>>>>>>>>>>>>>>>>> a note to the list that the draft is good as it >is, >>>>>>>>>>>>>>>>>>>>>> we need these notes as much as we need the actual >>>>>>>>>>>>>>>>>>>>>> comments. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks, Gabor >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> paws mailing list >>>>>>>>> paws@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> paws mailing list >>>>>>>> paws@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> paws mailing list >>>>>>>> paws@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>>> ________________________________ >>>>> >>>>> >>> >*********************************************************************** >>>>> * >>>>> ****************************************** >>>>> For more information visit www.ofcom.org.uk >>>>> >>>>> This email (and any attachments) is confidential and intended for >the >>>>> use of the addressee only. >>>>> >>>>> If you have received this email in error please notify the >originator >>>>> of the message and delete it from your system. >>>>> >>>>> This email has been scanned for viruses. However, you open any >>>>> attachments at your own risk. >>>>> >>>>> Any views expressed in this message are those of the individual >>> sender >>>>> and do not represent the views or opinions of Ofcom unless >expressly >>>>> stated otherwise. >>>>> >>> >*********************************************************************** >>>>> * >>>>> ****************************************** >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws From brian.rosen@neustar.biz Mon Mar 19 13:08:26 2012 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 35D6121F87CB for ; Mon, 19 Mar 2012 13:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.718 X-Spam-Level: X-Spam-Status: No, score=-4.718 tagged_above=-999 required=5 tests=[AWL=-0.746, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4, 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 v0CJVHVaLo9W for ; Mon, 19 Mar 2012 13:08:19 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 60FD121F87C7 for ; Mon, 19 Mar 2012 13:08:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1332187733; x=1647542439; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=KwJKFf/Lrl55axfCinwYb r1ZHe1bplXmYGCdxNep44I=; b=YZ5B9e5DBY9kE0SrbHYp4zDaEywzT9vsn7mOy WvgSqRqT7B2frdINl0sIsYJLhBrp3cUOGlRHUSuWttZrTpdwg== Received: from ([10.31.13.242]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.5774087; Mon, 19 Mar 2012 16:08:52 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Mon, 19 Mar 2012 16:08:13 -0400 From: "Rosen, Brian" To: Paul Lambert Date: Mon, 19 Mar 2012 16:08:12 -0400 Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting Thread-Index: Ac0GDANl49tVVXHtS8iUkyf8OArZCg== Message-ID: References: , <7BAC95F5A7E67643AAFB2C31BEE662D0157A034B37@SC-VEXCH2.marvell.com> <4F5A28F7.4070905@joelhalpern.com> <7BAC95F5A7E67643AAFB2C31BEE662D0157A034D48@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D015E331E56C@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D015E331E56C@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: x-ems-stamp: 7aNLL19wWnXW2zizWxUKxg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Reza.Karimi@ofcom.org.uk" , "paws@ietf.org" , "johnny.dixon@bt.com" , "presnick@qualcomm.com" Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting 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, 19 Mar 2012 20:08:26 -0000 Depends on the time period allowed for the ack. The device won't start another transaction with the database before it deci= des. The db doesn't have anything except a bit of state to keep if the ack takes= a while. So, let it take a while. Eventually, it would decide it wasn't going to get an answer and treat it l= ike an error (timeout). While we have to deal with charter issues, I don't like producing a protoco= l spec that only works with the US rules. Tracking usage is not an unreaso= nable regulatory requirement, and not a complicated protocol mechanism. It= only gets complicated when the spectrum returned from any query depends on= the usage information. That's somewhere I don't want to go yet. Let's assume, at least for now, that this subject is out of scope. We'll h= ave a discussion of what to do in Paris, and bring that back to the list. = Let's move forward on the document without this capability, and we'll pick = it up later if/when we get the charter issue settled. That means I would like to stop discussion until Paris, and then we will co= ntinue it on the list. Brian On Mar 19, 2012, at 2:58 PM, Paul Lambert wrote: > >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >> Sent: Monday, March 19, 2012 8:17 AM >> To: Paul Lambert >> Cc: Joel M. Halpern; chris.cheeseman@bt.com; Reza.Karimi@ofcom.org.uk; >> paws@ietf.org; johnny.dixon@bt.com; presnick@qualcomm.com >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >> rqmts-03:channel reporting >> >> >> Remembering that so far, it appears this discussion is out of scope: >> >> While it may be the case that devices dynamically change their choice of >> what "channels" they will use between queries of the database, it's at >> least equally likely that it will get the list of available channels, >> choose one, and stick to it. If they wanted to change at some point, it >> seems very feasible to query the database again, since the available >> spectrum may have changed. >> >> The device can't tell the database what it's going to use before it >> knows what is available. >> >> The "ack" sequence would be: >> Device to DB: What could I use at location x,y? >> DB to Device: You could use channels 3, 11 or 15 >> Device to DB: Okay, I'll use channel 11 > > But the "ack" in this sequence occurs right after the "you could use" mes= sage. Any intelligent AP/Master might some time to evaluate each channel a= nd pick one later that has the lowest utilization. It would not have this = knowledge in time for an "ack". If it picked a channel for the ack, it wou= ld likely change soon to another channel. > > Given that the "ack" has only informative information that will change - = there is nothing useful that can be done by the DB with this information. = Unless the Master provides continuous updates of channel utilization - ther= e is no reason to have this information carried in an ack. > > We should not create extra messages to carry information that will not be= used in any processing. > > Paul > > >> >> Brian >> >> On Mar 9, 2012, at 6:58 PM, Paul Lambert wrote: >> >>> >>> >>> +1 to all of Joels comments >>> >>> Why would a third ack message ever be different from the original >> request? >>> >>> There's been no time to connect clients or make any other interesting >> choices that would change the way the spectrum would be used. The ack >> is a useless message and any such informative information about the >> capabilities or plans of a device to use a range of spectrum should have >> been carried in the first message. >>> >>> >>> Paul >>> >>>> -----Original Message----- >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>> Sent: Friday, March 09, 2012 8:00 AM >>>> To: chris.cheeseman@bt.com >>>> Cc: Paul Lambert; sdas@appcomsci.com; SiewYoon.Tan@ofcom.org.uk; >>>> JuanCarlos.Zuniga@InterDigital.com; Basavaraj.Patil@nokia.com; >>>> gerald.chouinard@sympatico.ca; scott.probasco@nokia.com; >> paws@ietf.org; >>>> presnick@qualcomm.com; Reza.Karimi@ofcom.org.uk; johnny.dixon@bt.com >>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >>>> rqmts-03:channel reporting >>>> >>>> I am having trouble connecting the goal of the requirement, the >> expected >>>> protocol behavior, and the expected real-world operation. >>>> >>>> Lets keep it simple. A master, connected by wired internet to the >>>> World. A set of slaves who want to use whitespace to talk to the >>>> master. All within a small physical space. All within the the time >>>> limit of whatever answer the master gets from the database. >>>> >>>> The Ofcom requirement is described as being important for >> understanding >>>> interference effects. Therefore, presumably, it needs to relate to >>>> actual spectrum usage. >>>> >>>> The stated protocol behavior is that the master would reply to the >>>> shitespace database with an ack indicating what it expects to use, at >>>> what power level. >>>> The way folks are writing this, I believe the intention is "respond >>>> once". >>>> >>>> As I understand such master / slave behavior (and I am by no means a >>>> radio expert), the actual usage of spectrum, within the whitespace >> band, >>>> will depend upon how many slaves are active, and possibly on what >> they >>>> are doing. >>>> >>>> If the actual usage is going to depend upon the slave device >> population >>>> / behavior, then the only answer the master can correctly provide is >> "I >>>> will use all of the whitespace you have identified, with the highest >>>> power I might use. >>>> >>>> Such an answer is a valid answer in terms of protocol and in terms of >>>> the stated regulatory requirements. However, it is utterly useless >> in >>>> terms of the stated goal. >>>> As an engineer, I am very uncomfortable designing a protocol >> messaging >>>> exchange which I know will not meet the end-users needs. >>>> >>>> Note1: If I have mischaracterized ro misunderstood what folks ahve >>>> explained, I apologize. >>>> >>>> Note2: If instead the intention is for the master to update the >> database >>>> every time it changes the spectrum usage pattern, then this is NOT an >>>> acknowledgment of the reply from the database. It is a dynamic >> behavior >>>> reporting requirement. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 3/9/2012 6:36 AM, chris.cheeseman@bt.com wrote: >>>>> Hi >>>>> >>>>> My reading of the UK regulatory requirements that Ofcom has made >>>> available is that the Acknowledgement message that must be >> communicated >>>> back to the database from the white space device is simply the >> frequency >>>> range (or ranges) and maximum eirp density that the device intends to >>>> use (a subset of what it would have been offered by the database). I >>>> don't believe there is any intent to limit modulation schemes etc. as >>>> part of this exchange. This seems a relatively straightforward >>>> requirement and the PAWS protocol should accommodate this if it is to >> be >>>> relevant for the UK regulatory environment. >>>>> >>>>> Regards, >>>>> >>>>> Chris >>>>> >>>>> -----Original Message----- >>>>> From: Paul Lambert [mailto:paul@marvell.com] >>>>> Sent: 09 March 2012 02:15 >>>>> To: Das, Subir; 'Siew Yoon Tan'; Zuniga, Juan Carlos; >>>> Basavaraj.Patil@nokia.com; gerald.chouinard@sympatico.ca; >>>> jmh@joelhalpern.com; scott.probasco@nokia.com >>>>> Cc: paws@ietf.org; presnick@qualcomm.com; Reza Karimi; >>>> Dixon,JS,Johnny,COD R; Cheeseman,CJ,Chris,COD R >>>>> Subject: RE: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >>>> rqmts-03:channel reporting >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> I have a question here. Is it really an acknowledgement or we would >>>>>> like to see a kind of notification message that includes channel, >> and >>>>>> other parameters? >>>>> >>>>> What if it's multiple channels? What happens if the device adapts >> and >>>> changes between modulation technique or bandwidth? Does every change >>>> over the air need to be indicated to the GDB? >>>>> >>>>> This Channel acknowledgement does not seem useful and would limit >> real >>>> world behaviors (like channel and modulation adaptation). >>>>> >>>>> If viewed as a potential regulatory requirement - does this imply we >>>> need to parameterize the protocol to have different behaviors in >>>> different regions? >>>>> >>>>> Paul >>>>> >>>>> >>>>> >>>>>> >>>>>> Regards, >>>>>> _Subir >>>>>> >>>>>> -----Original Message----- >>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >> Behalf >>>> Of >>>>>> Siew Yoon Tan >>>>>> Sent: Thursday, March 08, 2012 4:06 PM >>>>>> To: Zuniga, Juan Carlos; Basavaraj.Patil@nokia.com; >>>>>> gerald.chouinard@sympatico.ca; jmh@joelhalpern.com; >>>>>> scott.probasco@nokia.com >>>>>> Cc: paws@ietf.org; presnick@qualcomm.com; Reza Karimi; >>>>>> johnny.dixon@bt.com; chris.cheeseman@bt.com >>>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >>>>>> rqmts-03:channel reporting >>>>>> >>>>>> Dear All, >>>>>> >>>>>> Regarding Ofcom's requirement to have a return channel as part of >> the >>>>>> protocol between the WSD and WSDB, I would like to confirm to >>>> following >>>>>> sequence of messaging >>>>>> >>>>>> Channel request >>>>>> Channel response >>>>>> Channel acknowledgement >>>>>> >>>>>> which was raised in an earlier email to this list. >>>>>> >>>>>> Our view is that it would be beneficial to define the protocol >>>> between >>>>>> WSD and WSDB that supports this requirement even though how the >>>>>> information could be used is still subject to discussion in the UK. >>>>>> >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Siew Yoon >>>>>> >>>>>> >>>>>> ________________________________________ >>>>>> From: paws-bounces@ietf.org [paws-bounces@ietf.org] on behalf of >>>>>> Zuniga, Juan Carlos [JuanCarlos.Zuniga@InterDigital.com] >>>>>> Sent: 08 March 2012 20:41 >>>>>> To: Basavaraj.Patil@nokia.com; gerald.chouinard@sympatico.ca; >>>>>> jmh@joelhalpern.com; scott.probasco@nokia.com >>>>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>>>>> chris.cheeseman@bt.com >>>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- >>>> usecases- >>>>>> rqmts-03:channel reporting >>>>>> >>>>>> Hi Raj, >>>>>> >>>>>> I was reusing the language used from Gerald (which I know is >> familiar >>>>>> to people working on IEEE 802 WS groups): >>>>>> >>>>>>>> [GC] You got it. This would be useless for spectrum regulators. >>>> One >>>>>>>> should realize that, from the spectrum regulator's point of view, >>>>>>>> the second and third messages could be iterated upon to optimize >>>> the >>>>>>>> spectrum use. >>>>>>>> Knowing >>>>>>>> what channels the systems in an area are using, the spectrum >>>>>>>> regulators and/or other entities such as those taking care of >>>>>>>> coexistence could use the database in near-real-time to iterate >> on >>>>>>>> the two last messages to reduce the range of channels that some >>>>>>>> systems may use once they know precisely what channels are being >>>>>>>> used in the area. The PAWS protocol would carry the information >>>> back >>>>>>>> and forth but would not be involved in such spectrum use >>>> optimization. >>>>>> >>>>>> Having said that, I have no issue sticking to the WSDB terminology. >> I >>>>>> like keeping things simple :) >>>>>> >>>>>> JC >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] >>>>>>> Sent: Thursday, March 08, 2012 3:33 PM >>>>>>> To: Zuniga, Juan Carlos; gerald.chouinard@sympatico.ca; >>>>>>> jmh@joelhalpern.com; scott.probasco@nokia.com >>>>>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>>>>>> chris.cheeseman@bt.com >>>>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- >> usecases- >>>>>>> rqmts-03:channel reporting >>>>>>> >>>>>>> >>>>>>> Hi JC, >>>>>>> >>>>>>> Where/why did the coexistence manager come into the picture? Your >>>>>>> comment about "communicating back to the WSDB/coexistence manager" >>>>>>> may result in further misunderstanding. If we simply stick to to >>>> WSDB >>>>>>> I think we are okay. >>>>>>> >>>>>>> -Raj >>>>>>> >>>>>>> On 3/8/12 2:25 PM, "ext Zuniga, Juan Carlos" >>>>>>> wrote: >>>>>>> >>>>>>>> So, from Gerald and Andy's comments, it seems like from the point >>>> of >>>>>>> view >>>>>>>> of (at least) two regulatory entities it is important for the >>>>>>>> protocol >>>>>>> to >>>>>>>> allow communicating back to the WSDB/coexistence manager the >> actual >>>>>>>> channel usage after the first query is made. >>>>>>>> >>>>>>>> This is to me a very clear requirement. >>>>>>>> >>>>>>>> The actual messages/IEs that would carry this information should >> be >>>>>>>> discussed as part of the solution document, and not the >>>> requirements. >>>>>>>> >>>>>>>> JC >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >>>>>>>>> Behalf >>>>>>> Of >>>>>>>>> Gerald Chouinard >>>>>>>>> Sent: Thursday, March 08, 2012 1:59 PM >>>>>>>>> To: 'Joel M. Halpern'; scott.probasco@nokia.com >>>>>>>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>>>>>>>> chris.cheeseman@bt.com >>>>>>>>> Subject: Re: [paws] WGLC for >>>>>>>>> draft-ietf-paws-problem-stmt-usecases- >>>>>>>>> rqmts-03:channel reporting >>>>>>>>> >>>>>>>>> Joel, Scott, >>>>>>>>> >>>>>>>>> Interesting discussion! See my comments in line below. >>>>>>>>> >>>>>>>>> Gerald >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >>>>>>>>> Behalf >>>>>>> Of >>>>>>>>> Joel >>>>>>>>> M. Halpern >>>>>>>>> Sent: Thursday, 08 March, 2012 13:17 >>>>>>>>> To: scott.probasco@nokia.com >>>>>>>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>>>>>>>> chris.cheeseman@bt.com >>>>>>>>> Subject: Re: [paws] WGLC for >>>>>>>>> draft-ietf-paws-problem-stmt-usecases- >>>>>>>>> rqmts-03: >>>>>>>>> channel reporting >>>>>>>>> >>>>>>>>> So why won't the device simply say "I will use all of this?" >>>>>>>>> [GC] This would defeat the purpose of the acknowledgement >> message. >>>>>>>>> After all, that way it needs to do less work with the database. >>>>>>>>> And >>>>>>> it >>>>>>>>> can change frequencies when it wants. >>>>>>>>> Given that the stated goal of the Ofcom requriement was to be >> able >>>>>>> to >>>>>>>>> analyze interference effects, it seems that this will not >> actually >>>>>>> lead >>>>>>>>> to them getting what they want, even if it does comply with the >>>>>>>>> regulations. >>>>>>>>> [GC] You got it. This would be useless for spectrum regulators. >>>>>>>>> One should realize that, from the spectrum regulator's point of >>>>>>>>> view, the >>>>>>> second >>>>>>>>> and >>>>>>>>> third messages could be iterated upon to optimize the spectrum >>>> use. >>>>>>>>> Knowing >>>>>>>>> what channels the systems in an area are using, the spectrum >>>>>>> regulators >>>>>>>>> and/or other entities such as those taking care of coexistence >>>>>>>>> could use the database in near-real-time to iterate on the two >>>>>>>>> last messages to reduce the range of channels that some systems >>>>>>>>> may use once they know precisely what channels are being used in >>>> the area. >>>>>>>>> The PAWS protocol would carry >>>>>>> the >>>>>>>>> information back and forth but would not be involved in such >>>>>>> spectrum >>>>>>>>> use >>>>>>>>> optimization. >>>>>>>>> >>>>>>>>> Yours, >>>>>>>>> joel >>>>>>>>> >>>>>>>>> On 3/8/2012 1:09 PM, scott.probasco@nokia.com wrote: >>>>>>>>>> Hi Peter, >>>>>>>>>> >>>>>>>>>> Answers below. >>>>>>>>>> >>>>>>>>>> Kind Regards, >>>>>>>>>> Scott >>>>>>>>>> >>>>>>>>>> On 3/8/12 11:39 AM, "ext Peter Saint-Andre" >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Scott, I have two clarifying questions: >>>>>>>>>>> >>>>>>>>>>> 1. Does the device know, when it receives the channel >> response, >>>>>>>>> which >>>>>>>>>>> channel it will actually use? >>>>>>>>>> Scott->This is all new and I am not aware of any existing >>>>>>>>> implementations. >>>>>>>>>> I would argue that the device must decide what channel(s) it >>>>>>>>>> will >>>>>>> use >>>>>>>>> when >>>>>>>>>> it receives the channel response. >>>>>>>>> [GC] Agree with Scott but this is only a portion of the >>>>>>> considerations. >>>>>>>>> If a >>>>>>>>> device was to operate on its own, this would be true but a >>>>>>>>> communication device usually implies at least 2 devices to >>>>>>>>> communicate. Hence, the choice of the channel to be used will >> need >>>>>>>>> to be negotiated between the two devices before a choice can be >>>>>>>>> made. The chosen channel will belong to the >>>>>>> set >>>>>>>>> of >>>>>>>>> available channels that is common to both devices. Remember that >>>>>>> some >>>>>>>>> channels may be available at one device and not at the other >>>>>>>>> because >>>>>>> of >>>>>>>>> their geolocation or other reason. Extending this concept to a >>>>>>>>> star network topology, the channel that will be selected by this >>>>>>>>> network will >>>>>>> have >>>>>>>>> to >>>>>>>>> belong to the set of channels that are available to all devices. >>>>>>> Each >>>>>>>>> device >>>>>>>>> will not be able to decide by itself which channel it wants to >>>> use. >>>>>>>>> >>>>>>>>> This is why in such a star topology, it makes sense that the >> slave >>>>>>>>> devices to a base station or access point be represented by the >>>>>>>>> base station acting as the master on their behalf to query the >>>>>>>>> database and receive the list of available channels (and/or >>>>>>>>> maximum EIRP per channel). It is then the responsibility of the >>>>>>>>> base station to identify the set of available channels that is >>>>>>>>> common for itself and all its slaves to decide on the >>>>>>> channel >>>>>>>>> that >>>>>>>>> the network will use. As you can see, in this case, there is no >>>>>>>>> need for each slave to receive its list of available channels. >> On >>>>>>>>> its own, it would not know what to do with it. The only thing >> that >>>>>>>>> needs to be sent >>>>>>> from >>>>>>>>> the >>>>>>>>> master device to its slaves is the resulting operating channel. >>>>>>>>> >>>>>>>>> I a more sophisticated operation, the master device may add one >> or >>>>>>>>> a few backup channels extracted from the common set of available >>>>>>>>> channel >>>>>>> to >>>>>>>>> the >>>>>>>>> message going to its slave so that if a change in channel >>>>>>> availability >>>>>>>>> occurs, an instantaneous switch to the next backup channel can >> be >>>>>>> made >>>>>>>>> without any further signaling, thus providing for a channel >> switch >>>>>>> that >>>>>>>>> is >>>>>>>>> transparent to the user. It is the scheme that has been included >>>>>>>>> in >>>>>>> the >>>>>>>>> IEEE >>>>>>>>> 802.22-2011 Standard. This is why I don't believe that PAWS >> should >>>>>>> get >>>>>>>>> involved in defining this signaling between the base station and >>>>>>>>> its slaves devices. >>>>>>>>>>> >>>>>>>>>>> 2. If the device then uses another channel or a different >>>>>>> channel, >>>>>>>>> does >>>>>>>>>>> it need to report that change to the database? >>>>>>>>>> Scott->My interpretation of section 3.18 is that the device can >>>>>>> only >>>>>>>>>> transmit within the upper& lower frequencies returned in the >>>>>>>>>> acknowledgment. I do not (quickly) find any reference in the >>>>>>>>> requirements >>>>>>>>>> to changing channels. Thus operationally it could be that the >>>>>>> channel >>>>>>>>>> request process must be repeated before the device can use a >>>>>>>>> different >>>>>>>>>> channel (frequencies). >>>>>>>>> [GC] If the process involves 2 messages, then, the device and >> its >>>>>>>>> associated devices could change channels at will as long as all >>>>>>>>> these channels belong to the set of available channel. However, >> if >>>>>>>>> the third message is added, it would make sense that the master >>>>>>>>> device reports to the database any channel change that would >> occur >>>>>>>>> to the database, otherwise, the status of >>>>>>> the >>>>>>>>> spectrum occupation would be wrong at any moment and would be >>>>>>> useless >>>>>>>>> for >>>>>>>>> the purpose of any spectrum usage optimization such as >>>> coexistence. >>>>>>>>>>> >>>>>>>>>>> Thanks! >>>>>>>>>>> >>>>>>>>>>> Peter >>>>>>>>>>> >>>>>>>>>>> On 3/8/12 10:17 AM, scott.probasco@nokia.com wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> The point from Brian is very relevant: >>>>>>>>>>>> >>>>>>>>>>>> Channel request >>>>>>>>>>>> Channel response >>>>>>>>>>>> Channel acknowledgement >>>>>>>>>>>> >>>>>>>>>>>> What Ofcom does with the information in the acknowledgement >>>>>>>>>>>> does >>>>>>>>> not >>>>>>>>>>>> matter. As the regulator in UK, they write rules that must be >>>>>>>>> followed >>>>>>>>>>>> in >>>>>>>>>>>> order to operate a whitespace radio in the UK. I believe the >>>>>>> scope >>>>>>>>> of >>>>>>>>>>>> the >>>>>>>>>>>> WG must be focused on a working solution. If this is simple >>>>>>> channel >>>>>>>>>>>> request& response in one regulator's domain, PAWS can >> support >>>>>>>>> this. If >>>>>>>>>>>> it >>>>>>>>>>>> means a channel request, response and acknowledgement in >>>>>>>>>>>> another regulator's domain, PAWS can support this. As a >>>>>>>>>>>> participating >>>>>>>>> member of >>>>>>>>>>>> the work group, I believe the scope should be basic working >>>>>>>>> solution, >>>>>>>>>>>> not >>>>>>>>>>>> limited to a specific number of messages. >>>>>>>>>>>> >>>>>>>>>>>> Kind Regards, >>>>>>>>>>>> Scott >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 3/8/12 11:11 AM, "ext Zuniga, Juan Carlos" >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Peter, Nancy, >>>>>>>>>>>>> >>>>>>>>>>>>> I agree should design a protocol with the best of our >> current >>>>>>>>>>>>> knowledge, and that should be accounting for all the known >>>>>>>>>>>>> regulations at >>>>>>>>> present >>>>>>>>>>>>> time. We should not limit the scope with the purpose of >>>>>>> designing >>>>>>>>> a >>>>>>>>>>>>> protocol 'faster'. Our goal is not only to design a WSDB >>>>>>> protocol. >>>>>>>>> Our >>>>>>>>>>>>> goal is to design a WSDB protocol that is USEFUL to the >>>>>>> community. >>>>>>>>>>>>> >>>>>>>>>>>>> The charter does state that >>>>>>>>>>>>> >>>>>>>>>>>>> "...the group should also reach out to other potential >>>>>>>>>>>>> "customers" for a white space database access method and >>>>>>> consider >>>>>>>>> input >>>>>>>>>>>>> from regulatory entities that are involved in the >>>>>>>>>>>>> specification >>>>>>> of >>>>>>>>> the >>>>>>>>>>>>> rules for secondary use of spectrum in specific radio bands. >> " >>>>>>>>>>>>> >>>>>>>>>>>>> I think that is exactly what we are doing now. >>>>>>>>>>>>> >>>>>>>>>>>>> Regarding whether the types of requirements belong to #1 or >>>>>>>>>>>>> #2, >>>>>>> I >>>>>>>>>>>>> believe >>>>>>>>>>>>> it is more of #1 type, as the information to be exchanged >>>>>>>>>>>>> would >>>>>>> be >>>>>>>>>>>>> known >>>>>>>>>>>>> after the initial query/response. >>>>>>>>>>>>> >>>>>>>>>>>>> If we know it today, I see no reason why we should not work >>>>>>>>>>>>> on >>>>>>> it >>>>>>>>> in >>>>>>>>>>>>> the >>>>>>>>>>>>> first phase of the work. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> >>>>>>>>>>>>> Juan Carlos >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] >>>>>>>>>>>>>> On >>>>>>>>> Behalf >>>>>>>>>>>>>> Of >>>>>>>>>>>>>> Peter Saint-Andre >>>>>>>>>>>>>> Sent: Thursday, March 08, 2012 11:59 AM >>>>>>>>>>>>>> To: Nancy Bravin >>>>>>>>>>>>>> Cc: paws@ietf.org; johnny.dixon@bt.com; >>>>>>> chris.cheeseman@bt.com; >>>>>>>>> Pete >>>>>>>>>>>>>> Resnick >>>>>>>>>>>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- >>>>>>>>> usecases- >>>>>>>>>>>>>> rqmts-03: channel reporting >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Nancy, >>>>>>>>>>>>>> >>>>>>>>>>>>>> You are absolutely right that different locales will have >>>>>>>>> different >>>>>>>>>>>>>> rules and requirements. We need to understand those, and >>>>>>>>>>>>>> work >>>>>>> to >>>>>>>>>>>>>> address >>>>>>>>>>>>>> them if possible (although we don't necessarily need to >>>>>>> address >>>>>>>>> them >>>>>>>>>>>>>> all >>>>>>>>>>>>>> at the same time). I see several kinds of requirements: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1. Some requirements might lead to features beyond the >>>>>>>>> query/response >>>>>>>>>>>>>> protocol we've envisioned so far. One example might be >> real- >>>>>>> time >>>>>>>>>>>>>> reporting about the channels that a device is actually >> using. >>>>>>> In >>>>>>>>> my >>>>>>>>>>>>>> opinion, it would be best to handle those in the next phase >>>>>>>>>>>>>> of >>>>>>>>> work, >>>>>>>>>>>>>> because as far as I can see they are outside the scope of >>>>>>>>>>>>>> our >>>>>>>>> charter. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2. Some requirements might be handled through by defining >>>>>>>>> additional >>>>>>>>>>>>>> fields that can be included in the query or response. We >>>>>>>>> definitely >>>>>>>>>>>>>> planned for that when working on the charter with the IESG: >>>>>>>>>>>>>> >>>>>>>>>>>>>> In addition, the particular >>>>>>>>>>>>>> data exchanged between a device and a database might >>>>>>>>>>>>>> depend >>>>>>> on >>>>>>>>> the >>>>>>>>>>>>>> ranges of radio spectrum that are to be used, the >>>>>>> requirements >>>>>>>>> of >>>>>>>>>>>>>> the >>>>>>>>>>>>>> database operators and their governing regulations, and >>>>>>> other >>>>>>>>>>>>>> factors. >>>>>>>>>>>>>> Therefore, the database access method and the >>>>>>> query/response >>>>>>>>> data >>>>>>>>>>>>>> formats that are exchanged using that method need to be >>>>>>>>> designed >>>>>>>>> for >>>>>>>>>>>>>> extensibility rather than being tied to any specific >>>>>>> spectrum, >>>>>>>>>>>>>> country, or phy/mac/air interface. >>>>>>>>>>>>>> >>>>>>>>>>>>>> It's unclear to me right now if the Ofcom requirement fits >>>>>>> into >>>>>>>>> #1 or >>>>>>>>>>>>>> #2, which is why we're having this discussion. :) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Peter >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 3/7/12 8:17 PM, Nancy Bravin wrote: >>>>>>>>>>>>>>> Peter and all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I agree that it is important to revisit now, so that in >> the >>>>>>>>> future, >>>>>>>>>>>>>>> it will be easy to align things in their proper place. >>>>>>>>>>>>>>> Every >>>>>>>>> country >>>>>>>>>>>>>>> may have different regulations, spectrum, policy and what >>>>>>>>>>>>>>> responsibility is in the domain of the system, and what >>>>>>>>>>>>>>> comes >>>>>>>>> under >>>>>>>>>>>>>>> the PAWS charter is important. Maybe some separation >> might >>>>>>> be >>>>>>>>>>>>>>> possible, and dividing and clarifying issues now will help >>>>>>>>>>>>>>> in >>>>>>>>> the >>>>>>>>>>>>>>> future. Certainly it seems that the FCC may change some >>>>>>> rules, >>>>>>>>> and >>>>>>>>>>>>>>> we know that Ofcom is not yet finished with their >>>>>>> regulations. >>>>>>>>> Canada >>>>>>>>>>>>>>> has their own, and other countries are working on this as >>>>>>> well. >>>>>>>>> Just >>>>>>>>>>>>>>> a thought...Sharing is a realistic goal...as is off >>>>>>> loading... >>>>>>>>> Or you >>>>>>>>>>>>>>> slim line and every 6 months decide what to incorporate in >>>>>>> the >>>>>>>>>>>>>>> protocol based on new information, new ideas, new >>>>>>>>>>>>>>> innovation >>>>>>> new >>>>>>>>>>>>>>> regulations and maybe spend more time than you could if >>>>>>>>> addressed >>>>>>>>>>>>>>> now. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> That way you leave the door open and outside of >> referencing >>>>>>> what >>>>>>>>> is >>>>>>>>>>>>>>> known today, by referencing regulations i.e. Ofcom, FCC, >>>>>>>>> Industry >>>>>>>>>>>>>>> Canada etc as of XX-XX-XXXX date. Out of scope not >>>>>>>>>>>>>>> something >>>>>>> we >>>>>>>>> know >>>>>>>>>>>>>>> enough about to say at this point, In my opinion. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> My 2 cents.. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Sincerely, Nancy >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> As your responsible Area Director (until March 28, when >>>>>>>>>>>>>>>> Pete Resnick will take over from me), I have reviewed >> this >>>>>>> thread. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In my opinion (I am happy to be proven wrong), this new >>>>>>>>> requirement >>>>>>>>>>>>>>>> goes beyond what the charter defined as the scope of this >>>>>>>>> working >>>>>>>>>>>>>>>> group, which was to enable a device to discover the white >>>>>>> space >>>>>>>>>>>>>>>> available to it in its current location. Reporting usage >>>>>>> back >>>>>>>>> to >>>>>>>>>>>>>>>> the database is simply not mentioned in the charter. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Earlier in this thread, Andy Sago wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> There's no language I can find in the charter that >>>>>>> explicitly >>>>>>>>> puts >>>>>>>>>>>>>>>> this out of scope. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> An IETF charter defines what the working group shall work >>>>>>> on. >>>>>>>>> Many >>>>>>>>>>>>>>>> interesting features could be developed here. However, it >>>>>>>>>>>>>>>> is >>>>>>>>> not >>>>>>>>>>>>>>>> the job of the charter to mention explicitly that each of >>>>>>> those >>>>>>>>>>>>>>>> interesting features is out of scope. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The charter does say: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Once the device learns of the available white space >> (e.g., >>>>>>> in a >>>>>>>>> TV >>>>>>>>>>>>>>>> white space implementation, the list of available >> channels >>>>>>> at >>>>>>>>> that >>>>>>>>>>>>>>>> location), it can then select one of the bands from the >>>>>>>>>>>>>>>> list >>>>>>>>> and >>>>>>>>>>>>>>>> begin to transmit and receive on the selected band. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This text might have assumed that no further >> communication >>>>>>> or >>>>>>>>>>>>>>>> authorization was required in order to select one of the >>>>>>> bands >>>>>>>>> from >>>>>>>>>>>>>>>> the list and then transmit/receive. Perhaps that >>>>>>>>>>>>>>>> assumption >>>>>>> was >>>>>>>>>>>>>>>> mistaken. If so, it would be good to have a discussion >>>>>>>>>>>>>>>> about >>>>>>>>> that, >>>>>>>>>>>>>>>> so we can determine if we need to revisit the assumptions >>>>>>>>>>>>>>>> we >>>>>>>>> made >>>>>>>>>>>>>>>> early on. If in fact we made some faulty or limited >>>>>>>>> assumptions, >>>>>>>>>>>>>>>> then let's get that out in the open. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Peter >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 3/7/12 9:40 AM, Rosen, Brian wrote: >>>>>>>>>>>>>>>>> I'd also suggest >> that >>>>>>> our >>>>>>>>>>>>>>>>> charter limitation is really support for sharing of >>>>>>> whitespace >>>>>>>>> by >>>>>>>>>>>>>>>>> whitespace devices. Reporting what you use is not >>>>>>>>>>>>>>>>> sharing, >>>>>>>>> it's >>>>>>>>>>>>>>>>> just data gathering. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The point of excluding sharing was to eliminate the >>>>>>>>> complexities >>>>>>>>>>>>>>>>> of what constituted fairness, and what kinds of >>>>>>> communication >>>>>>>>>>>>>>>>> might be needed between databases, where more than one >>>>>>> could >>>>>>>>>>>>>>>>> supply available whitespace in a band. This doesn't >> have >>>>>>> any >>>>>>>>> of >>>>>>>>>>>>>>>>> those issues, As long as it's just sending information, >> I >>>>>>>>> don't >>>>>>>>>>>>>>>>> have a problem. Once the database is supposed to do >>>>>>> anything >>>>>>>>>>>>>>>>> with it that involves changing what spectrum it reports, >>>>>>> then >>>>>>>>> I >>>>>>>>>>>>>>>>> think we cross the line. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Brian >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Mar 6, 2012, at 12:28 PM, >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Joel >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Indeed, the regulator has not described the process or >>>>>>>>> provided >>>>>>>>>>>>>>>>>> a flow diagram, so there may be some wrinkles, but we >>>>>>>>>>>>>>>>>> need >>>>>>> to >>>>>>>>>>>>>>>>>> provide for their intent. To answer your question, the >>>>>>>>> channels >>>>>>>>>>>>>>>>>> that the master will use are sent in a separate message >>>>>>>>>>>>>>>>>> (described in P.12 ter), that occurs after the master >>>>>>>>> receives >>>>>>>>>>>>>>>>>> the response to its channel request, but before the >>>>>>>>>>>>>>>>>> master >>>>>>>>> can >>>>>>>>>>>>>>>>>> transmit. At this point, it knows what channels are >>>>>>>>> available, >>>>>>>>>>>>>>>>>> and which one it will use. As far as the slaves are >>>>>>>>> concerned, >>>>>>>>>>>>>>>>>> as they associate, the master will need to gather their >>>>>>>>> details >>>>>>>>>>>>>>>>>> and send further channel usage messages to the database >>>>>>>>>>>>>>>>>> on their behalf. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Andy >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -----Original Message----- From: paws-bounces@ietf.org >>>>>>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] On Behalf Of Joel M. >>>>>>> Halpern >>>>>>>>>>>>>>>>>> Sent: 06 March 2012 17:05 To: scott.probasco@nokia.com >>>>>> Cc: >>>>>>>>>>>>>>>>>> paws@ietf.org; Cheeseman,CJ,Chris,COD R; >>>>>>> Dixon,JS,Johnny,COD >>>>>>>>> R >>>>>>>>>>>>>>>>>> Subject: Re: [paws] WGLC for >>>>>>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel >>>>>>>>>>>>>>>>>> reporting >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Ahh. I think I see where the request and my >>>>>>>>>>>>>>>>>> understanding divurge. If the idea here is that the >>>>>>>>>>>>>>>>>> master must provide, >>>>>>> in >>>>>>>>>>>>>>>>>> the request, an indication of what channels it expects >>>>>>>>>>>>>>>>>> to >>>>>>>>> use, >>>>>>>>>>>>>>>>>> I can at least understand that. I will return to >>>>>>> technical >>>>>>>>>>>>>>>>>> concerns in a moment. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> However, when you say "provide channel usage >>>>>>>>>>>>>>>>>> information, >>>>>>> in >>>>>>>>>>>>>>>>>> order to evaluate interference", what that says to me >> is >>>>>>>>>>>>>>>>>> providing, during operation, information as to what >>>>>>> channels >>>>>>>>>>>>>>>>>> are being used, and at what power levels. That is what >>>>>>> would >>>>>>>>>>>>>>>>>> be needed to analyze actual interference effects. And >>>>>>>>>>>>>>>>>> that >>>>>>> is >>>>>>>>>>>>>>>>>> out of scope as I understand our scope. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I do see a technical difficulty with having the master >>>>>>>>> provide, >>>>>>>>>>>>>>>>>> as part of either registering or requesting spectrum >>>>>>>>>>>>>>>>>> information, what channels it intends to use. It >>>>>>>>>>>>>>>>>> doesn;t >>>>>>>>> know >>>>>>>>>>>>>>>>>> what channels it intends to use. It intends to use >> some >>>>>>>>> number >>>>>>>>>>>>>>>>>> of available channels. It will figure out which ones >>>>>>>>>>>>>>>>>> when >>>>>>> it >>>>>>>>>>>>>>>>>> is told what is available. How can it send that >>>>>>> information >>>>>>>>> in >>>>>>>>>>>>>>>>>> the request? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: >>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> There is a similarity here with device ID. In context >>>>>>>>>>>>>>>>>>> of >>>>>>>>> PAWS >>>>>>>>>>>>>>>>>>> we are not concerned with why a device ID is required >>>>>>>>>>>>>>>>>>> by >>>>>>> a >>>>>>>>>>>>>>>>>>> regulator, we accept it is a requirement from a >>>>>>>>>>>>>>>>>>> regulator >>>>>>>>> and >>>>>>>>>>>>>>>>>>> include it to the protocol. Ofcom identifies in 3.18& >>>>>>> 3.19 >>>>>>>>>>>>>>>>>>> that channel usage information is required and thus we >>>>>>> need >>>>>>>>>>>>>>>>>>> to include this information. Since the master must >>>>>>> provide >>>>>>>>>>>>>>>>>>> this information prior to transmitting, PAWS will not >>>>>>>>>>>>>>>>>>> function in the UK without this information and thus I >>>>>>>>>>>>>>>>>>> believe channel usage information is integral to the >>>>>>> channel >>>>>>>>>>>>>>>>>>> request& response messaging. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Kind Regards, Scott >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 3/6/12 10:30 AM, "ext Joel M. >>>>>>>>>>>>>>>>>>> Halpern" wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I would draw a distinction. Ofcom regulations about >>>>>>>>>>>>>>>>>>>> whitespace requests are very much relevant. Ofcom >>>>>>>>>>>>>>>>>>>> regulations about notification of dynamic behavior >>>>>>> (which >>>>>>>>>>>>>>>>>>>> spectrum is being used) are not in scope as I >>>>>>>>>>>>>>>>>>>> understand the earlier discussions, particularly the >>>>>>>>>>>>>>>>>>>> chartering discussions. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com >> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> The ofcom requirements are very much relevant to the >>>>>>>>>>>>>>>>>>>>> scope of the PAWS WG. The only other regulatory >>>>>>>>>>>>>>>>>>>>> requirements that we have today is the FCC. Ofcom >>>>>>>>>>>>>>>>>>>>> requirements are a good addition to the set. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -Raj >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 3/6/12 10:03 AM, "ext >>>>>>>>>>>>>>>>>>>>> andy.sago@bt.com" wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Hi Joel >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> There's no language I can find in the charter that >>>>>>>>>>>>>>>>>>>>>> explicitly puts this out of scope. On the other >>>>>>>>>>>>>>>>>>>>>> hand, the charter says that the group will >> "consider >>>>>>>>>>>>>>>>>>>>>> input from regulatory entities", and this is one of >>>>>>>>>>>>>>>>>>>>>> the requirements from Ofcom that they have just >>>>>> published. >>>>>>>>>>>>>>>>>>>>>> The protocol will be worthless for the UK if it >>>>>>>>>>>>>>>>>>>>>> omits some requirements. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Andy >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> -----Original Message----- From: Joel M. Halpern >>>>>>>>>>>>>>>>>>>>>> [mailto:jmh@joelhalpern.com] Sent: 06 March 2012 >>>>>>>>>>>>>>>>>>>>>> 15:53 >>>>>>>>>>>>>>>>>>>>>> To: Sago,AJ,Andy,COD R Cc: paws@ietf.org; >>>>>>>>>>>>>>>>>>>>>> Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for >>>>>>>>>>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: >>>>>>> channel >>>>>>>>>>>>>>>>>>>>>> reporting >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> As I understand, the information you are asking for >>>>>>>>>>>>>>>>>>>>>> is explicitly out of scope for the working group. >>>>>>>>>>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >>>>>>>>>>>>>>>>>>>>>>> All >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Comparing the draft with the Ofcom requirements at >>>>>>>>>>>>>>>>>>>>>>> http://www.cept.org/Documents/se- >>>>>>>>>>>>>> 43/4161/SE43(12)Info03_Draft-UK-r >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> egul >>>>>>>>>>>>>>>>>>>>>>> atory-requirements-for-white-space-devices-in-the- >>>>>>> UHF- >>>>>>>>> TV- >>>>>>>>>>>>>> band, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> I believe the WG draft is deficient in the area of >> reporting >>>>>>>>>>>>>>>>>>>>>>> frequencies and powers actually used by masters >> and >>>>>>>>>>>>>>>>>>>>>>> slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom >>>>>>>>>>>>>>>>>>>>>>> intends to collect this data to assesses the >> impact >>>>>>>>>>>>>>>>>>>>>>> of aggregate interference into other services. It >>>>>>>>>>>>>>>>>>>>>>> would also provide usage information (frequency in >>>>>>>>>>>>>>>>>>>>>>> use) that would inform the operation of a kill >>>>>>>>>>>>>>>>>>>>>>> switch capability. I suggest this deficiency can >> be >>>>>>>>>>>>>>>>>>>>>>> remedied with the following changes: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> New P requirements (probably best placed following >>>>>>>>>>>>>>>>>>>>>>> P.12): >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> P.12bis: The protocol MUST support a channel usage >>>>>>>>>>>>>>>>>>>>>>> message from the slave device to the master >> device. >>>>>>>>>>>>>>>>>>>>>>> The channel usage message MUST include parameters >>>>>>>>>>>>>>>>>>>>>>> as required by local regulatory requirement. >> These >>>>>>>>>>>>>>>>>>>>>>> parameters MAY include device ID, manufacturer's >>>>>>>>>>>>>>>>>>>>>>> serial number, channel usage and power level >>>>>>>>>>>>>>>>>>>>>>> information. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> P.12ter: The protocol MUST support a channel usage >>>>>>>>>>>>>>>>>>>>>>> message from the master device to the database. >>>>>>>>>>>>>>>>>>>>>>> The channel usage message MUST include parameters >>>>>>>>>>>>>>>>>>>>>>> as required by local regulatory requirement for >> the >>>>>>>>>>>>>>>>>>>>>>> master and its associated slaves. These >> parameters >>>>>>>>>>>>>>>>>>>>>>> MAY include device ID, manufacturer's serial >>>>>>>>>>>>>>>>>>>>>>> number, channel usage and power level information. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> P.12qua: The protocol MUST support a channel usage >>>>>>>>>>>>>>>>>>>>>>> message acknowledgement. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> New O requirements (probably best placed following >>>>>>>>>>>>>>>>>>>>>>> O13): >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> O.13bis: According to local regulatory policy, >>>>>>>>>>>>>>>>>>>>>>> after connecting to a master device's radio >> network >>>>>>>>>>>>>>>>>>>>>>> a slave device MAY inform the master device of the >>>>>>>>>>>>>>>>>>>>>>> actual channel usage. The slave MUST include >>>>>>>>>>>>>>>>>>>>>>> parameters required by local regulatory policy, >> e.g. >>>>>>>>>>>>>>>>>>>>>>> device ID, manufacturer's serial number, channel >>>>>>>>>>>>>>>>>>>>>>> usage and power level information. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> O.13ter: According to local regulatory policy, a >>>>>>>>>>>>>>>>>>>>>>> master device MAY inform the database of the >> actual >>>>>>>>>>>>>>>>>>>>>>> channel usage of the master and its slaves. The >>>>>>>>>>>>>>>>>>>>>>> master MUST include parameters required by local >>>>>>>>>>>>>>>>>>>>>>> regulatory policy, e.g. device ID, manufacturer's >>>>>>>>>>>>>>>>>>>>>>> serial number, channel usage and power level >>>>>>>>>>>>>>>>>>>>>>> information of the master and its slaves. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> New steps could be introduced into one or more use >>>>>>>>>>>>>>>>>>>>>>> cases to cover these Ofcom requirements, e.g. new >>>>>>>>>>>>>>>>>>>>>>> steps 6bis and 9bis in the hotspot use case at >>>>>>>>>>>>>>>>>>>>>>> 4.2.1: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 6bis. Prior to initiating transmission, if >> required >>>>>>>>>>>>>>>>>>>>>>> by local regulation, the master/AP informs the >>>>>>>>>>>>>>>>>>>>>>> database of the channel and power level it has >>>>>>>>>>>>>>>>>>>>>>> chosen. This is repeated for each slave that >>>>>>>>>>>>>>>>>>>>>>> associated with the master. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 9bis. Prior to initiating transmission, if >> required >>>>>>>>>>>>>>>>>>>>>>> by local regulation, the slave informs the >>>>>>>>>>>>>>>>>>>>>>> master/AP of the channel and power level it has >>>>>>>>>>>>>>>>>>>>>>> chosen, and the master/AP relays this information >>>>>>>>>>>>>>>>>>>>>>> to the >>>>>> database. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> - end of new text - >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> For information, for those not accessing the url >> in >>>>>>>>>>>>>>>>>>>>>>> the first paragraph of this email, the full Ofcom >>>>>>>>>>>>>>>>>>>>>>> requirements leading to this new PAWS text are as >>>>>>>>>>>>>>>>>>>>>>> follows: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 3.18 After receiving instructions from a WSDB in >>>>>>>>>>>>>>>>>>>>>>> relation to the maximum permitted EIRPs over the >>>>>>>>>>>>>>>>>>>>>>> DTT channels, and prior to initiating >> transmissions >>>>>>>>>>>>>>>>>>>>>>> within the UHF TV band, a master WSD must >>>>>>>>>>>>>>>>>>>>>>> communicate to the WSDB the following information: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 3.18.1 The lower and upper frequency boundaries^13 >>>>>>>>>>>>>>>>>>>>>>> of the in-block emissions of the master WSD, and >>>>>>>>>>>>>>>>>>>>>>> those of the in-block emissions of its associated >>>>>>>>>>>>>>>>>>>>>>> slaves. A lower frequency will be specified as >> (470 >>>>>>>>>>>>>>>>>>>>>>> + 8k + >>>>>>>>>>>>>>>>>>>>>>> 0.2n) MHz, with the corresponding upper frequency >>>>>>>>>>>>>>>>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3?4 k >>>>>> 3?4 >>>>>>>>>>>>>>>>>>>>>>> 39, 0 3?4 n 3?4 39, 1 3?4 m 3?4 40, and n< m. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 3.18.2 The maximum in-block EIRP spectral >> densities >>>>>>>>>>>>>>>>>>>>>>> (in dBm/(0.2 MHz)) that the master WSD, and its >>>>>>>>>>>>>>>>>>>>>>> associated slaves, actually radiate between each >>>>>>>>>>>>>>>>>>>>>>> reported lower frequency boundary and its >>>>>>>>>>>>>>>>>>>>>>> corresponding upper frequency boundary. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Footnote 13 states: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> The use of upper and lower frequency boundaries >>>>>>>>>>>>>>>>>>>>>>> (defined over a 200 kHz raster) allows a WSDB to >>>>>>>>>>>>>>>>>>>>>>> collect more granular information with regards to >>>>>>>>>>>>>>>>>>>>>>> the usage of the frequency resource by narrowband >>>>>>>>>>>>>>>>>>>>>>> WSD technologies. The upper and lower frequencies >>>>>>>>>>>>>>>>>>>>>>> of a boundary pair do not straddle a DTT channel >>>>>> boundary. >>>>>>>>>>>>>>>>>>>>>>> Note that a WSD may transmit over multiple, >>>>>>>>>>>>>>>>>>>>>>> non-contiguous, whole DTT channels or fractions of >>>>>>>>>>>>>>>>>>>>>>> DTT channels. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 3.19 A master WSD must be able to receive the >>>>>>>>>>>>>>>>>>>>>>> following information^14 from a WSDB: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in >> the >>>>>>>>>>>>>>>>>>>>>>> context of 3.18, that the reported information on >>>>>>>>>>>>>>>>>>>>>>> the DTT channels and EIRP spectral densities >>>>>>>>>>>>>>>>>>>>>>> actually used by the master and slave WSDs were >>>>>>>>>>>>>>>>>>>>>>> received successfully by the WSDB^18 ]. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Footnote 14 states: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 14 While the communication of some of this >>>>>>>>>>>>>>>>>>>>>>> information from a WSDB to a master WSD is >>>>>>>>>>>>>>>>>>>>>>> optional, master WSDs must be able to receive and >>>>>>>>>>>>>>>>>>>>>>> interpret these. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Footnote 18 states: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 18 This forms part of a handshake protocol and may >>>>>>>>>>>>>>>>>>>>>>> be an area where industry could harmonise without >>>>>>>>>>>>>>>>>>>>>>> the need for an explicit requirement in the >>>>>> regulations. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Andy >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> *From:*paws-bounces@ietf.org >>>>>>>>>>>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] *On Behalf Of >>>>>>>>>>>>>>>>>>>>>>> *Gabor.Bajko@nokia.com *Sent:* 05 March 2012 19:46 >>>>>>>>>>>>>>>>>>>>>>> *To:* paws@ietf.org *Subject:* [paws] WGLC for >>>>>>>>>>>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> The authors of the use cases and requirements >> draft >>>>>>>>>>>>>>>>>>>>>>> have just posted a new version of the draft and >>>>>>>>>>>>>>>>>>>>>>> indicated that there are no unresolved >>>>>>>>>>>>>>>>>>>>>>> comments/issues they are aware of. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Therefore, I'd like to initiate a WG Last Call for >>>>>>>>>>>>>>>>>>>>>>> comments on >>>>>>>>>>>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf- >> paws >>>>>>>>>>>>>>>>>>>>>>> - >>>>>>>>> problem- >>>>>>>>>>>>>> stmt-u >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> seca >>>>>>>>>>>>>>>>>>>>>>> ses-rqmts-03.txt >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Please review the draft and send your comments to >>>>>>>>>>>>>>>>>>>>>>> the list by March 20th, 2012. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> If you review the draft and have no comments, send >>>>>>>>>>>>>>>>>>>>>>> a note to the list that the draft is good as it >> is, >>>>>>>>>>>>>>>>>>>>>>> we need these notes as much as we need the actual >>>>>>>>>>>>>>>>>>>>>>> comments. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks, Gabor >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> paws mailing list >>>>>>>>>> paws@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> paws mailing list >>>>>>>>> paws@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> paws mailing list >>>>>>>>> paws@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> >>>>>> ________________________________ >>>>>> >>>>>> >>>> >> *********************************************************************** >>>>>> * >>>>>> ****************************************** >>>>>> For more information visit www.ofcom.org.uk >>>>>> >>>>>> This email (and any attachments) is confidential and intended for >> the >>>>>> use of the addressee only. >>>>>> >>>>>> If you have received this email in error please notify the >> originator >>>>>> of the message and delete it from your system. >>>>>> >>>>>> This email has been scanned for viruses. However, you open any >>>>>> attachments at your own risk. >>>>>> >>>>>> Any views expressed in this message are those of the individual >>>> sender >>>>>> and do not represent the views or opinions of Ofcom unless >> expressly >>>>>> stated otherwise. >>>>>> >>>> >> *********************************************************************** >>>>>> * >>>>>> ****************************************** >>>>>> _______________________________________________ >>>>>> paws mailing list >>>>>> paws@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>> _______________________________________________ >>>>>> paws mailing list >>>>>> paws@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws > From paul@marvell.com Mon Mar 19 13:26:59 2012 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 5C08C21E8017 for ; Mon, 19 Mar 2012 13:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[AWL=-1.326, BAYES_00=-2.599, J_BACKHAIR_11=1, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4, 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 Bury5X4B8mM0 for ; Mon, 19 Mar 2012 13:26:56 -0700 (PDT) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) by ietfa.amsl.com (Postfix) with ESMTP id 0451A21F87DB for ; Mon, 19 Mar 2012 13:26:53 -0700 (PDT) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKT2eWh2Lze0taTwHscqco8qvpehdwUtFL@postini.com; Mon, 19 Mar 2012 13:26:55 PDT Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Mon, 19 Mar 2012 13:26:16 -0700 From: Paul Lambert To: "Rosen, Brian" Date: Mon, 19 Mar 2012 13:26:15 -0700 Thread-Topic: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting Thread-Index: Ac0GDANl49tVVXHtS8iUkyf8OArZCgAAZoMQ Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D015E331E5B7@SC-VEXCH2.marvell.com> References: , <7BAC95F5A7E67643AAFB2C31BEE662D0157A034B37@SC-VEXCH2.marvell.com> <4F5A28F7.4070905@joelhalpern.com> <7BAC95F5A7E67643AAFB2C31BEE662D0157A034D48@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D015E331E56C@SC-VEXCH2.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Reza.Karimi@ofcom.org.uk" , "paws@ietf.org" , "johnny.dixon@bt.com" , "presnick@qualcomm.com" Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting 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, 19 Mar 2012 20:26:59 -0000 If we are supporting multiple regulatory domains that have different protoc= ol requirements and state change behaviors we need to define some parameter= ization of regulatory requirements - like "USE_TRACKING", which if true wou= ld generate a message to the DB on each change of the Masters channel/power= /modulation settings. This is NOT the same as an ACK. In FCC regions, thi= s parameter would be FALSE and there would be no additional messages indica= ting usage. Seems like USE_TRACKING would be a simple extension to a more basic protoco= l state machine and so could be layered in later or sooner depending on the= charter. Paul >-----Original Message----- >From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >Sent: Monday, March 19, 2012 1:08 PM >To: Paul Lambert >Cc: Joel M. Halpern; chris.cheeseman@bt.com; Reza.Karimi@ofcom.org.uk; >paws@ietf.org; johnny.dixon@bt.com; presnick@qualcomm.com >Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >rqmts-03:channel reporting > > >Depends on the time period allowed for the ack. > >The device won't start another transaction with the database before it >decides. > >The db doesn't have anything except a bit of state to keep if the ack >takes a while. So, let it take a while. > >Eventually, it would decide it wasn't going to get an answer and treat >it like an error (timeout). > >While we have to deal with charter issues, I don't like producing a >protocol spec that only works with the US rules. Tracking usage is not >an unreasonable regulatory requirement, and not a complicated protocol >mechanism. It only gets complicated when the spectrum returned from any >query depends on the usage information. That's somewhere I don't want >to go yet. > > >Let's assume, at least for now, that this subject is out of scope. >We'll have a discussion of what to do in Paris, and bring that back to >the list. Let's move forward on the document without this capability, >and we'll pick it up later if/when we get the charter issue settled. >That means I would like to stop discussion until Paris, and then we will >continue it on the list. > >Brian > > > >On Mar 19, 2012, at 2:58 PM, Paul Lambert wrote: > >> >>> -----Original Message----- >>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>> Sent: Monday, March 19, 2012 8:17 AM >>> To: Paul Lambert >>> Cc: Joel M. Halpern; chris.cheeseman@bt.com; >Reza.Karimi@ofcom.org.uk; >>> paws@ietf.org; johnny.dixon@bt.com; presnick@qualcomm.com >>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >>> rqmts-03:channel reporting >>> >>> >>> Remembering that so far, it appears this discussion is out of scope: >>> >>> While it may be the case that devices dynamically change their choice >of >>> what "channels" they will use between queries of the database, it's >at >>> least equally likely that it will get the list of available channels, >>> choose one, and stick to it. If they wanted to change at some point, >it >>> seems very feasible to query the database again, since the available >>> spectrum may have changed. >>> >>> The device can't tell the database what it's going to use before it >>> knows what is available. >>> >>> The "ack" sequence would be: >>> Device to DB: What could I use at location x,y? >>> DB to Device: You could use channels 3, 11 or 15 >>> Device to DB: Okay, I'll use channel 11 >> >> But the "ack" in this sequence occurs right after the "you could use" >message. Any intelligent AP/Master might some time to evaluate each >channel and pick one later that has the lowest utilization. It would >not have this knowledge in time for an "ack". If it picked a channel >for the ack, it would likely change soon to another channel. >> >> Given that the "ack" has only informative information that will change >- there is nothing useful that can be done by the DB with this >information. Unless the Master provides continuous updates of channel >utilization - there is no reason to have this information carried in an >ack. >> >> We should not create extra messages to carry information that will not >be used in any processing. >> >> Paul >> >> >>> >>> Brian >>> >>> On Mar 9, 2012, at 6:58 PM, Paul Lambert wrote: >>> >>>> >>>> >>>> +1 to all of Joels comments >>>> >>>> Why would a third ack message ever be different from the original >>> request? >>>> >>>> There's been no time to connect clients or make any other >interesting >>> choices that would change the way the spectrum would be used. The >ack >>> is a useless message and any such informative information about the >>> capabilities or plans of a device to use a range of spectrum should >have >>> been carried in the first message. >>>> >>>> >>>> Paul >>>> >>>>> -----Original Message----- >>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>>> Sent: Friday, March 09, 2012 8:00 AM >>>>> To: chris.cheeseman@bt.com >>>>> Cc: Paul Lambert; sdas@appcomsci.com; SiewYoon.Tan@ofcom.org.uk; >>>>> JuanCarlos.Zuniga@InterDigital.com; Basavaraj.Patil@nokia.com; >>>>> gerald.chouinard@sympatico.ca; scott.probasco@nokia.com; >>> paws@ietf.org; >>>>> presnick@qualcomm.com; Reza.Karimi@ofcom.org.uk; >johnny.dixon@bt.com >>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >>>>> rqmts-03:channel reporting >>>>> >>>>> I am having trouble connecting the goal of the requirement, the >>> expected >>>>> protocol behavior, and the expected real-world operation. >>>>> >>>>> Lets keep it simple. A master, connected by wired internet to the >>>>> World. A set of slaves who want to use whitespace to talk to the >>>>> master. All within a small physical space. All within the the >time >>>>> limit of whatever answer the master gets from the database. >>>>> >>>>> The Ofcom requirement is described as being important for >>> understanding >>>>> interference effects. Therefore, presumably, it needs to relate to >>>>> actual spectrum usage. >>>>> >>>>> The stated protocol behavior is that the master would reply to the >>>>> shitespace database with an ack indicating what it expects to use, >at >>>>> what power level. >>>>> The way folks are writing this, I believe the intention is "respond >>>>> once". >>>>> >>>>> As I understand such master / slave behavior (and I am by no means >a >>>>> radio expert), the actual usage of spectrum, within the whitespace >>> band, >>>>> will depend upon how many slaves are active, and possibly on what >>> they >>>>> are doing. >>>>> >>>>> If the actual usage is going to depend upon the slave device >>> population >>>>> / behavior, then the only answer the master can correctly provide >is >>> "I >>>>> will use all of the whitespace you have identified, with the >highest >>>>> power I might use. >>>>> >>>>> Such an answer is a valid answer in terms of protocol and in terms >of >>>>> the stated regulatory requirements. However, it is utterly useless >>> in >>>>> terms of the stated goal. >>>>> As an engineer, I am very uncomfortable designing a protocol >>> messaging >>>>> exchange which I know will not meet the end-users needs. >>>>> >>>>> Note1: If I have mischaracterized ro misunderstood what folks ahve >>>>> explained, I apologize. >>>>> >>>>> Note2: If instead the intention is for the master to update the >>> database >>>>> every time it changes the spectrum usage pattern, then this is NOT >an >>>>> acknowledgment of the reply from the database. It is a dynamic >>> behavior >>>>> reporting requirement. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 3/9/2012 6:36 AM, chris.cheeseman@bt.com wrote: >>>>>> Hi >>>>>> >>>>>> My reading of the UK regulatory requirements that Ofcom has made >>>>> available is that the Acknowledgement message that must be >>> communicated >>>>> back to the database from the white space device is simply the >>> frequency >>>>> range (or ranges) and maximum eirp density that the device intends >to >>>>> use (a subset of what it would have been offered by the database). >I >>>>> don't believe there is any intent to limit modulation schemes etc. >as >>>>> part of this exchange. This seems a relatively straightforward >>>>> requirement and the PAWS protocol should accommodate this if it is >to >>> be >>>>> relevant for the UK regulatory environment. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Chris >>>>>> >>>>>> -----Original Message----- >>>>>> From: Paul Lambert [mailto:paul@marvell.com] >>>>>> Sent: 09 March 2012 02:15 >>>>>> To: Das, Subir; 'Siew Yoon Tan'; Zuniga, Juan Carlos; >>>>> Basavaraj.Patil@nokia.com; gerald.chouinard@sympatico.ca; >>>>> jmh@joelhalpern.com; scott.probasco@nokia.com >>>>>> Cc: paws@ietf.org; presnick@qualcomm.com; Reza Karimi; >>>>> Dixon,JS,Johnny,COD R; Cheeseman,CJ,Chris,COD R >>>>>> Subject: RE: [paws] WGLC for draft-ietf-paws-problem-stmt- >usecases- >>>>> rqmts-03:channel reporting >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> I have a question here. Is it really an acknowledgement or we >would >>>>>>> like to see a kind of notification message that includes channel, >>> and >>>>>>> other parameters? >>>>>> >>>>>> What if it's multiple channels? What happens if the device adapts >>> and >>>>> changes between modulation technique or bandwidth? Does every >change >>>>> over the air need to be indicated to the GDB? >>>>>> >>>>>> This Channel acknowledgement does not seem useful and would limit >>> real >>>>> world behaviors (like channel and modulation adaptation). >>>>>> >>>>>> If viewed as a potential regulatory requirement - does this imply >we >>>>> need to parameterize the protocol to have different behaviors in >>>>> different regions? >>>>>> >>>>>> Paul >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> _Subir >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >>> Behalf >>>>> Of >>>>>>> Siew Yoon Tan >>>>>>> Sent: Thursday, March 08, 2012 4:06 PM >>>>>>> To: Zuniga, Juan Carlos; Basavaraj.Patil@nokia.com; >>>>>>> gerald.chouinard@sympatico.ca; jmh@joelhalpern.com; >>>>>>> scott.probasco@nokia.com >>>>>>> Cc: paws@ietf.org; presnick@qualcomm.com; Reza Karimi; >>>>>>> johnny.dixon@bt.com; chris.cheeseman@bt.com >>>>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- >usecases- >>>>>>> rqmts-03:channel reporting >>>>>>> >>>>>>> Dear All, >>>>>>> >>>>>>> Regarding Ofcom's requirement to have a return channel as part of >>> the >>>>>>> protocol between the WSD and WSDB, I would like to confirm to >>>>> following >>>>>>> sequence of messaging >>>>>>> >>>>>>> Channel request >>>>>>> Channel response >>>>>>> Channel acknowledgement >>>>>>> >>>>>>> which was raised in an earlier email to this list. >>>>>>> >>>>>>> Our view is that it would be beneficial to define the protocol >>>>> between >>>>>>> WSD and WSDB that supports this requirement even though how the >>>>>>> information could be used is still subject to discussion in the >UK. >>>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Siew Yoon >>>>>>> >>>>>>> >>>>>>> ________________________________________ >>>>>>> From: paws-bounces@ietf.org [paws-bounces@ietf.org] on behalf of >>>>>>> Zuniga, Juan Carlos [JuanCarlos.Zuniga@InterDigital.com] >>>>>>> Sent: 08 March 2012 20:41 >>>>>>> To: Basavaraj.Patil@nokia.com; gerald.chouinard@sympatico.ca; >>>>>>> jmh@joelhalpern.com; scott.probasco@nokia.com >>>>>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>>>>>> chris.cheeseman@bt.com >>>>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- >>>>> usecases- >>>>>>> rqmts-03:channel reporting >>>>>>> >>>>>>> Hi Raj, >>>>>>> >>>>>>> I was reusing the language used from Gerald (which I know is >>> familiar >>>>>>> to people working on IEEE 802 WS groups): >>>>>>> >>>>>>>>> [GC] You got it. This would be useless for spectrum >regulators. >>>>> One >>>>>>>>> should realize that, from the spectrum regulator's point of >view, >>>>>>>>> the second and third messages could be iterated upon to >optimize >>>>> the >>>>>>>>> spectrum use. >>>>>>>>> Knowing >>>>>>>>> what channels the systems in an area are using, the spectrum >>>>>>>>> regulators and/or other entities such as those taking care of >>>>>>>>> coexistence could use the database in near-real-time to iterate >>> on >>>>>>>>> the two last messages to reduce the range of channels that some >>>>>>>>> systems may use once they know precisely what channels are >being >>>>>>>>> used in the area. The PAWS protocol would carry the information >>>>> back >>>>>>>>> and forth but would not be involved in such spectrum use >>>>> optimization. >>>>>>> >>>>>>> Having said that, I have no issue sticking to the WSDB >terminology. >>> I >>>>>>> like keeping things simple :) >>>>>>> >>>>>>> JC >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Basavaraj.Patil@nokia.com >[mailto:Basavaraj.Patil@nokia.com] >>>>>>>> Sent: Thursday, March 08, 2012 3:33 PM >>>>>>>> To: Zuniga, Juan Carlos; gerald.chouinard@sympatico.ca; >>>>>>>> jmh@joelhalpern.com; scott.probasco@nokia.com >>>>>>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>>>>>>> chris.cheeseman@bt.com >>>>>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- >>> usecases- >>>>>>>> rqmts-03:channel reporting >>>>>>>> >>>>>>>> >>>>>>>> Hi JC, >>>>>>>> >>>>>>>> Where/why did the coexistence manager come into the picture? >Your >>>>>>>> comment about "communicating back to the WSDB/coexistence >manager" >>>>>>>> may result in further misunderstanding. If we simply stick to to >>>>> WSDB >>>>>>>> I think we are okay. >>>>>>>> >>>>>>>> -Raj >>>>>>>> >>>>>>>> On 3/8/12 2:25 PM, "ext Zuniga, Juan Carlos" >>>>>>>> wrote: >>>>>>>> >>>>>>>>> So, from Gerald and Andy's comments, it seems like from the >point >>>>> of >>>>>>>> view >>>>>>>>> of (at least) two regulatory entities it is important for the >>>>>>>>> protocol >>>>>>>> to >>>>>>>>> allow communicating back to the WSDB/coexistence manager the >>> actual >>>>>>>>> channel usage after the first query is made. >>>>>>>>> >>>>>>>>> This is to me a very clear requirement. >>>>>>>>> >>>>>>>>> The actual messages/IEs that would carry this information >should >>> be >>>>>>>>> discussed as part of the solution document, and not the >>>>> requirements. >>>>>>>>> >>>>>>>>> JC >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >>>>>>>>>> Behalf >>>>>>>> Of >>>>>>>>>> Gerald Chouinard >>>>>>>>>> Sent: Thursday, March 08, 2012 1:59 PM >>>>>>>>>> To: 'Joel M. Halpern'; scott.probasco@nokia.com >>>>>>>>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>>>>>>>>> chris.cheeseman@bt.com >>>>>>>>>> Subject: Re: [paws] WGLC for >>>>>>>>>> draft-ietf-paws-problem-stmt-usecases- >>>>>>>>>> rqmts-03:channel reporting >>>>>>>>>> >>>>>>>>>> Joel, Scott, >>>>>>>>>> >>>>>>>>>> Interesting discussion! See my comments in line below. >>>>>>>>>> >>>>>>>>>> Gerald >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >>>>>>>>>> Behalf >>>>>>>> Of >>>>>>>>>> Joel >>>>>>>>>> M. Halpern >>>>>>>>>> Sent: Thursday, 08 March, 2012 13:17 >>>>>>>>>> To: scott.probasco@nokia.com >>>>>>>>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>>>>>>>>> chris.cheeseman@bt.com >>>>>>>>>> Subject: Re: [paws] WGLC for >>>>>>>>>> draft-ietf-paws-problem-stmt-usecases- >>>>>>>>>> rqmts-03: >>>>>>>>>> channel reporting >>>>>>>>>> >>>>>>>>>> So why won't the device simply say "I will use all of this?" >>>>>>>>>> [GC] This would defeat the purpose of the acknowledgement >>> message. >>>>>>>>>> After all, that way it needs to do less work with the >database. >>>>>>>>>> And >>>>>>>> it >>>>>>>>>> can change frequencies when it wants. >>>>>>>>>> Given that the stated goal of the Ofcom requriement was to be >>> able >>>>>>>> to >>>>>>>>>> analyze interference effects, it seems that this will not >>> actually >>>>>>>> lead >>>>>>>>>> to them getting what they want, even if it does comply with >the >>>>>>>>>> regulations. >>>>>>>>>> [GC] You got it. This would be useless for spectrum >regulators. >>>>>>>>>> One should realize that, from the spectrum regulator's point >of >>>>>>>>>> view, the >>>>>>>> second >>>>>>>>>> and >>>>>>>>>> third messages could be iterated upon to optimize the spectrum >>>>> use. >>>>>>>>>> Knowing >>>>>>>>>> what channels the systems in an area are using, the spectrum >>>>>>>> regulators >>>>>>>>>> and/or other entities such as those taking care of coexistence >>>>>>>>>> could use the database in near-real-time to iterate on the two >>>>>>>>>> last messages to reduce the range of channels that some >systems >>>>>>>>>> may use once they know precisely what channels are being used >in >>>>> the area. >>>>>>>>>> The PAWS protocol would carry >>>>>>>> the >>>>>>>>>> information back and forth but would not be involved in such >>>>>>>> spectrum >>>>>>>>>> use >>>>>>>>>> optimization. >>>>>>>>>> >>>>>>>>>> Yours, >>>>>>>>>> joel >>>>>>>>>> >>>>>>>>>> On 3/8/2012 1:09 PM, scott.probasco@nokia.com wrote: >>>>>>>>>>> Hi Peter, >>>>>>>>>>> >>>>>>>>>>> Answers below. >>>>>>>>>>> >>>>>>>>>>> Kind Regards, >>>>>>>>>>> Scott >>>>>>>>>>> >>>>>>>>>>> On 3/8/12 11:39 AM, "ext Peter Saint- >Andre" >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Scott, I have two clarifying questions: >>>>>>>>>>>> >>>>>>>>>>>> 1. Does the device know, when it receives the channel >>> response, >>>>>>>>>> which >>>>>>>>>>>> channel it will actually use? >>>>>>>>>>> Scott->This is all new and I am not aware of any existing >>>>>>>>>> implementations. >>>>>>>>>>> I would argue that the device must decide what channel(s) it >>>>>>>>>>> will >>>>>>>> use >>>>>>>>>> when >>>>>>>>>>> it receives the channel response. >>>>>>>>>> [GC] Agree with Scott but this is only a portion of the >>>>>>>> considerations. >>>>>>>>>> If a >>>>>>>>>> device was to operate on its own, this would be true but a >>>>>>>>>> communication device usually implies at least 2 devices to >>>>>>>>>> communicate. Hence, the choice of the channel to be used will >>> need >>>>>>>>>> to be negotiated between the two devices before a choice can >be >>>>>>>>>> made. The chosen channel will belong to the >>>>>>>> set >>>>>>>>>> of >>>>>>>>>> available channels that is common to both devices. Remember >that >>>>>>>> some >>>>>>>>>> channels may be available at one device and not at the other >>>>>>>>>> because >>>>>>>> of >>>>>>>>>> their geolocation or other reason. Extending this concept to a >>>>>>>>>> star network topology, the channel that will be selected by >this >>>>>>>>>> network will >>>>>>>> have >>>>>>>>>> to >>>>>>>>>> belong to the set of channels that are available to all >devices. >>>>>>>> Each >>>>>>>>>> device >>>>>>>>>> will not be able to decide by itself which channel it wants to >>>>> use. >>>>>>>>>> >>>>>>>>>> This is why in such a star topology, it makes sense that the >>> slave >>>>>>>>>> devices to a base station or access point be represented by >the >>>>>>>>>> base station acting as the master on their behalf to query the >>>>>>>>>> database and receive the list of available channels (and/or >>>>>>>>>> maximum EIRP per channel). It is then the responsibility of >the >>>>>>>>>> base station to identify the set of available channels that is >>>>>>>>>> common for itself and all its slaves to decide on the >>>>>>>> channel >>>>>>>>>> that >>>>>>>>>> the network will use. As you can see, in this case, there is >no >>>>>>>>>> need for each slave to receive its list of available channels. >>> On >>>>>>>>>> its own, it would not know what to do with it. The only thing >>> that >>>>>>>>>> needs to be sent >>>>>>>> from >>>>>>>>>> the >>>>>>>>>> master device to its slaves is the resulting operating >channel. >>>>>>>>>> >>>>>>>>>> I a more sophisticated operation, the master device may add >one >>> or >>>>>>>>>> a few backup channels extracted from the common set of >available >>>>>>>>>> channel >>>>>>>> to >>>>>>>>>> the >>>>>>>>>> message going to its slave so that if a change in channel >>>>>>>> availability >>>>>>>>>> occurs, an instantaneous switch to the next backup channel can >>> be >>>>>>>> made >>>>>>>>>> without any further signaling, thus providing for a channel >>> switch >>>>>>>> that >>>>>>>>>> is >>>>>>>>>> transparent to the user. It is the scheme that has been >included >>>>>>>>>> in >>>>>>>> the >>>>>>>>>> IEEE >>>>>>>>>> 802.22-2011 Standard. This is why I don't believe that PAWS >>> should >>>>>>>> get >>>>>>>>>> involved in defining this signaling between the base station >and >>>>>>>>>> its slaves devices. >>>>>>>>>>>> >>>>>>>>>>>> 2. If the device then uses another channel or a different >>>>>>>> channel, >>>>>>>>>> does >>>>>>>>>>>> it need to report that change to the database? >>>>>>>>>>> Scott->My interpretation of section 3.18 is that the device >can >>>>>>>> only >>>>>>>>>>> transmit within the upper& lower frequencies returned in >the >>>>>>>>>>> acknowledgment. I do not (quickly) find any reference in the >>>>>>>>>> requirements >>>>>>>>>>> to changing channels. Thus operationally it could be that the >>>>>>>> channel >>>>>>>>>>> request process must be repeated before the device can use a >>>>>>>>>> different >>>>>>>>>>> channel (frequencies). >>>>>>>>>> [GC] If the process involves 2 messages, then, the device and >>> its >>>>>>>>>> associated devices could change channels at will as long as >all >>>>>>>>>> these channels belong to the set of available channel. >However, >>> if >>>>>>>>>> the third message is added, it would make sense that the >master >>>>>>>>>> device reports to the database any channel change that would >>> occur >>>>>>>>>> to the database, otherwise, the status of >>>>>>>> the >>>>>>>>>> spectrum occupation would be wrong at any moment and would be >>>>>>>> useless >>>>>>>>>> for >>>>>>>>>> the purpose of any spectrum usage optimization such as >>>>> coexistence. >>>>>>>>>>>> >>>>>>>>>>>> Thanks! >>>>>>>>>>>> >>>>>>>>>>>> Peter >>>>>>>>>>>> >>>>>>>>>>>> On 3/8/12 10:17 AM, scott.probasco@nokia.com wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> The point from Brian is very relevant: >>>>>>>>>>>>> >>>>>>>>>>>>> Channel request >>>>>>>>>>>>> Channel response >>>>>>>>>>>>> Channel acknowledgement >>>>>>>>>>>>> >>>>>>>>>>>>> What Ofcom does with the information in the acknowledgement >>>>>>>>>>>>> does >>>>>>>>>> not >>>>>>>>>>>>> matter. As the regulator in UK, they write rules that must >be >>>>>>>>>> followed >>>>>>>>>>>>> in >>>>>>>>>>>>> order to operate a whitespace radio in the UK. I believe >the >>>>>>>> scope >>>>>>>>>> of >>>>>>>>>>>>> the >>>>>>>>>>>>> WG must be focused on a working solution. If this is simple >>>>>>>> channel >>>>>>>>>>>>> request& response in one regulator's domain, PAWS can >>> support >>>>>>>>>> this. If >>>>>>>>>>>>> it >>>>>>>>>>>>> means a channel request, response and acknowledgement in >>>>>>>>>>>>> another regulator's domain, PAWS can support this. As a >>>>>>>>>>>>> participating >>>>>>>>>> member of >>>>>>>>>>>>> the work group, I believe the scope should be basic >working >>>>>>>>>> solution, >>>>>>>>>>>>> not >>>>>>>>>>>>> limited to a specific number of messages. >>>>>>>>>>>>> >>>>>>>>>>>>> Kind Regards, >>>>>>>>>>>>> Scott >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 3/8/12 11:11 AM, "ext Zuniga, Juan Carlos" >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Peter, Nancy, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I agree should design a protocol with the best of our >>> current >>>>>>>>>>>>>> knowledge, and that should be accounting for all the known >>>>>>>>>>>>>> regulations at >>>>>>>>>> present >>>>>>>>>>>>>> time. We should not limit the scope with the purpose of >>>>>>>> designing >>>>>>>>>> a >>>>>>>>>>>>>> protocol 'faster'. Our goal is not only to design a WSDB >>>>>>>> protocol. >>>>>>>>>> Our >>>>>>>>>>>>>> goal is to design a WSDB protocol that is USEFUL to the >>>>>>>> community. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The charter does state that >>>>>>>>>>>>>> >>>>>>>>>>>>>> "...the group should also reach out to other potential >>>>>>>>>>>>>> "customers" for a white space database access method and >>>>>>>> consider >>>>>>>>>> input >>>>>>>>>>>>>> from regulatory entities that are involved in the >>>>>>>>>>>>>> specification >>>>>>>> of >>>>>>>>>> the >>>>>>>>>>>>>> rules for secondary use of spectrum in specific radio >bands. >>> " >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think that is exactly what we are doing now. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regarding whether the types of requirements belong to #1 >or >>>>>>>>>>>>>> #2, >>>>>>>> I >>>>>>>>>>>>>> believe >>>>>>>>>>>>>> it is more of #1 type, as the information to be exchanged >>>>>>>>>>>>>> would >>>>>>>> be >>>>>>>>>>>>>> known >>>>>>>>>>>>>> after the initial query/response. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If we know it today, I see no reason why we should not >work >>>>>>>>>>>>>> on >>>>>>>> it >>>>>>>>>> in >>>>>>>>>>>>>> the >>>>>>>>>>>>>> first phase of the work. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Juan Carlos >>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: paws-bounces@ietf.org [mailto:paws- >bounces@ietf.org] >>>>>>>>>>>>>>> On >>>>>>>>>> Behalf >>>>>>>>>>>>>>> Of >>>>>>>>>>>>>>> Peter Saint-Andre >>>>>>>>>>>>>>> Sent: Thursday, March 08, 2012 11:59 AM >>>>>>>>>>>>>>> To: Nancy Bravin >>>>>>>>>>>>>>> Cc: paws@ietf.org; johnny.dixon@bt.com; >>>>>>>> chris.cheeseman@bt.com; >>>>>>>>>> Pete >>>>>>>>>>>>>>> Resnick >>>>>>>>>>>>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem- >stmt- >>>>>>>>>> usecases- >>>>>>>>>>>>>>> rqmts-03: channel reporting >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Nancy, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> You are absolutely right that different locales will have >>>>>>>>>> different >>>>>>>>>>>>>>> rules and requirements. We need to understand those, and >>>>>>>>>>>>>>> work >>>>>>>> to >>>>>>>>>>>>>>> address >>>>>>>>>>>>>>> them if possible (although we don't necessarily need to >>>>>>>> address >>>>>>>>>> them >>>>>>>>>>>>>>> all >>>>>>>>>>>>>>> at the same time). I see several kinds of requirements: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1. Some requirements might lead to features beyond the >>>>>>>>>> query/response >>>>>>>>>>>>>>> protocol we've envisioned so far. One example might be >>> real- >>>>>>>> time >>>>>>>>>>>>>>> reporting about the channels that a device is actually >>> using. >>>>>>>> In >>>>>>>>>> my >>>>>>>>>>>>>>> opinion, it would be best to handle those in the next >phase >>>>>>>>>>>>>>> of >>>>>>>>>> work, >>>>>>>>>>>>>>> because as far as I can see they are outside the scope of >>>>>>>>>>>>>>> our >>>>>>>>>> charter. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2. Some requirements might be handled through by defining >>>>>>>>>> additional >>>>>>>>>>>>>>> fields that can be included in the query or response. We >>>>>>>>>> definitely >>>>>>>>>>>>>>> planned for that when working on the charter with the >IESG: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In addition, the particular >>>>>>>>>>>>>>> data exchanged between a device and a database might >>>>>>>>>>>>>>> depend >>>>>>>> on >>>>>>>>>> the >>>>>>>>>>>>>>> ranges of radio spectrum that are to be used, the >>>>>>>> requirements >>>>>>>>>> of >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> database operators and their governing regulations, and >>>>>>>> other >>>>>>>>>>>>>>> factors. >>>>>>>>>>>>>>> Therefore, the database access method and the >>>>>>>> query/response >>>>>>>>>> data >>>>>>>>>>>>>>> formats that are exchanged using that method need to be >>>>>>>>>> designed >>>>>>>>>> for >>>>>>>>>>>>>>> extensibility rather than being tied to any specific >>>>>>>> spectrum, >>>>>>>>>>>>>>> country, or phy/mac/air interface. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It's unclear to me right now if the Ofcom requirement >fits >>>>>>>> into >>>>>>>>>> #1 or >>>>>>>>>>>>>>> #2, which is why we're having this discussion. :) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Peter >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 3/7/12 8:17 PM, Nancy Bravin wrote: >>>>>>>>>>>>>>>> Peter and all, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I agree that it is important to revisit now, so that in >>> the >>>>>>>>>> future, >>>>>>>>>>>>>>>> it will be easy to align things in their proper place. >>>>>>>>>>>>>>>> Every >>>>>>>>>> country >>>>>>>>>>>>>>>> may have different regulations, spectrum, policy and >what >>>>>>>>>>>>>>>> responsibility is in the domain of the system, and what >>>>>>>>>>>>>>>> comes >>>>>>>>>> under >>>>>>>>>>>>>>>> the PAWS charter is important. Maybe some separation >>> might >>>>>>>> be >>>>>>>>>>>>>>>> possible, and dividing and clarifying issues now will >help >>>>>>>>>>>>>>>> in >>>>>>>>>> the >>>>>>>>>>>>>>>> future. Certainly it seems that the FCC may change some >>>>>>>> rules, >>>>>>>>>> and >>>>>>>>>>>>>>>> we know that Ofcom is not yet finished with their >>>>>>>> regulations. >>>>>>>>>> Canada >>>>>>>>>>>>>>>> has their own, and other countries are working on this >as >>>>>>>> well. >>>>>>>>>> Just >>>>>>>>>>>>>>>> a thought...Sharing is a realistic goal...as is off >>>>>>>> loading... >>>>>>>>>> Or you >>>>>>>>>>>>>>>> slim line and every 6 months decide what to incorporate >in >>>>>>>> the >>>>>>>>>>>>>>>> protocol based on new information, new ideas, new >>>>>>>>>>>>>>>> innovation >>>>>>>> new >>>>>>>>>>>>>>>> regulations and maybe spend more time than you could if >>>>>>>>>> addressed >>>>>>>>>>>>>>>> now. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> That way you leave the door open and outside of >>> referencing >>>>>>>> what >>>>>>>>>> is >>>>>>>>>>>>>>>> known today, by referencing regulations i.e. Ofcom, FCC, >>>>>>>>>> Industry >>>>>>>>>>>>>>>> Canada etc as of XX-XX-XXXX date. Out of scope not >>>>>>>>>>>>>>>> something >>>>>>>> we >>>>>>>>>> know >>>>>>>>>>>>>>>> enough about to say at this point, In my opinion. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> My 2 cents.. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Sincerely, Nancy >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> As your responsible Area Director (until March 28, when >>>>>>>>>>>>>>>>> Pete Resnick will take over from me), I have reviewed >>> this >>>>>>>> thread. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In my opinion (I am happy to be proven wrong), this new >>>>>>>>>> requirement >>>>>>>>>>>>>>>>> goes beyond what the charter defined as the scope of >this >>>>>>>>>> working >>>>>>>>>>>>>>>>> group, which was to enable a device to discover the >white >>>>>>>> space >>>>>>>>>>>>>>>>> available to it in its current location. Reporting >usage >>>>>>>> back >>>>>>>>>> to >>>>>>>>>>>>>>>>> the database is simply not mentioned in the charter. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Earlier in this thread, Andy Sago wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> There's no language I can find in the charter that >>>>>>>> explicitly >>>>>>>>>> puts >>>>>>>>>>>>>>>>> this out of scope. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> An IETF charter defines what the working group shall >work >>>>>>>> on. >>>>>>>>>> Many >>>>>>>>>>>>>>>>> interesting features could be developed here. However, >it >>>>>>>>>>>>>>>>> is >>>>>>>>>> not >>>>>>>>>>>>>>>>> the job of the charter to mention explicitly that each >of >>>>>>>> those >>>>>>>>>>>>>>>>> interesting features is out of scope. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The charter does say: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Once the device learns of the available white space >>> (e.g., >>>>>>>> in a >>>>>>>>>> TV >>>>>>>>>>>>>>>>> white space implementation, the list of available >>> channels >>>>>>>> at >>>>>>>>>> that >>>>>>>>>>>>>>>>> location), it can then select one of the bands from the >>>>>>>>>>>>>>>>> list >>>>>>>>>> and >>>>>>>>>>>>>>>>> begin to transmit and receive on the selected band. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This text might have assumed that no further >>> communication >>>>>>>> or >>>>>>>>>>>>>>>>> authorization was required in order to select one of >the >>>>>>>> bands >>>>>>>>>> from >>>>>>>>>>>>>>>>> the list and then transmit/receive. Perhaps that >>>>>>>>>>>>>>>>> assumption >>>>>>>> was >>>>>>>>>>>>>>>>> mistaken. If so, it would be good to have a discussion >>>>>>>>>>>>>>>>> about >>>>>>>>>> that, >>>>>>>>>>>>>>>>> so we can determine if we need to revisit the >assumptions >>>>>>>>>>>>>>>>> we >>>>>>>>>> made >>>>>>>>>>>>>>>>> early on. If in fact we made some faulty or limited >>>>>>>>>> assumptions, >>>>>>>>>>>>>>>>> then let's get that out in the open. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Peter >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 3/7/12 9:40 AM, Rosen, Brian wrote: >>>>>>>>>>>>>>>>>> I'd also suggest >>> that >>>>>>>> our >>>>>>>>>>>>>>>>>> charter limitation is really support for sharing of >>>>>>>> whitespace >>>>>>>>>> by >>>>>>>>>>>>>>>>>> whitespace devices. Reporting what you use is not >>>>>>>>>>>>>>>>>> sharing, >>>>>>>>>> it's >>>>>>>>>>>>>>>>>> just data gathering. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The point of excluding sharing was to eliminate the >>>>>>>>>> complexities >>>>>>>>>>>>>>>>>> of what constituted fairness, and what kinds of >>>>>>>> communication >>>>>>>>>>>>>>>>>> might be needed between databases, where more than one >>>>>>>> could >>>>>>>>>>>>>>>>>> supply available whitespace in a band. This doesn't >>> have >>>>>>>> any >>>>>>>>>> of >>>>>>>>>>>>>>>>>> those issues, As long as it's just sending >information, >>> I >>>>>>>>>> don't >>>>>>>>>>>>>>>>>> have a problem. Once the database is supposed to do >>>>>>>> anything >>>>>>>>>>>>>>>>>> with it that involves changing what spectrum it >reports, >>>>>>>> then >>>>>>>>>> I >>>>>>>>>>>>>>>>>> think we cross the line. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Brian >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Mar 6, 2012, at 12:28 PM, >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Joel >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Indeed, the regulator has not described the process >or >>>>>>>>>> provided >>>>>>>>>>>>>>>>>>> a flow diagram, so there may be some wrinkles, but we >>>>>>>>>>>>>>>>>>> need >>>>>>>> to >>>>>>>>>>>>>>>>>>> provide for their intent. To answer your question, >the >>>>>>>>>> channels >>>>>>>>>>>>>>>>>>> that the master will use are sent in a separate >message >>>>>>>>>>>>>>>>>>> (described in P.12 ter), that occurs after the master >>>>>>>>>> receives >>>>>>>>>>>>>>>>>>> the response to its channel request, but before the >>>>>>>>>>>>>>>>>>> master >>>>>>>>>> can >>>>>>>>>>>>>>>>>>> transmit. At this point, it knows what channels are >>>>>>>>>> available, >>>>>>>>>>>>>>>>>>> and which one it will use. As far as the slaves are >>>>>>>>>> concerned, >>>>>>>>>>>>>>>>>>> as they associate, the master will need to gather >their >>>>>>>>>> details >>>>>>>>>>>>>>>>>>> and send further channel usage messages to the >database >>>>>>>>>>>>>>>>>>> on their behalf. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Andy >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -----Original Message----- From: paws- >bounces@ietf.org >>>>>>>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] On Behalf Of Joel M. >>>>>>>> Halpern >>>>>>>>>>>>>>>>>>> Sent: 06 March 2012 17:05 To: >scott.probasco@nokia.com >>>>>>> Cc: >>>>>>>>>>>>>>>>>>> paws@ietf.org; Cheeseman,CJ,Chris,COD R; >>>>>>>> Dixon,JS,Johnny,COD >>>>>>>>>> R >>>>>>>>>>>>>>>>>>> Subject: Re: [paws] WGLC for >>>>>>>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: >channel >>>>>>>>>>>>>>>>>>> reporting >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Ahh. I think I see where the request and my >>>>>>>>>>>>>>>>>>> understanding divurge. If the idea here is that the >>>>>>>>>>>>>>>>>>> master must provide, >>>>>>>> in >>>>>>>>>>>>>>>>>>> the request, an indication of what channels it >expects >>>>>>>>>>>>>>>>>>> to >>>>>>>>>> use, >>>>>>>>>>>>>>>>>>> I can at least understand that. I will return to >>>>>>>> technical >>>>>>>>>>>>>>>>>>> concerns in a moment. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> However, when you say "provide channel usage >>>>>>>>>>>>>>>>>>> information, >>>>>>>> in >>>>>>>>>>>>>>>>>>> order to evaluate interference", what that says to me >>> is >>>>>>>>>>>>>>>>>>> providing, during operation, information as to what >>>>>>>> channels >>>>>>>>>>>>>>>>>>> are being used, and at what power levels. That is >what >>>>>>>> would >>>>>>>>>>>>>>>>>>> be needed to analyze actual interference effects. And >>>>>>>>>>>>>>>>>>> that >>>>>>>> is >>>>>>>>>>>>>>>>>>> out of scope as I understand our scope. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I do see a technical difficulty with having the >master >>>>>>>>>> provide, >>>>>>>>>>>>>>>>>>> as part of either registering or requesting spectrum >>>>>>>>>>>>>>>>>>> information, what channels it intends to use. It >>>>>>>>>>>>>>>>>>> doesn;t >>>>>>>>>> know >>>>>>>>>>>>>>>>>>> what channels it intends to use. It intends to use >>> some >>>>>>>>>> number >>>>>>>>>>>>>>>>>>> of available channels. It will figure out which ones >>>>>>>>>>>>>>>>>>> when >>>>>>>> it >>>>>>>>>>>>>>>>>>> is told what is available. How can it send that >>>>>>>> information >>>>>>>>>> in >>>>>>>>>>>>>>>>>>> the request? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: >>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> There is a similarity here with device ID. In >context >>>>>>>>>>>>>>>>>>>> of >>>>>>>>>> PAWS >>>>>>>>>>>>>>>>>>>> we are not concerned with why a device ID is >required >>>>>>>>>>>>>>>>>>>> by >>>>>>>> a >>>>>>>>>>>>>>>>>>>> regulator, we accept it is a requirement from a >>>>>>>>>>>>>>>>>>>> regulator >>>>>>>>>> and >>>>>>>>>>>>>>>>>>>> include it to the protocol. Ofcom identifies in >3.18& >>>>>>>> 3.19 >>>>>>>>>>>>>>>>>>>> that channel usage information is required and thus >we >>>>>>>> need >>>>>>>>>>>>>>>>>>>> to include this information. Since the master must >>>>>>>> provide >>>>>>>>>>>>>>>>>>>> this information prior to transmitting, PAWS will >not >>>>>>>>>>>>>>>>>>>> function in the UK without this information and thus >I >>>>>>>>>>>>>>>>>>>> believe channel usage information is integral to the >>>>>>>> channel >>>>>>>>>>>>>>>>>>>> request& response messaging. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Kind Regards, Scott >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 3/6/12 10:30 AM, "ext Joel M. >>>>>>>>>>>>>>>>>>>> Halpern" wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I would draw a distinction. Ofcom regulations >about >>>>>>>>>>>>>>>>>>>>> whitespace requests are very much relevant. Ofcom >>>>>>>>>>>>>>>>>>>>> regulations about notification of dynamic behavior >>>>>>>> (which >>>>>>>>>>>>>>>>>>>>> spectrum is being used) are not in scope as I >>>>>>>>>>>>>>>>>>>>> understand the earlier discussions, particularly >the >>>>>>>>>>>>>>>>>>>>> chartering discussions. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com >>> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> The ofcom requirements are very much relevant to >the >>>>>>>>>>>>>>>>>>>>>> scope of the PAWS WG. The only other regulatory >>>>>>>>>>>>>>>>>>>>>> requirements that we have today is the FCC. Ofcom >>>>>>>>>>>>>>>>>>>>>> requirements are a good addition to the set. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> -Raj >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On 3/6/12 10:03 AM, "ext >>>>>>>>>>>>>>>>>>>>>> andy.sago@bt.com" wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Hi Joel >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> There's no language I can find in the charter >that >>>>>>>>>>>>>>>>>>>>>>> explicitly puts this out of scope. On the other >>>>>>>>>>>>>>>>>>>>>>> hand, the charter says that the group will >>> "consider >>>>>>>>>>>>>>>>>>>>>>> input from regulatory entities", and this is one >of >>>>>>>>>>>>>>>>>>>>>>> the requirements from Ofcom that they have just >>>>>>> published. >>>>>>>>>>>>>>>>>>>>>>> The protocol will be worthless for the UK if it >>>>>>>>>>>>>>>>>>>>>>> omits some requirements. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Andy >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- From: Joel M. Halpern >>>>>>>>>>>>>>>>>>>>>>> [mailto:jmh@joelhalpern.com] Sent: 06 March 2012 >>>>>>>>>>>>>>>>>>>>>>> 15:53 >>>>>>>>>>>>>>>>>>>>>>> To: Sago,AJ,Andy,COD R Cc: paws@ietf.org; >>>>>>>>>>>>>>>>>>>>>>> Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC >for >>>>>>>>>>>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: >>>>>>>> channel >>>>>>>>>>>>>>>>>>>>>>> reporting >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> As I understand, the information you are asking >for >>>>>>>>>>>>>>>>>>>>>>> is explicitly out of scope for the working group. >>>>>>>>>>>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >>>>>>>>>>>>>>>>>>>>>>>> All >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Comparing the draft with the Ofcom requirements >at >>>>>>>>>>>>>>>>>>>>>>>> http://www.cept.org/Documents/se- >>>>>>>>>>>>>>> 43/4161/SE43(12)Info03_Draft-UK-r >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> egul >>>>>>>>>>>>>>>>>>>>>>>> atory-requirements-for-white-space-devices-in- >the- >>>>>>>> UHF- >>>>>>>>>> TV- >>>>>>>>>>>>>>> band, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I believe the WG draft is deficient in the area of >>> reporting >>>>>>>>>>>>>>>>>>>>>>>> frequencies and powers actually used by masters >>> and >>>>>>>>>>>>>>>>>>>>>>>> slaves (Ofcom requirements 3.18 and 3.19.8). >Ofcom >>>>>>>>>>>>>>>>>>>>>>>> intends to collect this data to assesses the >>> impact >>>>>>>>>>>>>>>>>>>>>>>> of aggregate interference into other services. >It >>>>>>>>>>>>>>>>>>>>>>>> would also provide usage information (frequency >in >>>>>>>>>>>>>>>>>>>>>>>> use) that would inform the operation of a kill >>>>>>>>>>>>>>>>>>>>>>>> switch capability. I suggest this deficiency can >>> be >>>>>>>>>>>>>>>>>>>>>>>> remedied with the following changes: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> New P requirements (probably best placed >following >>>>>>>>>>>>>>>>>>>>>>>> P.12): >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> P.12bis: The protocol MUST support a channel >usage >>>>>>>>>>>>>>>>>>>>>>>> message from the slave device to the master >>> device. >>>>>>>>>>>>>>>>>>>>>>>> The channel usage message MUST include >parameters >>>>>>>>>>>>>>>>>>>>>>>> as required by local regulatory requirement. >>> These >>>>>>>>>>>>>>>>>>>>>>>> parameters MAY include device ID, manufacturer's >>>>>>>>>>>>>>>>>>>>>>>> serial number, channel usage and power level >>>>>>>>>>>>>>>>>>>>>>>> information. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> P.12ter: The protocol MUST support a channel >usage >>>>>>>>>>>>>>>>>>>>>>>> message from the master device to the database. >>>>>>>>>>>>>>>>>>>>>>>> The channel usage message MUST include >parameters >>>>>>>>>>>>>>>>>>>>>>>> as required by local regulatory requirement for >>> the >>>>>>>>>>>>>>>>>>>>>>>> master and its associated slaves. These >>> parameters >>>>>>>>>>>>>>>>>>>>>>>> MAY include device ID, manufacturer's serial >>>>>>>>>>>>>>>>>>>>>>>> number, channel usage and power level >information. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> P.12qua: The protocol MUST support a channel >usage >>>>>>>>>>>>>>>>>>>>>>>> message acknowledgement. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> New O requirements (probably best placed >following >>>>>>>>>>>>>>>>>>>>>>>> O13): >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> O.13bis: According to local regulatory policy, >>>>>>>>>>>>>>>>>>>>>>>> after connecting to a master device's radio >>> network >>>>>>>>>>>>>>>>>>>>>>>> a slave device MAY inform the master device of >the >>>>>>>>>>>>>>>>>>>>>>>> actual channel usage. The slave MUST include >>>>>>>>>>>>>>>>>>>>>>>> parameters required by local regulatory policy, >>> e.g. >>>>>>>>>>>>>>>>>>>>>>>> device ID, manufacturer's serial number, channel >>>>>>>>>>>>>>>>>>>>>>>> usage and power level information. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> O.13ter: According to local regulatory policy, >a >>>>>>>>>>>>>>>>>>>>>>>> master device MAY inform the database of the >>> actual >>>>>>>>>>>>>>>>>>>>>>>> channel usage of the master and its slaves. The >>>>>>>>>>>>>>>>>>>>>>>> master MUST include parameters required by local >>>>>>>>>>>>>>>>>>>>>>>> regulatory policy, e.g. device ID, >manufacturer's >>>>>>>>>>>>>>>>>>>>>>>> serial number, channel usage and power level >>>>>>>>>>>>>>>>>>>>>>>> information of the master and its slaves. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> New steps could be introduced into one or more >use >>>>>>>>>>>>>>>>>>>>>>>> cases to cover these Ofcom requirements, e.g. >new >>>>>>>>>>>>>>>>>>>>>>>> steps 6bis and 9bis in the hotspot use case at >>>>>>>>>>>>>>>>>>>>>>>> 4.2.1: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 6bis. Prior to initiating transmission, if >>> required >>>>>>>>>>>>>>>>>>>>>>>> by local regulation, the master/AP informs the >>>>>>>>>>>>>>>>>>>>>>>> database of the channel and power level it has >>>>>>>>>>>>>>>>>>>>>>>> chosen. This is repeated for each slave that >>>>>>>>>>>>>>>>>>>>>>>> associated with the master. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 9bis. Prior to initiating transmission, if >>> required >>>>>>>>>>>>>>>>>>>>>>>> by local regulation, the slave informs the >>>>>>>>>>>>>>>>>>>>>>>> master/AP of the channel and power level it has >>>>>>>>>>>>>>>>>>>>>>>> chosen, and the master/AP relays this >information >>>>>>>>>>>>>>>>>>>>>>>> to the >>>>>>> database. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> - end of new text - >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> For information, for those not accessing the url >>> in >>>>>>>>>>>>>>>>>>>>>>>> the first paragraph of this email, the full >Ofcom >>>>>>>>>>>>>>>>>>>>>>>> requirements leading to this new PAWS text are >as >>>>>>>>>>>>>>>>>>>>>>>> follows: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 3.18 After receiving instructions from a WSDB in >>>>>>>>>>>>>>>>>>>>>>>> relation to the maximum permitted EIRPs over the >>>>>>>>>>>>>>>>>>>>>>>> DTT channels, and prior to initiating >>> transmissions >>>>>>>>>>>>>>>>>>>>>>>> within the UHF TV band, a master WSD must >>>>>>>>>>>>>>>>>>>>>>>> communicate to the WSDB the following >information: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 3.18.1 The lower and upper frequency >boundaries^13 >>>>>>>>>>>>>>>>>>>>>>>> of the in-block emissions of the master WSD, and >>>>>>>>>>>>>>>>>>>>>>>> those of the in-block emissions of its >associated >>>>>>>>>>>>>>>>>>>>>>>> slaves. A lower frequency will be specified as >>> (470 >>>>>>>>>>>>>>>>>>>>>>>> + 8k + >>>>>>>>>>>>>>>>>>>>>>>> 0.2n) MHz, with the corresponding upper >frequency >>>>>>>>>>>>>>>>>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3?4 >k >>>>>>> 3?4 >>>>>>>>>>>>>>>>>>>>>>>> 39, 0 3?4 n 3?4 39, 1 3?4 m 3?4 40, and n< >m. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 3.18.2 The maximum in-block EIRP spectral >>> densities >>>>>>>>>>>>>>>>>>>>>>>> (in dBm/(0.2 MHz)) that the master WSD, and its >>>>>>>>>>>>>>>>>>>>>>>> associated slaves, actually radiate between each >>>>>>>>>>>>>>>>>>>>>>>> reported lower frequency boundary and its >>>>>>>>>>>>>>>>>>>>>>>> corresponding upper frequency boundary. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Footnote 13 states: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> The use of upper and lower frequency boundaries >>>>>>>>>>>>>>>>>>>>>>>> (defined over a 200 kHz raster) allows a WSDB to >>>>>>>>>>>>>>>>>>>>>>>> collect more granular information with regards >to >>>>>>>>>>>>>>>>>>>>>>>> the usage of the frequency resource by >narrowband >>>>>>>>>>>>>>>>>>>>>>>> WSD technologies. The upper and lower >frequencies >>>>>>>>>>>>>>>>>>>>>>>> of a boundary pair do not straddle a DTT channel >>>>>>> boundary. >>>>>>>>>>>>>>>>>>>>>>>> Note that a WSD may transmit over multiple, >>>>>>>>>>>>>>>>>>>>>>>> non-contiguous, whole DTT channels or fractions >of >>>>>>>>>>>>>>>>>>>>>>>> DTT channels. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 3.19 A master WSD must be able to receive the >>>>>>>>>>>>>>>>>>>>>>>> following information^14 from a WSDB: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in >>> the >>>>>>>>>>>>>>>>>>>>>>>> context of 3.18, that the reported information >on >>>>>>>>>>>>>>>>>>>>>>>> the DTT channels and EIRP spectral densities >>>>>>>>>>>>>>>>>>>>>>>> actually used by the master and slave WSDs were >>>>>>>>>>>>>>>>>>>>>>>> received successfully by the WSDB^18 ]. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Footnote 14 states: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 14 While the communication of some of this >>>>>>>>>>>>>>>>>>>>>>>> information from a WSDB to a master WSD is >>>>>>>>>>>>>>>>>>>>>>>> optional, master WSDs must be able to receive >and >>>>>>>>>>>>>>>>>>>>>>>> interpret these. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Footnote 18 states: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 18 This forms part of a handshake protocol and >may >>>>>>>>>>>>>>>>>>>>>>>> be an area where industry could harmonise >without >>>>>>>>>>>>>>>>>>>>>>>> the need for an explicit requirement in the >>>>>>> regulations. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Andy >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> *From:*paws-bounces@ietf.org >>>>>>>>>>>>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] *On Behalf Of >>>>>>>>>>>>>>>>>>>>>>>> *Gabor.Bajko@nokia.com *Sent:* 05 March 2012 >19:46 >>>>>>>>>>>>>>>>>>>>>>>> *To:* paws@ietf.org *Subject:* [paws] WGLC for >>>>>>>>>>>>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> The authors of the use cases and requirements >>> draft >>>>>>>>>>>>>>>>>>>>>>>> have just posted a new version of the draft and >>>>>>>>>>>>>>>>>>>>>>>> indicated that there are no unresolved >>>>>>>>>>>>>>>>>>>>>>>> comments/issues they are aware of. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Therefore, I'd like to initiate a WG Last Call >for >>>>>>>>>>>>>>>>>>>>>>>> comments on >>>>>>>>>>>>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf- >>> paws >>>>>>>>>>>>>>>>>>>>>>>> - >>>>>>>>>> problem- >>>>>>>>>>>>>>> stmt-u >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> seca >>>>>>>>>>>>>>>>>>>>>>>> ses-rqmts-03.txt >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Please review the draft and send your comments >to >>>>>>>>>>>>>>>>>>>>>>>> the list by March 20th, 2012. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> If you review the draft and have no comments, >send >>>>>>>>>>>>>>>>>>>>>>>> a note to the list that the draft is good as it >>> is, >>>>>>>>>>>>>>>>>>>>>>>> we need these notes as much as we need the >actual >>>>>>>>>>>>>>>>>>>>>>>> comments. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Thanks, Gabor >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> paws mailing list >>>>>>>>>>> paws@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> paws mailing list >>>>>>>>>> paws@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> paws mailing list >>>>>>>>>> paws@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>> >>>>>>> ________________________________ >>>>>>> >>>>>>> >>>>> >>> >*********************************************************************** >>>>>>> * >>>>>>> ****************************************** >>>>>>> For more information visit www.ofcom.org.uk >>>>>>> >>>>>>> This email (and any attachments) is confidential and intended for >>> the >>>>>>> use of the addressee only. >>>>>>> >>>>>>> If you have received this email in error please notify the >>> originator >>>>>>> of the message and delete it from your system. >>>>>>> >>>>>>> This email has been scanned for viruses. However, you open any >>>>>>> attachments at your own risk. >>>>>>> >>>>>>> Any views expressed in this message are those of the individual >>>>> sender >>>>>>> and do not represent the views or opinions of Ofcom unless >>> expressly >>>>>>> stated otherwise. >>>>>>> >>>>> >>> >*********************************************************************** >>>>>>> * >>>>>>> ****************************************** >>>>>>> _______________________________________________ >>>>>>> paws mailing list >>>>>>> paws@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>> _______________________________________________ >>>>>>> paws mailing list >>>>>>> paws@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>> >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >> From teco@inf-net.nl Mon Mar 19 22:53:44 2012 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 42E5221E803F for ; Mon, 19 Mar 2012 22:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.733 X-Spam-Level: X-Spam-Status: No, score=-1.733 tagged_above=-999 required=5 tests=[AWL=-1.753, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, 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 tArY3uaUwH8r for ; Mon, 19 Mar 2012 22:53:41 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id A7F6021F85F8 for ; Mon, 19 Mar 2012 22:53:39 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so3759401wib.13 for ; Mon, 19 Mar 2012 22:53:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=toaqDSxT84vIOJtghtqH4Qj/piu6d4pFCXUh00+Ty1Q=; b=cwM77iMGTCAx6O9IayYDXKlbwasU3X5xz2/70Nk/duE9u6CwgHXXEhDNJzlrbZpntg DVkVks4lyrdBI/Abz91tv1a2Y01ZgwU8nblfkRpkoRgLG/zhnH6La8jgcATVptTEkCv6 rXM0aLpfT9g0Gh+8Bdk41nthuqYDhWKoC6rwEkVl9ntCFha3Ky8yk1O4sft1x+Kfsy8f X7ba/zeMutqvTkgdGrku3ne+0B3uqxesRCOQPUHCCVffGdlvNKtpH/S18UxsXckoGsfq junSgkfmfTOAACgf2yp7SkBPJcFVEiDbeeYcm35Yqljvw57pNQf9392lA95uiXV9+F95 CYeg== Received: by 10.216.135.234 with SMTP id u84mr8707825wei.108.1332222818881; Mon, 19 Mar 2012 22:53:38 -0700 (PDT) Received: from [10.87.59.172] ([80.187.201.33]) by mx.google.com with ESMTPS id fz9sm31349674wib.3.2012.03.19.22.53.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Mar 2012 22:53:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Mon, 19 Mar 2012 17:17:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <7BAC95F5A7E67643AAFB2C31BEE662D0157A034B37@SC-VEXCH2.marvell.com> <4F5A28F7.4070905@joelhalpern.com> <7BAC95F5A7E67643AAFB2C31BEE662D0157A034D48@SC-VEXCH2.marvell.com> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQluWdOmUrP/+22h73QwqFfpA2Cllih6igj94Ocvo2ZH1IOXIgKv+GcZgtXuiqAA2BOXbfen Cc: "paws@ietf.org" , "presnick@qualcomm.com" , "Reza.Karimi@ofcom.org.uk" , "johnny.dixon@bt.com" Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting 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, 20 Mar 2012 05:53:44 -0000 Op 19 mrt. 2012, om 16:17 heeft Rosen, Brian het volgende geschreven: > > Remembering that so far, it appears this discussion is out of scope: >=20 > While it may be the case that devices dynamically change their choice = of what "channels" they will use between queries of the database, it's = at least equally likely that it will get the list of available channels, = choose one, and stick to it. If they wanted to change at some point, it = seems very feasible to query the database again, since the available = spectrum may have changed. >=20 > The device can't tell the database what it's going to use before it = knows what is available. >=20 > The "ack" sequence would be: > Device to DB: What could I use at location x,y? > DB to Device: You could use channels 3, 11 or 15 > Device to DB: Okay, I'll use channel 11 What to do when switched to another channel? I can think of another extension: Device to DB: By the way, channel 15 is heavily used here. Again, lifetime of his info would be limited. Teco > Brian >=20 > On Mar 9, 2012, at 6:58 PM, Paul Lambert wrote: >=20 >>=20 >>=20 >> +1 to all of Joels comments >>=20 >> Why would a third ack message ever be different from the original = request? >>=20 >> There's been no time to connect clients or make any other interesting = choices that would change the way the spectrum would be used. The ack = is a useless message and any such informative information about the = capabilities or plans of a device to use a range of spectrum should have = been carried in the first message. >>=20 >>=20 >> Paul >>=20 >>> -----Original Message----- >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>> Sent: Friday, March 09, 2012 8:00 AM >>> To: chris.cheeseman@bt.com >>> Cc: Paul Lambert; sdas@appcomsci.com; SiewYoon.Tan@ofcom.org.uk; >>> JuanCarlos.Zuniga@InterDigital.com; Basavaraj.Patil@nokia.com; >>> gerald.chouinard@sympatico.ca; scott.probasco@nokia.com; = paws@ietf.org; >>> presnick@qualcomm.com; Reza.Karimi@ofcom.org.uk; johnny.dixon@bt.com >>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >>> rqmts-03:channel reporting >>>=20 >>> I am having trouble connecting the goal of the requirement, the = expected >>> protocol behavior, and the expected real-world operation. >>>=20 >>> Lets keep it simple. A master, connected by wired internet to the >>> World. A set of slaves who want to use whitespace to talk to the >>> master. All within a small physical space. All within the the time >>> limit of whatever answer the master gets from the database. >>>=20 >>> The Ofcom requirement is described as being important for = understanding >>> interference effects. Therefore, presumably, it needs to relate to >>> actual spectrum usage. >>>=20 >>> The stated protocol behavior is that the master would reply to the >>> shitespace database with an ack indicating what it expects to use, = at >>> what power level. >>> The way folks are writing this, I believe the intention is "respond >>> once". >>>=20 >>> As I understand such master / slave behavior (and I am by no means a >>> radio expert), the actual usage of spectrum, within the whitespace = band, >>> will depend upon how many slaves are active, and possibly on what = they >>> are doing. >>>=20 >>> If the actual usage is going to depend upon the slave device = population >>> / behavior, then the only answer the master can correctly provide is = "I >>> will use all of the whitespace you have identified, with the highest >>> power I might use. >>>=20 >>> Such an answer is a valid answer in terms of protocol and in terms = of >>> the stated regulatory requirements. However, it is utterly useless = in >>> terms of the stated goal. >>> As an engineer, I am very uncomfortable designing a protocol = messaging >>> exchange which I know will not meet the end-users needs. >>>=20 >>> Note1: If I have mischaracterized ro misunderstood what folks ahve >>> explained, I apologize. >>>=20 >>> Note2: If instead the intention is for the master to update the = database >>> every time it changes the spectrum usage pattern, then this is NOT = an >>> acknowledgment of the reply from the database. It is a dynamic = behavior >>> reporting requirement. >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 3/9/2012 6:36 AM, chris.cheeseman@bt.com wrote: >>>> Hi >>>>=20 >>>> My reading of the UK regulatory requirements that Ofcom has made >>> available is that the Acknowledgement message that must be = communicated >>> back to the database from the white space device is simply the = frequency >>> range (or ranges) and maximum eirp density that the device intends = to >>> use (a subset of what it would have been offered by the database). I >>> don't believe there is any intent to limit modulation schemes etc. = as >>> part of this exchange. This seems a relatively straightforward >>> requirement and the PAWS protocol should accommodate this if it is = to be >>> relevant for the UK regulatory environment. >>>>=20 >>>> Regards, >>>>=20 >>>> Chris >>>>=20 >>>> -----Original Message----- >>>> From: Paul Lambert [mailto:paul@marvell.com] >>>> Sent: 09 March 2012 02:15 >>>> To: Das, Subir; 'Siew Yoon Tan'; Zuniga, Juan Carlos; >>> Basavaraj.Patil@nokia.com; gerald.chouinard@sympatico.ca; >>> jmh@joelhalpern.com; scott.probasco@nokia.com >>>> Cc: paws@ietf.org; presnick@qualcomm.com; Reza Karimi; >>> Dixon,JS,Johnny,COD R; Cheeseman,CJ,Chris,COD R >>>> Subject: RE: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >>> rqmts-03:channel reporting >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> I have a question here. Is it really an acknowledgement or we = would >>>>> like to see a kind of notification message that includes channel, = and >>>>> other parameters? >>>>=20 >>>> What if it's multiple channels? What happens if the device adapts = and >>> changes between modulation technique or bandwidth? Does every = change >>> over the air need to be indicated to the GDB? >>>>=20 >>>> This Channel acknowledgement does not seem useful and would limit = real >>> world behaviors (like channel and modulation adaptation). >>>>=20 >>>> If viewed as a potential regulatory requirement - does this imply = we >>> need to parameterize the protocol to have different behaviors in >>> different regions? >>>>=20 >>>> Paul >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> Regards, >>>>> _Subir >>>>>=20 >>>>> -----Original Message----- >>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On = Behalf >>> Of >>>>> Siew Yoon Tan >>>>> Sent: Thursday, March 08, 2012 4:06 PM >>>>> To: Zuniga, Juan Carlos; Basavaraj.Patil@nokia.com; >>>>> gerald.chouinard@sympatico.ca; jmh@joelhalpern.com; >>>>> scott.probasco@nokia.com >>>>> Cc: paws@ietf.org; presnick@qualcomm.com; Reza Karimi; >>>>> johnny.dixon@bt.com; chris.cheeseman@bt.com >>>>> Subject: Re: [paws] WGLC for = draft-ietf-paws-problem-stmt-usecases- >>>>> rqmts-03:channel reporting >>>>>=20 >>>>> Dear All, >>>>>=20 >>>>> Regarding Ofcom's requirement to have a return channel as part of = the >>>>> protocol between the WSD and WSDB, I would like to confirm to >>> following >>>>> sequence of messaging >>>>>=20 >>>>> Channel request >>>>> Channel response >>>>> Channel acknowledgement >>>>>=20 >>>>> which was raised in an earlier email to this list. >>>>>=20 >>>>> Our view is that it would be beneficial to define the protocol >>> between >>>>> WSD and WSDB that supports this requirement even though how the >>>>> information could be used is still subject to discussion in the = UK. >>>>>=20 >>>>>=20 >>>>> Best regards, >>>>>=20 >>>>> Siew Yoon >>>>>=20 >>>>>=20 >>>>> ________________________________________ >>>>> From: paws-bounces@ietf.org [paws-bounces@ietf.org] on behalf of >>>>> Zuniga, Juan Carlos [JuanCarlos.Zuniga@InterDigital.com] >>>>> Sent: 08 March 2012 20:41 >>>>> To: Basavaraj.Patil@nokia.com; gerald.chouinard@sympatico.ca; >>>>> jmh@joelhalpern.com; scott.probasco@nokia.com >>>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>>>> chris.cheeseman@bt.com >>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- >>> usecases- >>>>> rqmts-03:channel reporting >>>>>=20 >>>>> Hi Raj, >>>>>=20 >>>>> I was reusing the language used from Gerald (which I know is = familiar >>>>> to people working on IEEE 802 WS groups): >>>>>=20 >>>>>>> [GC] You got it. This would be useless for spectrum regulators. >>> One >>>>>>> should realize that, from the spectrum regulator's point of = view, >>>>>>> the second and third messages could be iterated upon to optimize >>> the >>>>>>> spectrum use. >>>>>>> Knowing >>>>>>> what channels the systems in an area are using, the spectrum >>>>>>> regulators and/or other entities such as those taking care of >>>>>>> coexistence could use the database in near-real-time to iterate = on >>>>>>> the two last messages to reduce the range of channels that some >>>>>>> systems may use once they know precisely what channels are being >>>>>>> used in the area. The PAWS protocol would carry the information >>> back >>>>>>> and forth but would not be involved in such spectrum use >>> optimization. >>>>>=20 >>>>> Having said that, I have no issue sticking to the WSDB = terminology. I >>>>> like keeping things simple :) >>>>>=20 >>>>> JC >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Basavaraj.Patil@nokia.com = [mailto:Basavaraj.Patil@nokia.com] >>>>>> Sent: Thursday, March 08, 2012 3:33 PM >>>>>> To: Zuniga, Juan Carlos; gerald.chouinard@sympatico.ca; >>>>>> jmh@joelhalpern.com; scott.probasco@nokia.com >>>>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>>>>> chris.cheeseman@bt.com >>>>>> Subject: Re: [paws] WGLC for = draft-ietf-paws-problem-stmt-usecases- >>>>>> rqmts-03:channel reporting >>>>>>=20 >>>>>>=20 >>>>>> Hi JC, >>>>>>=20 >>>>>> Where/why did the coexistence manager come into the picture? Your >>>>>> comment about "communicating back to the WSDB/coexistence = manager" >>>>>> may result in further misunderstanding. If we simply stick to to >>> WSDB >>>>>> I think we are okay. >>>>>>=20 >>>>>> -Raj >>>>>>=20 >>>>>> On 3/8/12 2:25 PM, "ext Zuniga, Juan Carlos" >>>>>> wrote: >>>>>>=20 >>>>>>> So, from Gerald and Andy's comments, it seems like from the = point >>> of >>>>>> view >>>>>>> of (at least) two regulatory entities it is important for the >>>>>>> protocol >>>>>> to >>>>>>> allow communicating back to the WSDB/coexistence manager the = actual >>>>>>> channel usage after the first query is made. >>>>>>>=20 >>>>>>> This is to me a very clear requirement. >>>>>>>=20 >>>>>>> The actual messages/IEs that would carry this information should = be >>>>>>> discussed as part of the solution document, and not the >>> requirements. >>>>>>>=20 >>>>>>> JC >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >>>>>>>> Behalf >>>>>> Of >>>>>>>> Gerald Chouinard >>>>>>>> Sent: Thursday, March 08, 2012 1:59 PM >>>>>>>> To: 'Joel M. Halpern'; scott.probasco@nokia.com >>>>>>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>>>>>>> chris.cheeseman@bt.com >>>>>>>> Subject: Re: [paws] WGLC for >>>>>>>> draft-ietf-paws-problem-stmt-usecases- >>>>>>>> rqmts-03:channel reporting >>>>>>>>=20 >>>>>>>> Joel, Scott, >>>>>>>>=20 >>>>>>>> Interesting discussion! See my comments in line below. >>>>>>>>=20 >>>>>>>> Gerald >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >>>>>>>> Behalf >>>>>> Of >>>>>>>> Joel >>>>>>>> M. Halpern >>>>>>>> Sent: Thursday, 08 March, 2012 13:17 >>>>>>>> To: scott.probasco@nokia.com >>>>>>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>>>>>>> chris.cheeseman@bt.com >>>>>>>> Subject: Re: [paws] WGLC for >>>>>>>> draft-ietf-paws-problem-stmt-usecases- >>>>>>>> rqmts-03: >>>>>>>> channel reporting >>>>>>>>=20 >>>>>>>> So why won't the device simply say "I will use all of this?" >>>>>>>> [GC] This would defeat the purpose of the acknowledgement = message. >>>>>>>> After all, that way it needs to do less work with the database. >>>>>>>> And >>>>>> it >>>>>>>> can change frequencies when it wants. >>>>>>>> Given that the stated goal of the Ofcom requriement was to be = able >>>>>> to >>>>>>>> analyze interference effects, it seems that this will not = actually >>>>>> lead >>>>>>>> to them getting what they want, even if it does comply with the >>>>>>>> regulations. >>>>>>>> [GC] You got it. This would be useless for spectrum = regulators. >>>>>>>> One should realize that, from the spectrum regulator's point of >>>>>>>> view, the >>>>>> second >>>>>>>> and >>>>>>>> third messages could be iterated upon to optimize the spectrum >>> use. >>>>>>>> Knowing >>>>>>>> what channels the systems in an area are using, the spectrum >>>>>> regulators >>>>>>>> and/or other entities such as those taking care of coexistence >>>>>>>> could use the database in near-real-time to iterate on the two >>>>>>>> last messages to reduce the range of channels that some systems >>>>>>>> may use once they know precisely what channels are being used = in >>> the area. >>>>>>>> The PAWS protocol would carry >>>>>> the >>>>>>>> information back and forth but would not be involved in such >>>>>> spectrum >>>>>>>> use >>>>>>>> optimization. >>>>>>>>=20 >>>>>>>> Yours, >>>>>>>> joel >>>>>>>>=20 >>>>>>>> On 3/8/2012 1:09 PM, scott.probasco@nokia.com wrote: >>>>>>>>> Hi Peter, >>>>>>>>>=20 >>>>>>>>> Answers below. >>>>>>>>>=20 >>>>>>>>> Kind Regards, >>>>>>>>> Scott >>>>>>>>>=20 >>>>>>>>> On 3/8/12 11:39 AM, "ext Peter = Saint-Andre" >>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> Hi Scott, I have two clarifying questions: >>>>>>>>>>=20 >>>>>>>>>> 1. Does the device know, when it receives the channel = response, >>>>>>>> which >>>>>>>>>> channel it will actually use? >>>>>>>>> Scott->This is all new and I am not aware of any existing >>>>>>>> implementations. >>>>>>>>> I would argue that the device must decide what channel(s) it >>>>>>>>> will >>>>>> use >>>>>>>> when >>>>>>>>> it receives the channel response. >>>>>>>> [GC] Agree with Scott but this is only a portion of the >>>>>> considerations. >>>>>>>> If a >>>>>>>> device was to operate on its own, this would be true but a >>>>>>>> communication device usually implies at least 2 devices to >>>>>>>> communicate. Hence, the choice of the channel to be used will = need >>>>>>>> to be negotiated between the two devices before a choice can be >>>>>>>> made. The chosen channel will belong to the >>>>>> set >>>>>>>> of >>>>>>>> available channels that is common to both devices. Remember = that >>>>>> some >>>>>>>> channels may be available at one device and not at the other >>>>>>>> because >>>>>> of >>>>>>>> their geolocation or other reason. Extending this concept to a >>>>>>>> star network topology, the channel that will be selected by = this >>>>>>>> network will >>>>>> have >>>>>>>> to >>>>>>>> belong to the set of channels that are available to all = devices. >>>>>> Each >>>>>>>> device >>>>>>>> will not be able to decide by itself which channel it wants to >>> use. >>>>>>>>=20 >>>>>>>> This is why in such a star topology, it makes sense that the = slave >>>>>>>> devices to a base station or access point be represented by the >>>>>>>> base station acting as the master on their behalf to query the >>>>>>>> database and receive the list of available channels (and/or >>>>>>>> maximum EIRP per channel). It is then the responsibility of the >>>>>>>> base station to identify the set of available channels that is >>>>>>>> common for itself and all its slaves to decide on the >>>>>> channel >>>>>>>> that >>>>>>>> the network will use. As you can see, in this case, there is no >>>>>>>> need for each slave to receive its list of available channels. = On >>>>>>>> its own, it would not know what to do with it. The only thing = that >>>>>>>> needs to be sent >>>>>> from >>>>>>>> the >>>>>>>> master device to its slaves is the resulting operating channel. >>>>>>>>=20 >>>>>>>> I a more sophisticated operation, the master device may add one = or >>>>>>>> a few backup channels extracted from the common set of = available >>>>>>>> channel >>>>>> to >>>>>>>> the >>>>>>>> message going to its slave so that if a change in channel >>>>>> availability >>>>>>>> occurs, an instantaneous switch to the next backup channel can = be >>>>>> made >>>>>>>> without any further signaling, thus providing for a channel = switch >>>>>> that >>>>>>>> is >>>>>>>> transparent to the user. It is the scheme that has been = included >>>>>>>> in >>>>>> the >>>>>>>> IEEE >>>>>>>> 802.22-2011 Standard. This is why I don't believe that PAWS = should >>>>>> get >>>>>>>> involved in defining this signaling between the base station = and >>>>>>>> its slaves devices. >>>>>>>>>>=20 >>>>>>>>>> 2. If the device then uses another channel or a different >>>>>> channel, >>>>>>>> does >>>>>>>>>> it need to report that change to the database? >>>>>>>>> Scott->My interpretation of section 3.18 is that the device = can >>>>>> only >>>>>>>>> transmit within the upper& lower frequencies returned in the >>>>>>>>> acknowledgment. I do not (quickly) find any reference in the >>>>>>>> requirements >>>>>>>>> to changing channels. Thus operationally it could be that the >>>>>> channel >>>>>>>>> request process must be repeated before the device can use a >>>>>>>> different >>>>>>>>> channel (frequencies). >>>>>>>> [GC] If the process involves 2 messages, then, the device and = its >>>>>>>> associated devices could change channels at will as long as all >>>>>>>> these channels belong to the set of available channel. However, = if >>>>>>>> the third message is added, it would make sense that the master >>>>>>>> device reports to the database any channel change that would = occur >>>>>>>> to the database, otherwise, the status of >>>>>> the >>>>>>>> spectrum occupation would be wrong at any moment and would be >>>>>> useless >>>>>>>> for >>>>>>>> the purpose of any spectrum usage optimization such as >>> coexistence. >>>>>>>>>>=20 >>>>>>>>>> Thanks! >>>>>>>>>>=20 >>>>>>>>>> Peter >>>>>>>>>>=20 >>>>>>>>>> On 3/8/12 10:17 AM, scott.probasco@nokia.com wrote: >>>>>>>>>>> Hi, >>>>>>>>>>>=20 >>>>>>>>>>> The point from Brian is very relevant: >>>>>>>>>>>=20 >>>>>>>>>>> Channel request >>>>>>>>>>> Channel response >>>>>>>>>>> Channel acknowledgement >>>>>>>>>>>=20 >>>>>>>>>>> What Ofcom does with the information in the acknowledgement >>>>>>>>>>> does >>>>>>>> not >>>>>>>>>>> matter. As the regulator in UK, they write rules that must = be >>>>>>>> followed >>>>>>>>>>> in >>>>>>>>>>> order to operate a whitespace radio in the UK. I believe the >>>>>> scope >>>>>>>> of >>>>>>>>>>> the >>>>>>>>>>> WG must be focused on a working solution. If this is simple >>>>>> channel >>>>>>>>>>> request& response in one regulator's domain, PAWS can = support >>>>>>>> this. If >>>>>>>>>>> it >>>>>>>>>>> means a channel request, response and acknowledgement in >>>>>>>>>>> another regulator's domain, PAWS can support this. As a >>>>>>>>>>> participating >>>>>>>> member of >>>>>>>>>>> the work group, I believe the scope should be basic working >>>>>>>> solution, >>>>>>>>>>> not >>>>>>>>>>> limited to a specific number of messages. >>>>>>>>>>>=20 >>>>>>>>>>> Kind Regards, >>>>>>>>>>> Scott >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On 3/8/12 11:11 AM, "ext Zuniga, Juan Carlos" >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> Peter, Nancy, >>>>>>>>>>>>=20 >>>>>>>>>>>> I agree should design a protocol with the best of our = current >>>>>>>>>>>> knowledge, and that should be accounting for all the known >>>>>>>>>>>> regulations at >>>>>>>> present >>>>>>>>>>>> time. We should not limit the scope with the purpose of >>>>>> designing >>>>>>>> a >>>>>>>>>>>> protocol 'faster'. Our goal is not only to design a WSDB >>>>>> protocol. >>>>>>>> Our >>>>>>>>>>>> goal is to design a WSDB protocol that is USEFUL to the >>>>>> community. >>>>>>>>>>>>=20 >>>>>>>>>>>> The charter does state that >>>>>>>>>>>>=20 >>>>>>>>>>>> "...the group should also reach out to other potential >>>>>>>>>>>> "customers" for a white space database access method and >>>>>> consider >>>>>>>> input >>>>>>>>>>>> from regulatory entities that are involved in the >>>>>>>>>>>> specification >>>>>> of >>>>>>>> the >>>>>>>>>>>> rules for secondary use of spectrum in specific radio = bands. " >>>>>>>>>>>>=20 >>>>>>>>>>>> I think that is exactly what we are doing now. >>>>>>>>>>>>=20 >>>>>>>>>>>> Regarding whether the types of requirements belong to #1 or >>>>>>>>>>>> #2, >>>>>> I >>>>>>>>>>>> believe >>>>>>>>>>>> it is more of #1 type, as the information to be exchanged >>>>>>>>>>>> would >>>>>> be >>>>>>>>>>>> known >>>>>>>>>>>> after the initial query/response. >>>>>>>>>>>>=20 >>>>>>>>>>>> If we know it today, I see no reason why we should not work >>>>>>>>>>>> on >>>>>> it >>>>>>>> in >>>>>>>>>>>> the >>>>>>>>>>>> first phase of the work. >>>>>>>>>>>>=20 >>>>>>>>>>>> Regards, >>>>>>>>>>>>=20 >>>>>>>>>>>> Juan Carlos >>>>>>>>>>>>=20 >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] >>>>>>>>>>>>> On >>>>>>>> Behalf >>>>>>>>>>>>> Of >>>>>>>>>>>>> Peter Saint-Andre >>>>>>>>>>>>> Sent: Thursday, March 08, 2012 11:59 AM >>>>>>>>>>>>> To: Nancy Bravin >>>>>>>>>>>>> Cc: paws@ietf.org; johnny.dixon@bt.com; >>>>>> chris.cheeseman@bt.com; >>>>>>>> Pete >>>>>>>>>>>>> Resnick >>>>>>>>>>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- >>>>>>>> usecases- >>>>>>>>>>>>> rqmts-03: channel reporting >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Hi Nancy, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> You are absolutely right that different locales will have >>>>>>>> different >>>>>>>>>>>>> rules and requirements. We need to understand those, and >>>>>>>>>>>>> work >>>>>> to >>>>>>>>>>>>> address >>>>>>>>>>>>> them if possible (although we don't necessarily need to >>>>>> address >>>>>>>> them >>>>>>>>>>>>> all >>>>>>>>>>>>> at the same time). I see several kinds of requirements: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 1. Some requirements might lead to features beyond the >>>>>>>> query/response >>>>>>>>>>>>> protocol we've envisioned so far. One example might be = real- >>>>>> time >>>>>>>>>>>>> reporting about the channels that a device is actually = using. >>>>>> In >>>>>>>> my >>>>>>>>>>>>> opinion, it would be best to handle those in the next = phase >>>>>>>>>>>>> of >>>>>>>> work, >>>>>>>>>>>>> because as far as I can see they are outside the scope of >>>>>>>>>>>>> our >>>>>>>> charter. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 2. Some requirements might be handled through by defining >>>>>>>> additional >>>>>>>>>>>>> fields that can be included in the query or response. We >>>>>>>> definitely >>>>>>>>>>>>> planned for that when working on the charter with the = IESG: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> In addition, the particular >>>>>>>>>>>>> data exchanged between a device and a database might >>>>>>>>>>>>> depend >>>>>> on >>>>>>>> the >>>>>>>>>>>>> ranges of radio spectrum that are to be used, the >>>>>> requirements >>>>>>>> of >>>>>>>>>>>>> the >>>>>>>>>>>>> database operators and their governing regulations, and >>>>>> other >>>>>>>>>>>>> factors. >>>>>>>>>>>>> Therefore, the database access method and the >>>>>> query/response >>>>>>>> data >>>>>>>>>>>>> formats that are exchanged using that method need to be >>>>>>>> designed >>>>>>>> for >>>>>>>>>>>>> extensibility rather than being tied to any specific >>>>>> spectrum, >>>>>>>>>>>>> country, or phy/mac/air interface. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> It's unclear to me right now if the Ofcom requirement fits >>>>>> into >>>>>>>> #1 or >>>>>>>>>>>>> #2, which is why we're having this discussion. :) >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Peter >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On 3/7/12 8:17 PM, Nancy Bravin wrote: >>>>>>>>>>>>>> Peter and all, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I agree that it is important to revisit now, so that in = the >>>>>>>> future, >>>>>>>>>>>>>> it will be easy to align things in their proper place. >>>>>>>>>>>>>> Every >>>>>>>> country >>>>>>>>>>>>>> may have different regulations, spectrum, policy and what >>>>>>>>>>>>>> responsibility is in the domain of the system, and what >>>>>>>>>>>>>> comes >>>>>>>> under >>>>>>>>>>>>>> the PAWS charter is important. Maybe some separation = might >>>>>> be >>>>>>>>>>>>>> possible, and dividing and clarifying issues now will = help >>>>>>>>>>>>>> in >>>>>>>> the >>>>>>>>>>>>>> future. Certainly it seems that the FCC may change some >>>>>> rules, >>>>>>>> and >>>>>>>>>>>>>> we know that Ofcom is not yet finished with their >>>>>> regulations. >>>>>>>> Canada >>>>>>>>>>>>>> has their own, and other countries are working on this as >>>>>> well. >>>>>>>> Just >>>>>>>>>>>>>> a thought...Sharing is a realistic goal...as is off >>>>>> loading... >>>>>>>> Or you >>>>>>>>>>>>>> slim line and every 6 months decide what to incorporate = in >>>>>> the >>>>>>>>>>>>>> protocol based on new information, new ideas, new >>>>>>>>>>>>>> innovation >>>>>> new >>>>>>>>>>>>>> regulations and maybe spend more time than you could if >>>>>>>> addressed >>>>>>>>>>>>>> now. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> That way you leave the door open and outside of = referencing >>>>>> what >>>>>>>> is >>>>>>>>>>>>>> known today, by referencing regulations i.e. Ofcom, FCC, >>>>>>>> Industry >>>>>>>>>>>>>> Canada etc as of XX-XX-XXXX date. Out of scope not >>>>>>>>>>>>>> something >>>>>> we >>>>>>>> know >>>>>>>>>>>>>> enough about to say at this point, In my opinion. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> My 2 cents.. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Sincerely, Nancy >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> As your responsible Area Director (until March 28, when >>>>>>>>>>>>>>> Pete Resnick will take over from me), I have reviewed = this >>>>>> thread. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> In my opinion (I am happy to be proven wrong), this new >>>>>>>> requirement >>>>>>>>>>>>>>> goes beyond what the charter defined as the scope of = this >>>>>>>> working >>>>>>>>>>>>>>> group, which was to enable a device to discover the = white >>>>>> space >>>>>>>>>>>>>>> available to it in its current location. Reporting usage >>>>>> back >>>>>>>> to >>>>>>>>>>>>>>> the database is simply not mentioned in the charter. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Earlier in this thread, Andy Sago wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> There's no language I can find in the charter that >>>>>> explicitly >>>>>>>> puts >>>>>>>>>>>>>>> this out of scope. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> An IETF charter defines what the working group shall = work >>>>>> on. >>>>>>>> Many >>>>>>>>>>>>>>> interesting features could be developed here. However, = it >>>>>>>>>>>>>>> is >>>>>>>> not >>>>>>>>>>>>>>> the job of the charter to mention explicitly that each = of >>>>>> those >>>>>>>>>>>>>>> interesting features is out of scope. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The charter does say: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Once the device learns of the available white space = (e.g., >>>>>> in a >>>>>>>> TV >>>>>>>>>>>>>>> white space implementation, the list of available = channels >>>>>> at >>>>>>>> that >>>>>>>>>>>>>>> location), it can then select one of the bands from the >>>>>>>>>>>>>>> list >>>>>>>> and >>>>>>>>>>>>>>> begin to transmit and receive on the selected band. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> This text might have assumed that no further = communication >>>>>> or >>>>>>>>>>>>>>> authorization was required in order to select one of the >>>>>> bands >>>>>>>> from >>>>>>>>>>>>>>> the list and then transmit/receive. Perhaps that >>>>>>>>>>>>>>> assumption >>>>>> was >>>>>>>>>>>>>>> mistaken. If so, it would be good to have a discussion >>>>>>>>>>>>>>> about >>>>>>>> that, >>>>>>>>>>>>>>> so we can determine if we need to revisit the = assumptions >>>>>>>>>>>>>>> we >>>>>>>> made >>>>>>>>>>>>>>> early on. If in fact we made some faulty or limited >>>>>>>> assumptions, >>>>>>>>>>>>>>> then let's get that out in the open. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Peter >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On 3/7/12 9:40 AM, Rosen, Brian wrote: >>>>>>>>>>>>>>>> I'd also suggest = that >>>>>> our >>>>>>>>>>>>>>>> charter limitation is really support for sharing of >>>>>> whitespace >>>>>>>> by >>>>>>>>>>>>>>>> whitespace devices. Reporting what you use is not >>>>>>>>>>>>>>>> sharing, >>>>>>>> it's >>>>>>>>>>>>>>>> just data gathering. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> The point of excluding sharing was to eliminate the >>>>>>>> complexities >>>>>>>>>>>>>>>> of what constituted fairness, and what kinds of >>>>>> communication >>>>>>>>>>>>>>>> might be needed between databases, where more than one >>>>>> could >>>>>>>>>>>>>>>> supply available whitespace in a band. This doesn't = have >>>>>> any >>>>>>>> of >>>>>>>>>>>>>>>> those issues, As long as it's just sending information, = I >>>>>>>> don't >>>>>>>>>>>>>>>> have a problem. Once the database is supposed to do >>>>>> anything >>>>>>>>>>>>>>>> with it that involves changing what spectrum it = reports, >>>>>> then >>>>>>>> I >>>>>>>>>>>>>>>> think we cross the line. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Brian >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On Mar 6, 2012, at 12:28 PM, >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Joel >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Indeed, the regulator has not described the process or >>>>>>>> provided >>>>>>>>>>>>>>>>> a flow diagram, so there may be some wrinkles, but we >>>>>>>>>>>>>>>>> need >>>>>> to >>>>>>>>>>>>>>>>> provide for their intent. To answer your question, the >>>>>>>> channels >>>>>>>>>>>>>>>>> that the master will use are sent in a separate = message >>>>>>>>>>>>>>>>> (described in P.12 ter), that occurs after the master >>>>>>>> receives >>>>>>>>>>>>>>>>> the response to its channel request, but before the >>>>>>>>>>>>>>>>> master >>>>>>>> can >>>>>>>>>>>>>>>>> transmit. At this point, it knows what channels are >>>>>>>> available, >>>>>>>>>>>>>>>>> and which one it will use. As far as the slaves are >>>>>>>> concerned, >>>>>>>>>>>>>>>>> as they associate, the master will need to gather = their >>>>>>>> details >>>>>>>>>>>>>>>>> and send further channel usage messages to the = database >>>>>>>>>>>>>>>>> on their behalf. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Andy >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> -----Original Message----- From: paws-bounces@ietf.org >>>>>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] On Behalf Of Joel M. >>>>>> Halpern >>>>>>>>>>>>>>>>> Sent: 06 March 2012 17:05 To: scott.probasco@nokia.com >>>>> Cc: >>>>>>>>>>>>>>>>> paws@ietf.org; Cheeseman,CJ,Chris,COD R; >>>>>> Dixon,JS,Johnny,COD >>>>>>>> R >>>>>>>>>>>>>>>>> Subject: Re: [paws] WGLC for >>>>>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: = channel >>>>>>>>>>>>>>>>> reporting >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Ahh. I think I see where the request and my >>>>>>>>>>>>>>>>> understanding divurge. If the idea here is that the >>>>>>>>>>>>>>>>> master must provide, >>>>>> in >>>>>>>>>>>>>>>>> the request, an indication of what channels it expects >>>>>>>>>>>>>>>>> to >>>>>>>> use, >>>>>>>>>>>>>>>>> I can at least understand that. I will return to >>>>>> technical >>>>>>>>>>>>>>>>> concerns in a moment. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> However, when you say "provide channel usage >>>>>>>>>>>>>>>>> information, >>>>>> in >>>>>>>>>>>>>>>>> order to evaluate interference", what that says to me = is >>>>>>>>>>>>>>>>> providing, during operation, information as to what >>>>>> channels >>>>>>>>>>>>>>>>> are being used, and at what power levels. That is = what >>>>>> would >>>>>>>>>>>>>>>>> be needed to analyze actual interference effects. And >>>>>>>>>>>>>>>>> that >>>>>> is >>>>>>>>>>>>>>>>> out of scope as I understand our scope. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> I do see a technical difficulty with having the master >>>>>>>> provide, >>>>>>>>>>>>>>>>> as part of either registering or requesting spectrum >>>>>>>>>>>>>>>>> information, what channels it intends to use. It >>>>>>>>>>>>>>>>> doesn;t >>>>>>>> know >>>>>>>>>>>>>>>>> what channels it intends to use. It intends to use = some >>>>>>>> number >>>>>>>>>>>>>>>>> of available channels. It will figure out which ones >>>>>>>>>>>>>>>>> when >>>>>> it >>>>>>>>>>>>>>>>> is told what is available. How can it send that >>>>>> information >>>>>>>> in >>>>>>>>>>>>>>>>> the request? >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: >>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> There is a similarity here with device ID. In context >>>>>>>>>>>>>>>>>> of >>>>>>>> PAWS >>>>>>>>>>>>>>>>>> we are not concerned with why a device ID is required >>>>>>>>>>>>>>>>>> by >>>>>> a >>>>>>>>>>>>>>>>>> regulator, we accept it is a requirement from a >>>>>>>>>>>>>>>>>> regulator >>>>>>>> and >>>>>>>>>>>>>>>>>> include it to the protocol. Ofcom identifies in 3.18& >>>>>> 3.19 >>>>>>>>>>>>>>>>>> that channel usage information is required and thus = we >>>>>> need >>>>>>>>>>>>>>>>>> to include this information. Since the master must >>>>>> provide >>>>>>>>>>>>>>>>>> this information prior to transmitting, PAWS will not >>>>>>>>>>>>>>>>>> function in the UK without this information and thus = I >>>>>>>>>>>>>>>>>> believe channel usage information is integral to the >>>>>> channel >>>>>>>>>>>>>>>>>> request& response messaging. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Kind Regards, Scott >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> On 3/6/12 10:30 AM, "ext Joel M. >>>>>>>>>>>>>>>>>> Halpern" wrote: >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> I would draw a distinction. Ofcom regulations about >>>>>>>>>>>>>>>>>>> whitespace requests are very much relevant. Ofcom >>>>>>>>>>>>>>>>>>> regulations about notification of dynamic behavior >>>>>> (which >>>>>>>>>>>>>>>>>>> spectrum is being used) are not in scope as I >>>>>>>>>>>>>>>>>>> understand the earlier discussions, particularly the >>>>>>>>>>>>>>>>>>> chartering discussions. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com = wrote: >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> The ofcom requirements are very much relevant to = the >>>>>>>>>>>>>>>>>>>> scope of the PAWS WG. The only other regulatory >>>>>>>>>>>>>>>>>>>> requirements that we have today is the FCC. Ofcom >>>>>>>>>>>>>>>>>>>> requirements are a good addition to the set. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> -Raj >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> On 3/6/12 10:03 AM, "ext >>>>>>>>>>>>>>>>>>>> andy.sago@bt.com" wrote: >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> Hi Joel >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> There's no language I can find in the charter that >>>>>>>>>>>>>>>>>>>>> explicitly puts this out of scope. On the other >>>>>>>>>>>>>>>>>>>>> hand, the charter says that the group will = "consider >>>>>>>>>>>>>>>>>>>>> input from regulatory entities", and this is one = of >>>>>>>>>>>>>>>>>>>>> the requirements from Ofcom that they have just >>>>> published. >>>>>>>>>>>>>>>>>>>>> The protocol will be worthless for the UK if it >>>>>>>>>>>>>>>>>>>>> omits some requirements. >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> Andy >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> -----Original Message----- From: Joel M. Halpern >>>>>>>>>>>>>>>>>>>>> [mailto:jmh@joelhalpern.com] Sent: 06 March 2012 >>>>>>>>>>>>>>>>>>>>> 15:53 >>>>>>>>>>>>>>>>>>>>> To: Sago,AJ,Andy,COD R Cc: paws@ietf.org; >>>>>>>>>>>>>>>>>>>>> Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for >>>>>>>>>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: >>>>>> channel >>>>>>>>>>>>>>>>>>>>> reporting >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> As I understand, the information you are asking = for >>>>>>>>>>>>>>>>>>>>> is explicitly out of scope for the working group. >>>>>>>>>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >>>>>>>>>>>>>>>>>>>>>> All >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> Comparing the draft with the Ofcom requirements = at >>>>>>>>>>>>>>>>>>>>>> http://www.cept.org/Documents/se- >>>>>>>>>>>>> 43/4161/SE43(12)Info03_Draft-UK-r >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>> egul >>>>>>>>>>>>>>>>>>>>>> = atory-requirements-for-white-space-devices-in-the- >>>>>> UHF- >>>>>>>> TV- >>>>>>>>>>>>> band, >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>> I believe the WG draft is deficient in the area of = reporting >>>>>>>>>>>>>>>>>>>>>> frequencies and powers actually used by masters = and >>>>>>>>>>>>>>>>>>>>>> slaves (Ofcom requirements 3.18 and 3.19.8). = Ofcom >>>>>>>>>>>>>>>>>>>>>> intends to collect this data to assesses the = impact >>>>>>>>>>>>>>>>>>>>>> of aggregate interference into other services. It >>>>>>>>>>>>>>>>>>>>>> would also provide usage information (frequency = in >>>>>>>>>>>>>>>>>>>>>> use) that would inform the operation of a kill >>>>>>>>>>>>>>>>>>>>>> switch capability. I suggest this deficiency can = be >>>>>>>>>>>>>>>>>>>>>> remedied with the following changes: >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> New P requirements (probably best placed = following >>>>>>>>>>>>>>>>>>>>>> P.12): >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> P.12bis: The protocol MUST support a channel = usage >>>>>>>>>>>>>>>>>>>>>> message from the slave device to the master = device. >>>>>>>>>>>>>>>>>>>>>> The channel usage message MUST include parameters >>>>>>>>>>>>>>>>>>>>>> as required by local regulatory requirement. = These >>>>>>>>>>>>>>>>>>>>>> parameters MAY include device ID, manufacturer's >>>>>>>>>>>>>>>>>>>>>> serial number, channel usage and power level >>>>>>>>>>>>>>>>>>>>>> information. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> P.12ter: The protocol MUST support a channel = usage >>>>>>>>>>>>>>>>>>>>>> message from the master device to the database. >>>>>>>>>>>>>>>>>>>>>> The channel usage message MUST include parameters >>>>>>>>>>>>>>>>>>>>>> as required by local regulatory requirement for = the >>>>>>>>>>>>>>>>>>>>>> master and its associated slaves. These = parameters >>>>>>>>>>>>>>>>>>>>>> MAY include device ID, manufacturer's serial >>>>>>>>>>>>>>>>>>>>>> number, channel usage and power level = information. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> P.12qua: The protocol MUST support a channel = usage >>>>>>>>>>>>>>>>>>>>>> message acknowledgement. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> New O requirements (probably best placed = following >>>>>>>>>>>>>>>>>>>>>> O13): >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> O.13bis: According to local regulatory policy, >>>>>>>>>>>>>>>>>>>>>> after connecting to a master device's radio = network >>>>>>>>>>>>>>>>>>>>>> a slave device MAY inform the master device of = the >>>>>>>>>>>>>>>>>>>>>> actual channel usage. The slave MUST include >>>>>>>>>>>>>>>>>>>>>> parameters required by local regulatory policy, = e.g. >>>>>>>>>>>>>>>>>>>>>> device ID, manufacturer's serial number, channel >>>>>>>>>>>>>>>>>>>>>> usage and power level information. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> O.13ter: According to local regulatory policy, a >>>>>>>>>>>>>>>>>>>>>> master device MAY inform the database of the = actual >>>>>>>>>>>>>>>>>>>>>> channel usage of the master and its slaves. The >>>>>>>>>>>>>>>>>>>>>> master MUST include parameters required by local >>>>>>>>>>>>>>>>>>>>>> regulatory policy, e.g. device ID, manufacturer's >>>>>>>>>>>>>>>>>>>>>> serial number, channel usage and power level >>>>>>>>>>>>>>>>>>>>>> information of the master and its slaves. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> New steps could be introduced into one or more = use >>>>>>>>>>>>>>>>>>>>>> cases to cover these Ofcom requirements, e.g. new >>>>>>>>>>>>>>>>>>>>>> steps 6bis and 9bis in the hotspot use case at >>>>>>>>>>>>>>>>>>>>>> 4.2.1: >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> 6bis. Prior to initiating transmission, if = required >>>>>>>>>>>>>>>>>>>>>> by local regulation, the master/AP informs the >>>>>>>>>>>>>>>>>>>>>> database of the channel and power level it has >>>>>>>>>>>>>>>>>>>>>> chosen. This is repeated for each slave that >>>>>>>>>>>>>>>>>>>>>> associated with the master. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> 9bis. Prior to initiating transmission, if = required >>>>>>>>>>>>>>>>>>>>>> by local regulation, the slave informs the >>>>>>>>>>>>>>>>>>>>>> master/AP of the channel and power level it has >>>>>>>>>>>>>>>>>>>>>> chosen, and the master/AP relays this information >>>>>>>>>>>>>>>>>>>>>> to the >>>>> database. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> - end of new text - >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> For information, for those not accessing the url = in >>>>>>>>>>>>>>>>>>>>>> the first paragraph of this email, the full Ofcom >>>>>>>>>>>>>>>>>>>>>> requirements leading to this new PAWS text are as >>>>>>>>>>>>>>>>>>>>>> follows: >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> 3.18 After receiving instructions from a WSDB in >>>>>>>>>>>>>>>>>>>>>> relation to the maximum permitted EIRPs over the >>>>>>>>>>>>>>>>>>>>>> DTT channels, and prior to initiating = transmissions >>>>>>>>>>>>>>>>>>>>>> within the UHF TV band, a master WSD must >>>>>>>>>>>>>>>>>>>>>> communicate to the WSDB the following = information: >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> 3.18.1 The lower and upper frequency = boundaries^13 >>>>>>>>>>>>>>>>>>>>>> of the in-block emissions of the master WSD, and >>>>>>>>>>>>>>>>>>>>>> those of the in-block emissions of its associated >>>>>>>>>>>>>>>>>>>>>> slaves. A lower frequency will be specified as = (470 >>>>>>>>>>>>>>>>>>>>>> + 8k + >>>>>>>>>>>>>>>>>>>>>> 0.2n) MHz, with the corresponding upper frequency >>>>>>>>>>>>>>>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3?4 k >>>>> 3?4 >>>>>>>>>>>>>>>>>>>>>> 39, 0 3?4 n 3?4 39, 1 3?4 m 3?4 40, and n< m. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> 3.18.2 The maximum in-block EIRP spectral = densities >>>>>>>>>>>>>>>>>>>>>> (in dBm/(0.2 MHz)) that the master WSD, and its >>>>>>>>>>>>>>>>>>>>>> associated slaves, actually radiate between each >>>>>>>>>>>>>>>>>>>>>> reported lower frequency boundary and its >>>>>>>>>>>>>>>>>>>>>> corresponding upper frequency boundary. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> Footnote 13 states: >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> The use of upper and lower frequency boundaries >>>>>>>>>>>>>>>>>>>>>> (defined over a 200 kHz raster) allows a WSDB to >>>>>>>>>>>>>>>>>>>>>> collect more granular information with regards to >>>>>>>>>>>>>>>>>>>>>> the usage of the frequency resource by narrowband >>>>>>>>>>>>>>>>>>>>>> WSD technologies. The upper and lower frequencies >>>>>>>>>>>>>>>>>>>>>> of a boundary pair do not straddle a DTT channel >>>>> boundary. >>>>>>>>>>>>>>>>>>>>>> Note that a WSD may transmit over multiple, >>>>>>>>>>>>>>>>>>>>>> non-contiguous, whole DTT channels or fractions = of >>>>>>>>>>>>>>>>>>>>>> DTT channels. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> 3.19 A master WSD must be able to receive the >>>>>>>>>>>>>>>>>>>>>> following information^14 from a WSDB: >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in = the >>>>>>>>>>>>>>>>>>>>>> context of 3.18, that the reported information on >>>>>>>>>>>>>>>>>>>>>> the DTT channels and EIRP spectral densities >>>>>>>>>>>>>>>>>>>>>> actually used by the master and slave WSDs were >>>>>>>>>>>>>>>>>>>>>> received successfully by the WSDB^18 ]. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> Footnote 14 states: >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> 14 While the communication of some of this >>>>>>>>>>>>>>>>>>>>>> information from a WSDB to a master WSD is >>>>>>>>>>>>>>>>>>>>>> optional, master WSDs must be able to receive and >>>>>>>>>>>>>>>>>>>>>> interpret these. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> Footnote 18 states: >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> 18 This forms part of a handshake protocol and = may >>>>>>>>>>>>>>>>>>>>>> be an area where industry could harmonise without >>>>>>>>>>>>>>>>>>>>>> the need for an explicit requirement in the >>>>> regulations. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> Andy >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> *From:*paws-bounces@ietf.org >>>>>>>>>>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] *On Behalf Of >>>>>>>>>>>>>>>>>>>>>> *Gabor.Bajko@nokia.com *Sent:* 05 March 2012 = 19:46 >>>>>>>>>>>>>>>>>>>>>> *To:* paws@ietf.org *Subject:* [paws] WGLC for >>>>>>>>>>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> The authors of the use cases and requirements = draft >>>>>>>>>>>>>>>>>>>>>> have just posted a new version of the draft and >>>>>>>>>>>>>>>>>>>>>> indicated that there are no unresolved >>>>>>>>>>>>>>>>>>>>>> comments/issues they are aware of. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> Therefore, I'd like to initiate a WG Last Call = for >>>>>>>>>>>>>>>>>>>>>> comments on >>>>>>>>>>>>>>>>>>>>>> = http://www.ietf.org/internet-drafts/draft-ietf-paws >>>>>>>>>>>>>>>>>>>>>> - >>>>>>>> problem- >>>>>>>>>>>>> stmt-u >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>> seca >>>>>>>>>>>>>>>>>>>>>> ses-rqmts-03.txt >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> Please review the draft and send your comments to >>>>>>>>>>>>>>>>>>>>>> the list by March 20th, 2012. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> If you review the draft and have no comments, = send >>>>>>>>>>>>>>>>>>>>>> a note to the list that the draft is good as it = is, >>>>>>>>>>>>>>>>>>>>>> we need these notes as much as we need the actual >>>>>>>>>>>>>>>>>>>>>> comments. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> Thanks, Gabor >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> paws mailing list >>>>>>>>> paws@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> paws mailing list >>>>>>>> paws@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> paws mailing list >>>>>>>> paws@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>> _______________________________________________ >>>>>>> paws mailing list >>>>>>> paws@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>=20 >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>=20 >>>>> ________________________________ >>>>>=20 >>>>>=20 >>> = *********************************************************************** >>>>> * >>>>> ****************************************** >>>>> For more information visit www.ofcom.org.uk >>>>>=20 >>>>> This email (and any attachments) is confidential and intended for = the >>>>> use of the addressee only. >>>>>=20 >>>>> If you have received this email in error please notify the = originator >>>>> of the message and delete it from your system. >>>>>=20 >>>>> This email has been scanned for viruses. However, you open any >>>>> attachments at your own risk. >>>>>=20 >>>>> 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. >>>>>=20 >>> = *********************************************************************** >>>>> * >>>>> ****************************************** >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From gerald.chouinard@sympatico.ca Tue Mar 20 06:52:27 2012 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 7723521F8777 for ; Tue, 20 Mar 2012 06:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.968 X-Spam-Level: X-Spam-Status: No, score=0.968 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_92=0.6, MSGID_FROM_MTA_HEADER=0.803, 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 k-BF-qkxuFNU for ; Tue, 20 Mar 2012 06:52:24 -0700 (PDT) Received: from blu0-omc3-s22.blu0.hotmail.com (blu0-omc3-s22.blu0.hotmail.com [65.55.116.97]) by ietfa.amsl.com (Postfix) with ESMTP id E91B121F8776 for ; Tue, 20 Mar 2012 06:52:23 -0700 (PDT) Received: from BLU0-SMTP48 ([65.55.116.72]) by blu0-omc3-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Mar 2012 06:52:23 -0700 X-Originating-IP: [70.26.238.77] X-Originating-Email: [gerald.chouinard@sympatico.ca] Message-ID: Received: from Gerald2 ([70.26.238.77]) by BLU0-SMTP48.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Mar 2012 06:52:21 -0700 From: Gerald Chouinard To: "'Rosen, Brian'" References: , <7BAC95F5A7E67643AAFB2C31BEE662D0157A034B37@SC-VEXCH2.marvell.com><4F5A28F7.4070905@joelhalpern.com><7BAC95F5A7E67643AAFB2C31BEE662D0157A034D48@SC-VEXCH2.marvell.com><7BAC95F5A7E67643AAFB2C31BEE662D015E331E56C@SC-VEXCH2.marvell.com> Date: Tue, 20 Mar 2012 09:52:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac0GDANl49tVVXHtS8iUkyf8OArZCgAkuT2g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 In-Reply-To: X-OriginalArrivalTime: 20 Mar 2012 13:52:21.0704 (UTC) FILETIME=[AC310480:01CD06A0] Cc: paws@ietf.org Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting 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, 20 Mar 2012 13:52:27 -0000 Brian, What you may want to consider during the face-to-face meeting is to form an ad-hoc group that would develop a paper describing the implications of such third message back to the database to be sent to OFCOM. Although useful for the purpose of tracking the use of the spectrum, OFCOM may not have thoroughly analyzed the implications of such a requirement. The views from the protocol experts present in PAWS would very likely be appreciated in identifying the pros and cons of such an approach and would be useful in verifying its feasibility. A possible consequence of such analysis may be a precise description of this requirement with a more specific scope developed by OFCOM so that it is genuinely feasible, practical and useful. Gerald -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Rosen, Brian Sent: Monday, 19 March, 2012 16:08 To: Paul Lambert Cc: Reza.Karimi@ofcom.org.uk; paws@ietf.org; johnny.dixon@bt.com; presnick@qualcomm.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting Depends on the time period allowed for the ack. The device won't start another transaction with the database before it decides. The db doesn't have anything except a bit of state to keep if the ack takes a while. So, let it take a while. Eventually, it would decide it wasn't going to get an answer and treat it like an error (timeout). While we have to deal with charter issues, I don't like producing a protocol spec that only works with the US rules. Tracking usage is not an unreasonable regulatory requirement, and not a complicated protocol mechanism. It only gets complicated when the spectrum returned from any query depends on the usage information. That's somewhere I don't want to go yet. Let's assume, at least for now, that this subject is out of scope. We'll have a discussion of what to do in Paris, and bring that back to the list. Let's move forward on the document without this capability, and we'll pick it up later if/when we get the charter issue settled. That means I would like to stop discussion until Paris, and then we will continue it on the list. Brian On Mar 19, 2012, at 2:58 PM, Paul Lambert wrote: > >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >> Sent: Monday, March 19, 2012 8:17 AM >> To: Paul Lambert >> Cc: Joel M. Halpern; chris.cheeseman@bt.com; Reza.Karimi@ofcom.org.uk; >> paws@ietf.org; johnny.dixon@bt.com; presnick@qualcomm.com >> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >> rqmts-03:channel reporting >> >> >> Remembering that so far, it appears this discussion is out of scope: >> >> While it may be the case that devices dynamically change their choice of >> what "channels" they will use between queries of the database, it's at >> least equally likely that it will get the list of available channels, >> choose one, and stick to it. If they wanted to change at some point, it >> seems very feasible to query the database again, since the available >> spectrum may have changed. >> >> The device can't tell the database what it's going to use before it >> knows what is available. >> >> The "ack" sequence would be: >> Device to DB: What could I use at location x,y? >> DB to Device: You could use channels 3, 11 or 15 >> Device to DB: Okay, I'll use channel 11 > > But the "ack" in this sequence occurs right after the "you could use" message. Any intelligent AP/Master might some time to evaluate each channel and pick one later that has the lowest utilization. It would not have this knowledge in time for an "ack". If it picked a channel for the ack, it would likely change soon to another channel. > > Given that the "ack" has only informative information that will change - there is nothing useful that can be done by the DB with this information. Unless the Master provides continuous updates of channel utilization - there is no reason to have this information carried in an ack. > > We should not create extra messages to carry information that will not be used in any processing. > > Paul > > >> >> Brian >> >> On Mar 9, 2012, at 6:58 PM, Paul Lambert wrote: >> >>> >>> >>> +1 to all of Joels comments >>> >>> Why would a third ack message ever be different from the original >> request? >>> >>> There's been no time to connect clients or make any other interesting >> choices that would change the way the spectrum would be used. The ack >> is a useless message and any such informative information about the >> capabilities or plans of a device to use a range of spectrum should have >> been carried in the first message. >>> >>> >>> Paul >>> >>>> -----Original Message----- >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>> Sent: Friday, March 09, 2012 8:00 AM >>>> To: chris.cheeseman@bt.com >>>> Cc: Paul Lambert; sdas@appcomsci.com; SiewYoon.Tan@ofcom.org.uk; >>>> JuanCarlos.Zuniga@InterDigital.com; Basavaraj.Patil@nokia.com; >>>> gerald.chouinard@sympatico.ca; scott.probasco@nokia.com; >> paws@ietf.org; >>>> presnick@qualcomm.com; Reza.Karimi@ofcom.org.uk; johnny.dixon@bt.com >>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >>>> rqmts-03:channel reporting >>>> >>>> I am having trouble connecting the goal of the requirement, the >> expected >>>> protocol behavior, and the expected real-world operation. >>>> >>>> Lets keep it simple. A master, connected by wired internet to the >>>> World. A set of slaves who want to use whitespace to talk to the >>>> master. All within a small physical space. All within the the time >>>> limit of whatever answer the master gets from the database. >>>> >>>> The Ofcom requirement is described as being important for >> understanding >>>> interference effects. Therefore, presumably, it needs to relate to >>>> actual spectrum usage. >>>> >>>> The stated protocol behavior is that the master would reply to the >>>> shitespace database with an ack indicating what it expects to use, at >>>> what power level. >>>> The way folks are writing this, I believe the intention is "respond >>>> once". >>>> >>>> As I understand such master / slave behavior (and I am by no means a >>>> radio expert), the actual usage of spectrum, within the whitespace >> band, >>>> will depend upon how many slaves are active, and possibly on what >> they >>>> are doing. >>>> >>>> If the actual usage is going to depend upon the slave device >> population >>>> / behavior, then the only answer the master can correctly provide is >> "I >>>> will use all of the whitespace you have identified, with the highest >>>> power I might use. >>>> >>>> Such an answer is a valid answer in terms of protocol and in terms of >>>> the stated regulatory requirements. However, it is utterly useless >> in >>>> terms of the stated goal. >>>> As an engineer, I am very uncomfortable designing a protocol >> messaging >>>> exchange which I know will not meet the end-users needs. >>>> >>>> Note1: If I have mischaracterized ro misunderstood what folks ahve >>>> explained, I apologize. >>>> >>>> Note2: If instead the intention is for the master to update the >> database >>>> every time it changes the spectrum usage pattern, then this is NOT an >>>> acknowledgment of the reply from the database. It is a dynamic >> behavior >>>> reporting requirement. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 3/9/2012 6:36 AM, chris.cheeseman@bt.com wrote: >>>>> Hi >>>>> >>>>> My reading of the UK regulatory requirements that Ofcom has made >>>> available is that the Acknowledgement message that must be >> communicated >>>> back to the database from the white space device is simply the >> frequency >>>> range (or ranges) and maximum eirp density that the device intends to >>>> use (a subset of what it would have been offered by the database). I >>>> don't believe there is any intent to limit modulation schemes etc. as >>>> part of this exchange. This seems a relatively straightforward >>>> requirement and the PAWS protocol should accommodate this if it is to >> be >>>> relevant for the UK regulatory environment. >>>>> >>>>> Regards, >>>>> >>>>> Chris >>>>> >>>>> -----Original Message----- >>>>> From: Paul Lambert [mailto:paul@marvell.com] >>>>> Sent: 09 March 2012 02:15 >>>>> To: Das, Subir; 'Siew Yoon Tan'; Zuniga, Juan Carlos; >>>> Basavaraj.Patil@nokia.com; gerald.chouinard@sympatico.ca; >>>> jmh@joelhalpern.com; scott.probasco@nokia.com >>>>> Cc: paws@ietf.org; presnick@qualcomm.com; Reza Karimi; >>>> Dixon,JS,Johnny,COD R; Cheeseman,CJ,Chris,COD R >>>>> Subject: RE: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >>>> rqmts-03:channel reporting >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> I have a question here. Is it really an acknowledgement or we would >>>>>> like to see a kind of notification message that includes channel, >> and >>>>>> other parameters? >>>>> >>>>> What if it's multiple channels? What happens if the device adapts >> and >>>> changes between modulation technique or bandwidth? Does every change >>>> over the air need to be indicated to the GDB? >>>>> >>>>> This Channel acknowledgement does not seem useful and would limit >> real >>>> world behaviors (like channel and modulation adaptation). >>>>> >>>>> If viewed as a potential regulatory requirement - does this imply we >>>> need to parameterize the protocol to have different behaviors in >>>> different regions? >>>>> >>>>> Paul >>>>> >>>>> >>>>> >>>>>> >>>>>> Regards, >>>>>> _Subir >>>>>> >>>>>> -----Original Message----- >>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >> Behalf >>>> Of >>>>>> Siew Yoon Tan >>>>>> Sent: Thursday, March 08, 2012 4:06 PM >>>>>> To: Zuniga, Juan Carlos; Basavaraj.Patil@nokia.com; >>>>>> gerald.chouinard@sympatico.ca; jmh@joelhalpern.com; >>>>>> scott.probasco@nokia.com >>>>>> Cc: paws@ietf.org; presnick@qualcomm.com; Reza Karimi; >>>>>> johnny.dixon@bt.com; chris.cheeseman@bt.com >>>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >>>>>> rqmts-03:channel reporting >>>>>> >>>>>> Dear All, >>>>>> >>>>>> Regarding Ofcom's requirement to have a return channel as part of >> the >>>>>> protocol between the WSD and WSDB, I would like to confirm to >>>> following >>>>>> sequence of messaging >>>>>> >>>>>> Channel request >>>>>> Channel response >>>>>> Channel acknowledgement >>>>>> >>>>>> which was raised in an earlier email to this list. >>>>>> >>>>>> Our view is that it would be beneficial to define the protocol >>>> between >>>>>> WSD and WSDB that supports this requirement even though how the >>>>>> information could be used is still subject to discussion in the UK. >>>>>> >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Siew Yoon >>>>>> >>>>>> >>>>>> ________________________________________ >>>>>> From: paws-bounces@ietf.org [paws-bounces@ietf.org] on behalf of >>>>>> Zuniga, Juan Carlos [JuanCarlos.Zuniga@InterDigital.com] >>>>>> Sent: 08 March 2012 20:41 >>>>>> To: Basavaraj.Patil@nokia.com; gerald.chouinard@sympatico.ca; >>>>>> jmh@joelhalpern.com; scott.probasco@nokia.com >>>>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>>>>> chris.cheeseman@bt.com >>>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- >>>> usecases- >>>>>> rqmts-03:channel reporting >>>>>> >>>>>> Hi Raj, >>>>>> >>>>>> I was reusing the language used from Gerald (which I know is >> familiar >>>>>> to people working on IEEE 802 WS groups): >>>>>> >>>>>>>> [GC] You got it. This would be useless for spectrum regulators. >>>> One >>>>>>>> should realize that, from the spectrum regulator's point of view, >>>>>>>> the second and third messages could be iterated upon to optimize >>>> the >>>>>>>> spectrum use. >>>>>>>> Knowing >>>>>>>> what channels the systems in an area are using, the spectrum >>>>>>>> regulators and/or other entities such as those taking care of >>>>>>>> coexistence could use the database in near-real-time to iterate >> on >>>>>>>> the two last messages to reduce the range of channels that some >>>>>>>> systems may use once they know precisely what channels are being >>>>>>>> used in the area. The PAWS protocol would carry the information >>>> back >>>>>>>> and forth but would not be involved in such spectrum use >>>> optimization. >>>>>> >>>>>> Having said that, I have no issue sticking to the WSDB terminology. >> I >>>>>> like keeping things simple :) >>>>>> >>>>>> JC >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] >>>>>>> Sent: Thursday, March 08, 2012 3:33 PM >>>>>>> To: Zuniga, Juan Carlos; gerald.chouinard@sympatico.ca; >>>>>>> jmh@joelhalpern.com; scott.probasco@nokia.com >>>>>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>>>>>> chris.cheeseman@bt.com >>>>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- >> usecases- >>>>>>> rqmts-03:channel reporting >>>>>>> >>>>>>> >>>>>>> Hi JC, >>>>>>> >>>>>>> Where/why did the coexistence manager come into the picture? Your >>>>>>> comment about "communicating back to the WSDB/coexistence manager" >>>>>>> may result in further misunderstanding. If we simply stick to to >>>> WSDB >>>>>>> I think we are okay. >>>>>>> >>>>>>> -Raj >>>>>>> >>>>>>> On 3/8/12 2:25 PM, "ext Zuniga, Juan Carlos" >>>>>>> wrote: >>>>>>> >>>>>>>> So, from Gerald and Andy's comments, it seems like from the point >>>> of >>>>>>> view >>>>>>>> of (at least) two regulatory entities it is important for the >>>>>>>> protocol >>>>>>> to >>>>>>>> allow communicating back to the WSDB/coexistence manager the >> actual >>>>>>>> channel usage after the first query is made. >>>>>>>> >>>>>>>> This is to me a very clear requirement. >>>>>>>> >>>>>>>> The actual messages/IEs that would carry this information should >> be >>>>>>>> discussed as part of the solution document, and not the >>>> requirements. >>>>>>>> >>>>>>>> JC >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >>>>>>>>> Behalf >>>>>>> Of >>>>>>>>> Gerald Chouinard >>>>>>>>> Sent: Thursday, March 08, 2012 1:59 PM >>>>>>>>> To: 'Joel M. Halpern'; scott.probasco@nokia.com >>>>>>>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>>>>>>>> chris.cheeseman@bt.com >>>>>>>>> Subject: Re: [paws] WGLC for >>>>>>>>> draft-ietf-paws-problem-stmt-usecases- >>>>>>>>> rqmts-03:channel reporting >>>>>>>>> >>>>>>>>> Joel, Scott, >>>>>>>>> >>>>>>>>> Interesting discussion! See my comments in line below. >>>>>>>>> >>>>>>>>> Gerald >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >>>>>>>>> Behalf >>>>>>> Of >>>>>>>>> Joel >>>>>>>>> M. Halpern >>>>>>>>> Sent: Thursday, 08 March, 2012 13:17 >>>>>>>>> To: scott.probasco@nokia.com >>>>>>>>> Cc: paws@ietf.org; presnick@qualcomm.com; johnny.dixon@bt.com; >>>>>>>>> chris.cheeseman@bt.com >>>>>>>>> Subject: Re: [paws] WGLC for >>>>>>>>> draft-ietf-paws-problem-stmt-usecases- >>>>>>>>> rqmts-03: >>>>>>>>> channel reporting >>>>>>>>> >>>>>>>>> So why won't the device simply say "I will use all of this?" >>>>>>>>> [GC] This would defeat the purpose of the acknowledgement >> message. >>>>>>>>> After all, that way it needs to do less work with the database. >>>>>>>>> And >>>>>>> it >>>>>>>>> can change frequencies when it wants. >>>>>>>>> Given that the stated goal of the Ofcom requriement was to be >> able >>>>>>> to >>>>>>>>> analyze interference effects, it seems that this will not >> actually >>>>>>> lead >>>>>>>>> to them getting what they want, even if it does comply with the >>>>>>>>> regulations. >>>>>>>>> [GC] You got it. This would be useless for spectrum regulators. >>>>>>>>> One should realize that, from the spectrum regulator's point of >>>>>>>>> view, the >>>>>>> second >>>>>>>>> and >>>>>>>>> third messages could be iterated upon to optimize the spectrum >>>> use. >>>>>>>>> Knowing >>>>>>>>> what channels the systems in an area are using, the spectrum >>>>>>> regulators >>>>>>>>> and/or other entities such as those taking care of coexistence >>>>>>>>> could use the database in near-real-time to iterate on the two >>>>>>>>> last messages to reduce the range of channels that some systems >>>>>>>>> may use once they know precisely what channels are being used in >>>> the area. >>>>>>>>> The PAWS protocol would carry >>>>>>> the >>>>>>>>> information back and forth but would not be involved in such >>>>>>> spectrum >>>>>>>>> use >>>>>>>>> optimization. >>>>>>>>> >>>>>>>>> Yours, >>>>>>>>> joel >>>>>>>>> >>>>>>>>> On 3/8/2012 1:09 PM, scott.probasco@nokia.com wrote: >>>>>>>>>> Hi Peter, >>>>>>>>>> >>>>>>>>>> Answers below. >>>>>>>>>> >>>>>>>>>> Kind Regards, >>>>>>>>>> Scott >>>>>>>>>> >>>>>>>>>> On 3/8/12 11:39 AM, "ext Peter Saint-Andre" >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Scott, I have two clarifying questions: >>>>>>>>>>> >>>>>>>>>>> 1. Does the device know, when it receives the channel >> response, >>>>>>>>> which >>>>>>>>>>> channel it will actually use? >>>>>>>>>> Scott->This is all new and I am not aware of any existing >>>>>>>>> implementations. >>>>>>>>>> I would argue that the device must decide what channel(s) it >>>>>>>>>> will >>>>>>> use >>>>>>>>> when >>>>>>>>>> it receives the channel response. >>>>>>>>> [GC] Agree with Scott but this is only a portion of the >>>>>>> considerations. >>>>>>>>> If a >>>>>>>>> device was to operate on its own, this would be true but a >>>>>>>>> communication device usually implies at least 2 devices to >>>>>>>>> communicate. Hence, the choice of the channel to be used will >> need >>>>>>>>> to be negotiated between the two devices before a choice can be >>>>>>>>> made. The chosen channel will belong to the >>>>>>> set >>>>>>>>> of >>>>>>>>> available channels that is common to both devices. Remember that >>>>>>> some >>>>>>>>> channels may be available at one device and not at the other >>>>>>>>> because >>>>>>> of >>>>>>>>> their geolocation or other reason. Extending this concept to a >>>>>>>>> star network topology, the channel that will be selected by this >>>>>>>>> network will >>>>>>> have >>>>>>>>> to >>>>>>>>> belong to the set of channels that are available to all devices. >>>>>>> Each >>>>>>>>> device >>>>>>>>> will not be able to decide by itself which channel it wants to >>>> use. >>>>>>>>> >>>>>>>>> This is why in such a star topology, it makes sense that the >> slave >>>>>>>>> devices to a base station or access point be represented by the >>>>>>>>> base station acting as the master on their behalf to query the >>>>>>>>> database and receive the list of available channels (and/or >>>>>>>>> maximum EIRP per channel). It is then the responsibility of the >>>>>>>>> base station to identify the set of available channels that is >>>>>>>>> common for itself and all its slaves to decide on the >>>>>>> channel >>>>>>>>> that >>>>>>>>> the network will use. As you can see, in this case, there is no >>>>>>>>> need for each slave to receive its list of available channels. >> On >>>>>>>>> its own, it would not know what to do with it. The only thing >> that >>>>>>>>> needs to be sent >>>>>>> from >>>>>>>>> the >>>>>>>>> master device to its slaves is the resulting operating channel. >>>>>>>>> >>>>>>>>> I a more sophisticated operation, the master device may add one >> or >>>>>>>>> a few backup channels extracted from the common set of available >>>>>>>>> channel >>>>>>> to >>>>>>>>> the >>>>>>>>> message going to its slave so that if a change in channel >>>>>>> availability >>>>>>>>> occurs, an instantaneous switch to the next backup channel can >> be >>>>>>> made >>>>>>>>> without any further signaling, thus providing for a channel >> switch >>>>>>> that >>>>>>>>> is >>>>>>>>> transparent to the user. It is the scheme that has been included >>>>>>>>> in >>>>>>> the >>>>>>>>> IEEE >>>>>>>>> 802.22-2011 Standard. This is why I don't believe that PAWS >> should >>>>>>> get >>>>>>>>> involved in defining this signaling between the base station and >>>>>>>>> its slaves devices. >>>>>>>>>>> >>>>>>>>>>> 2. If the device then uses another channel or a different >>>>>>> channel, >>>>>>>>> does >>>>>>>>>>> it need to report that change to the database? >>>>>>>>>> Scott->My interpretation of section 3.18 is that the device can >>>>>>> only >>>>>>>>>> transmit within the upper& lower frequencies returned in the >>>>>>>>>> acknowledgment. I do not (quickly) find any reference in the >>>>>>>>> requirements >>>>>>>>>> to changing channels. Thus operationally it could be that the >>>>>>> channel >>>>>>>>>> request process must be repeated before the device can use a >>>>>>>>> different >>>>>>>>>> channel (frequencies). >>>>>>>>> [GC] If the process involves 2 messages, then, the device and >> its >>>>>>>>> associated devices could change channels at will as long as all >>>>>>>>> these channels belong to the set of available channel. However, >> if >>>>>>>>> the third message is added, it would make sense that the master >>>>>>>>> device reports to the database any channel change that would >> occur >>>>>>>>> to the database, otherwise, the status of >>>>>>> the >>>>>>>>> spectrum occupation would be wrong at any moment and would be >>>>>>> useless >>>>>>>>> for >>>>>>>>> the purpose of any spectrum usage optimization such as >>>> coexistence. >>>>>>>>>>> >>>>>>>>>>> Thanks! >>>>>>>>>>> >>>>>>>>>>> Peter >>>>>>>>>>> >>>>>>>>>>> On 3/8/12 10:17 AM, scott.probasco@nokia.com wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> The point from Brian is very relevant: >>>>>>>>>>>> >>>>>>>>>>>> Channel request >>>>>>>>>>>> Channel response >>>>>>>>>>>> Channel acknowledgement >>>>>>>>>>>> >>>>>>>>>>>> What Ofcom does with the information in the acknowledgement >>>>>>>>>>>> does >>>>>>>>> not >>>>>>>>>>>> matter. As the regulator in UK, they write rules that must be >>>>>>>>> followed >>>>>>>>>>>> in >>>>>>>>>>>> order to operate a whitespace radio in the UK. I believe the >>>>>>> scope >>>>>>>>> of >>>>>>>>>>>> the >>>>>>>>>>>> WG must be focused on a working solution. If this is simple >>>>>>> channel >>>>>>>>>>>> request& response in one regulator's domain, PAWS can >> support >>>>>>>>> this. If >>>>>>>>>>>> it >>>>>>>>>>>> means a channel request, response and acknowledgement in >>>>>>>>>>>> another regulator's domain, PAWS can support this. As a >>>>>>>>>>>> participating >>>>>>>>> member of >>>>>>>>>>>> the work group, I believe the scope should be basic working >>>>>>>>> solution, >>>>>>>>>>>> not >>>>>>>>>>>> limited to a specific number of messages. >>>>>>>>>>>> >>>>>>>>>>>> Kind Regards, >>>>>>>>>>>> Scott >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 3/8/12 11:11 AM, "ext Zuniga, Juan Carlos" >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Peter, Nancy, >>>>>>>>>>>>> >>>>>>>>>>>>> I agree should design a protocol with the best of our >> current >>>>>>>>>>>>> knowledge, and that should be accounting for all the known >>>>>>>>>>>>> regulations at >>>>>>>>> present >>>>>>>>>>>>> time. We should not limit the scope with the purpose of >>>>>>> designing >>>>>>>>> a >>>>>>>>>>>>> protocol 'faster'. Our goal is not only to design a WSDB >>>>>>> protocol. >>>>>>>>> Our >>>>>>>>>>>>> goal is to design a WSDB protocol that is USEFUL to the >>>>>>> community. >>>>>>>>>>>>> >>>>>>>>>>>>> The charter does state that >>>>>>>>>>>>> >>>>>>>>>>>>> "...the group should also reach out to other potential >>>>>>>>>>>>> "customers" for a white space database access method and >>>>>>> consider >>>>>>>>> input >>>>>>>>>>>>> from regulatory entities that are involved in the >>>>>>>>>>>>> specification >>>>>>> of >>>>>>>>> the >>>>>>>>>>>>> rules for secondary use of spectrum in specific radio bands. >> " >>>>>>>>>>>>> >>>>>>>>>>>>> I think that is exactly what we are doing now. >>>>>>>>>>>>> >>>>>>>>>>>>> Regarding whether the types of requirements belong to #1 or >>>>>>>>>>>>> #2, >>>>>>> I >>>>>>>>>>>>> believe >>>>>>>>>>>>> it is more of #1 type, as the information to be exchanged >>>>>>>>>>>>> would >>>>>>> be >>>>>>>>>>>>> known >>>>>>>>>>>>> after the initial query/response. >>>>>>>>>>>>> >>>>>>>>>>>>> If we know it today, I see no reason why we should not work >>>>>>>>>>>>> on >>>>>>> it >>>>>>>>> in >>>>>>>>>>>>> the >>>>>>>>>>>>> first phase of the work. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> >>>>>>>>>>>>> Juan Carlos >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] >>>>>>>>>>>>>> On >>>>>>>>> Behalf >>>>>>>>>>>>>> Of >>>>>>>>>>>>>> Peter Saint-Andre >>>>>>>>>>>>>> Sent: Thursday, March 08, 2012 11:59 AM >>>>>>>>>>>>>> To: Nancy Bravin >>>>>>>>>>>>>> Cc: paws@ietf.org; johnny.dixon@bt.com; >>>>>>> chris.cheeseman@bt.com; >>>>>>>>> Pete >>>>>>>>>>>>>> Resnick >>>>>>>>>>>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- >>>>>>>>> usecases- >>>>>>>>>>>>>> rqmts-03: channel reporting >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Nancy, >>>>>>>>>>>>>> >>>>>>>>>>>>>> You are absolutely right that different locales will have >>>>>>>>> different >>>>>>>>>>>>>> rules and requirements. We need to understand those, and >>>>>>>>>>>>>> work >>>>>>> to >>>>>>>>>>>>>> address >>>>>>>>>>>>>> them if possible (although we don't necessarily need to >>>>>>> address >>>>>>>>> them >>>>>>>>>>>>>> all >>>>>>>>>>>>>> at the same time). I see several kinds of requirements: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1. Some requirements might lead to features beyond the >>>>>>>>> query/response >>>>>>>>>>>>>> protocol we've envisioned so far. One example might be >> real- >>>>>>> time >>>>>>>>>>>>>> reporting about the channels that a device is actually >> using. >>>>>>> In >>>>>>>>> my >>>>>>>>>>>>>> opinion, it would be best to handle those in the next phase >>>>>>>>>>>>>> of >>>>>>>>> work, >>>>>>>>>>>>>> because as far as I can see they are outside the scope of >>>>>>>>>>>>>> our >>>>>>>>> charter. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2. Some requirements might be handled through by defining >>>>>>>>> additional >>>>>>>>>>>>>> fields that can be included in the query or response. We >>>>>>>>> definitely >>>>>>>>>>>>>> planned for that when working on the charter with the IESG: >>>>>>>>>>>>>> >>>>>>>>>>>>>> In addition, the particular >>>>>>>>>>>>>> data exchanged between a device and a database might >>>>>>>>>>>>>> depend >>>>>>> on >>>>>>>>> the >>>>>>>>>>>>>> ranges of radio spectrum that are to be used, the >>>>>>> requirements >>>>>>>>> of >>>>>>>>>>>>>> the >>>>>>>>>>>>>> database operators and their governing regulations, and >>>>>>> other >>>>>>>>>>>>>> factors. >>>>>>>>>>>>>> Therefore, the database access method and the >>>>>>> query/response >>>>>>>>> data >>>>>>>>>>>>>> formats that are exchanged using that method need to be >>>>>>>>> designed >>>>>>>>> for >>>>>>>>>>>>>> extensibility rather than being tied to any specific >>>>>>> spectrum, >>>>>>>>>>>>>> country, or phy/mac/air interface. >>>>>>>>>>>>>> >>>>>>>>>>>>>> It's unclear to me right now if the Ofcom requirement fits >>>>>>> into >>>>>>>>> #1 or >>>>>>>>>>>>>> #2, which is why we're having this discussion. :) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Peter >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 3/7/12 8:17 PM, Nancy Bravin wrote: >>>>>>>>>>>>>>> Peter and all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I agree that it is important to revisit now, so that in >> the >>>>>>>>> future, >>>>>>>>>>>>>>> it will be easy to align things in their proper place. >>>>>>>>>>>>>>> Every >>>>>>>>> country >>>>>>>>>>>>>>> may have different regulations, spectrum, policy and what >>>>>>>>>>>>>>> responsibility is in the domain of the system, and what >>>>>>>>>>>>>>> comes >>>>>>>>> under >>>>>>>>>>>>>>> the PAWS charter is important. Maybe some separation >> might >>>>>>> be >>>>>>>>>>>>>>> possible, and dividing and clarifying issues now will help >>>>>>>>>>>>>>> in >>>>>>>>> the >>>>>>>>>>>>>>> future. Certainly it seems that the FCC may change some >>>>>>> rules, >>>>>>>>> and >>>>>>>>>>>>>>> we know that Ofcom is not yet finished with their >>>>>>> regulations. >>>>>>>>> Canada >>>>>>>>>>>>>>> has their own, and other countries are working on this as >>>>>>> well. >>>>>>>>> Just >>>>>>>>>>>>>>> a thought...Sharing is a realistic goal...as is off >>>>>>> loading... >>>>>>>>> Or you >>>>>>>>>>>>>>> slim line and every 6 months decide what to incorporate in >>>>>>> the >>>>>>>>>>>>>>> protocol based on new information, new ideas, new >>>>>>>>>>>>>>> innovation >>>>>>> new >>>>>>>>>>>>>>> regulations and maybe spend more time than you could if >>>>>>>>> addressed >>>>>>>>>>>>>>> now. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> That way you leave the door open and outside of >> referencing >>>>>>> what >>>>>>>>> is >>>>>>>>>>>>>>> known today, by referencing regulations i.e. Ofcom, FCC, >>>>>>>>> Industry >>>>>>>>>>>>>>> Canada etc as of XX-XX-XXXX date. Out of scope not >>>>>>>>>>>>>>> something >>>>>>> we >>>>>>>>> know >>>>>>>>>>>>>>> enough about to say at this point, In my opinion. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> My 2 cents.. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Sincerely, Nancy >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> As your responsible Area Director (until March 28, when >>>>>>>>>>>>>>>> Pete Resnick will take over from me), I have reviewed >> this >>>>>>> thread. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In my opinion (I am happy to be proven wrong), this new >>>>>>>>> requirement >>>>>>>>>>>>>>>> goes beyond what the charter defined as the scope of this >>>>>>>>> working >>>>>>>>>>>>>>>> group, which was to enable a device to discover the white >>>>>>> space >>>>>>>>>>>>>>>> available to it in its current location. Reporting usage >>>>>>> back >>>>>>>>> to >>>>>>>>>>>>>>>> the database is simply not mentioned in the charter. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Earlier in this thread, Andy Sago wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> There's no language I can find in the charter that >>>>>>> explicitly >>>>>>>>> puts >>>>>>>>>>>>>>>> this out of scope. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> An IETF charter defines what the working group shall work >>>>>>> on. >>>>>>>>> Many >>>>>>>>>>>>>>>> interesting features could be developed here. However, it >>>>>>>>>>>>>>>> is >>>>>>>>> not >>>>>>>>>>>>>>>> the job of the charter to mention explicitly that each of >>>>>>> those >>>>>>>>>>>>>>>> interesting features is out of scope. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The charter does say: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Once the device learns of the available white space >> (e.g., >>>>>>> in a >>>>>>>>> TV >>>>>>>>>>>>>>>> white space implementation, the list of available >> channels >>>>>>> at >>>>>>>>> that >>>>>>>>>>>>>>>> location), it can then select one of the bands from the >>>>>>>>>>>>>>>> list >>>>>>>>> and >>>>>>>>>>>>>>>> begin to transmit and receive on the selected band. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This text might have assumed that no further >> communication >>>>>>> or >>>>>>>>>>>>>>>> authorization was required in order to select one of the >>>>>>> bands >>>>>>>>> from >>>>>>>>>>>>>>>> the list and then transmit/receive. Perhaps that >>>>>>>>>>>>>>>> assumption >>>>>>> was >>>>>>>>>>>>>>>> mistaken. If so, it would be good to have a discussion >>>>>>>>>>>>>>>> about >>>>>>>>> that, >>>>>>>>>>>>>>>> so we can determine if we need to revisit the assumptions >>>>>>>>>>>>>>>> we >>>>>>>>> made >>>>>>>>>>>>>>>> early on. If in fact we made some faulty or limited >>>>>>>>> assumptions, >>>>>>>>>>>>>>>> then let's get that out in the open. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Peter >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 3/7/12 9:40 AM, Rosen, Brian wrote: >>>>>>>>>>>>>>>>> I'd also suggest >> that >>>>>>> our >>>>>>>>>>>>>>>>> charter limitation is really support for sharing of >>>>>>> whitespace >>>>>>>>> by >>>>>>>>>>>>>>>>> whitespace devices. Reporting what you use is not >>>>>>>>>>>>>>>>> sharing, >>>>>>>>> it's >>>>>>>>>>>>>>>>> just data gathering. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The point of excluding sharing was to eliminate the >>>>>>>>> complexities >>>>>>>>>>>>>>>>> of what constituted fairness, and what kinds of >>>>>>> communication >>>>>>>>>>>>>>>>> might be needed between databases, where more than one >>>>>>> could >>>>>>>>>>>>>>>>> supply available whitespace in a band. This doesn't >> have >>>>>>> any >>>>>>>>> of >>>>>>>>>>>>>>>>> those issues, As long as it's just sending information, >> I >>>>>>>>> don't >>>>>>>>>>>>>>>>> have a problem. Once the database is supposed to do >>>>>>> anything >>>>>>>>>>>>>>>>> with it that involves changing what spectrum it reports, >>>>>>> then >>>>>>>>> I >>>>>>>>>>>>>>>>> think we cross the line. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Brian >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Mar 6, 2012, at 12:28 PM, >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Joel >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Indeed, the regulator has not described the process or >>>>>>>>> provided >>>>>>>>>>>>>>>>>> a flow diagram, so there may be some wrinkles, but we >>>>>>>>>>>>>>>>>> need >>>>>>> to >>>>>>>>>>>>>>>>>> provide for their intent. To answer your question, the >>>>>>>>> channels >>>>>>>>>>>>>>>>>> that the master will use are sent in a separate message >>>>>>>>>>>>>>>>>> (described in P.12 ter), that occurs after the master >>>>>>>>> receives >>>>>>>>>>>>>>>>>> the response to its channel request, but before the >>>>>>>>>>>>>>>>>> master >>>>>>>>> can >>>>>>>>>>>>>>>>>> transmit. At this point, it knows what channels are >>>>>>>>> available, >>>>>>>>>>>>>>>>>> and which one it will use. As far as the slaves are >>>>>>>>> concerned, >>>>>>>>>>>>>>>>>> as they associate, the master will need to gather their >>>>>>>>> details >>>>>>>>>>>>>>>>>> and send further channel usage messages to the database >>>>>>>>>>>>>>>>>> on their behalf. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Andy >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -----Original Message----- From: paws-bounces@ietf.org >>>>>>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] On Behalf Of Joel M. >>>>>>> Halpern >>>>>>>>>>>>>>>>>> Sent: 06 March 2012 17:05 To: scott.probasco@nokia.com >>>>>> Cc: >>>>>>>>>>>>>>>>>> paws@ietf.org; Cheeseman,CJ,Chris,COD R; >>>>>>> Dixon,JS,Johnny,COD >>>>>>>>> R >>>>>>>>>>>>>>>>>> Subject: Re: [paws] WGLC for >>>>>>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel >>>>>>>>>>>>>>>>>> reporting >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Ahh. I think I see where the request and my >>>>>>>>>>>>>>>>>> understanding divurge. If the idea here is that the >>>>>>>>>>>>>>>>>> master must provide, >>>>>>> in >>>>>>>>>>>>>>>>>> the request, an indication of what channels it expects >>>>>>>>>>>>>>>>>> to >>>>>>>>> use, >>>>>>>>>>>>>>>>>> I can at least understand that. I will return to >>>>>>> technical >>>>>>>>>>>>>>>>>> concerns in a moment. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> However, when you say "provide channel usage >>>>>>>>>>>>>>>>>> information, >>>>>>> in >>>>>>>>>>>>>>>>>> order to evaluate interference", what that says to me >> is >>>>>>>>>>>>>>>>>> providing, during operation, information as to what >>>>>>> channels >>>>>>>>>>>>>>>>>> are being used, and at what power levels. That is what >>>>>>> would >>>>>>>>>>>>>>>>>> be needed to analyze actual interference effects. And >>>>>>>>>>>>>>>>>> that >>>>>>> is >>>>>>>>>>>>>>>>>> out of scope as I understand our scope. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I do see a technical difficulty with having the master >>>>>>>>> provide, >>>>>>>>>>>>>>>>>> as part of either registering or requesting spectrum >>>>>>>>>>>>>>>>>> information, what channels it intends to use. It >>>>>>>>>>>>>>>>>> doesn;t >>>>>>>>> know >>>>>>>>>>>>>>>>>> what channels it intends to use. It intends to use >> some >>>>>>>>> number >>>>>>>>>>>>>>>>>> of available channels. It will figure out which ones >>>>>>>>>>>>>>>>>> when >>>>>>> it >>>>>>>>>>>>>>>>>> is told what is available. How can it send that >>>>>>> information >>>>>>>>> in >>>>>>>>>>>>>>>>>> the request? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 3/6/2012 11:48 AM, scott.probasco@nokia.com wrote: >>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> There is a similarity here with device ID. In context >>>>>>>>>>>>>>>>>>> of >>>>>>>>> PAWS >>>>>>>>>>>>>>>>>>> we are not concerned with why a device ID is required >>>>>>>>>>>>>>>>>>> by >>>>>>> a >>>>>>>>>>>>>>>>>>> regulator, we accept it is a requirement from a >>>>>>>>>>>>>>>>>>> regulator >>>>>>>>> and >>>>>>>>>>>>>>>>>>> include it to the protocol. Ofcom identifies in 3.18& >>>>>>> 3.19 >>>>>>>>>>>>>>>>>>> that channel usage information is required and thus we >>>>>>> need >>>>>>>>>>>>>>>>>>> to include this information. Since the master must >>>>>>> provide >>>>>>>>>>>>>>>>>>> this information prior to transmitting, PAWS will not >>>>>>>>>>>>>>>>>>> function in the UK without this information and thus I >>>>>>>>>>>>>>>>>>> believe channel usage information is integral to the >>>>>>> channel >>>>>>>>>>>>>>>>>>> request& response messaging. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Kind Regards, Scott >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 3/6/12 10:30 AM, "ext Joel M. >>>>>>>>>>>>>>>>>>> Halpern" wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I would draw a distinction. Ofcom regulations about >>>>>>>>>>>>>>>>>>>> whitespace requests are very much relevant. Ofcom >>>>>>>>>>>>>>>>>>>> regulations about notification of dynamic behavior >>>>>>> (which >>>>>>>>>>>>>>>>>>>> spectrum is being used) are not in scope as I >>>>>>>>>>>>>>>>>>>> understand the earlier discussions, particularly the >>>>>>>>>>>>>>>>>>>> chartering discussions. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 3/6/2012 11:22 AM, Basavaraj.Patil@nokia.com >> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> The ofcom requirements are very much relevant to the >>>>>>>>>>>>>>>>>>>>> scope of the PAWS WG. The only other regulatory >>>>>>>>>>>>>>>>>>>>> requirements that we have today is the FCC. Ofcom >>>>>>>>>>>>>>>>>>>>> requirements are a good addition to the set. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -Raj >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 3/6/12 10:03 AM, "ext >>>>>>>>>>>>>>>>>>>>> andy.sago@bt.com" wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Hi Joel >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> There's no language I can find in the charter that >>>>>>>>>>>>>>>>>>>>>> explicitly puts this out of scope. On the other >>>>>>>>>>>>>>>>>>>>>> hand, the charter says that the group will >> "consider >>>>>>>>>>>>>>>>>>>>>> input from regulatory entities", and this is one of >>>>>>>>>>>>>>>>>>>>>> the requirements from Ofcom that they have just >>>>>> published. >>>>>>>>>>>>>>>>>>>>>> The protocol will be worthless for the UK if it >>>>>>>>>>>>>>>>>>>>>> omits some requirements. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Andy >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> -----Original Message----- From: Joel M. Halpern >>>>>>>>>>>>>>>>>>>>>> [mailto:jmh@joelhalpern.com] Sent: 06 March 2012 >>>>>>>>>>>>>>>>>>>>>> 15:53 >>>>>>>>>>>>>>>>>>>>>> To: Sago,AJ,Andy,COD R Cc: paws@ietf.org; >>>>>>>>>>>>>>>>>>>>>> Gabor.Bajko@nokia.com Subject: Re: [paws] WGLC for >>>>>>>>>>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: >>>>>>> channel >>>>>>>>>>>>>>>>>>>>>> reporting >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> As I understand, the information you are asking for >>>>>>>>>>>>>>>>>>>>>> is explicitly out of scope for the working group. >>>>>>>>>>>>>>>>>>>>>> Yours, Joel >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On 3/6/2012 10:42 AM, andy.sago@bt.com wrote: >>>>>>>>>>>>>>>>>>>>>>> All >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Comparing the draft with the Ofcom requirements at >>>>>>>>>>>>>>>>>>>>>>> http://www.cept.org/Documents/se- >>>>>>>>>>>>>> 43/4161/SE43(12)Info03_Draft-UK-r >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> egul >>>>>>>>>>>>>>>>>>>>>>> atory-requirements-for-white-space-devices-in-the- >>>>>>> UHF- >>>>>>>>> TV- >>>>>>>>>>>>>> band, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> I believe the WG draft is deficient in the area of >> reporting >>>>>>>>>>>>>>>>>>>>>>> frequencies and powers actually used by masters >> and >>>>>>>>>>>>>>>>>>>>>>> slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom >>>>>>>>>>>>>>>>>>>>>>> intends to collect this data to assesses the >> impact >>>>>>>>>>>>>>>>>>>>>>> of aggregate interference into other services. It >>>>>>>>>>>>>>>>>>>>>>> would also provide usage information (frequency in >>>>>>>>>>>>>>>>>>>>>>> use) that would inform the operation of a kill >>>>>>>>>>>>>>>>>>>>>>> switch capability. I suggest this deficiency can >> be >>>>>>>>>>>>>>>>>>>>>>> remedied with the following changes: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> New P requirements (probably best placed following >>>>>>>>>>>>>>>>>>>>>>> P.12): >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> P.12bis: The protocol MUST support a channel usage >>>>>>>>>>>>>>>>>>>>>>> message from the slave device to the master >> device. >>>>>>>>>>>>>>>>>>>>>>> The channel usage message MUST include parameters >>>>>>>>>>>>>>>>>>>>>>> as required by local regulatory requirement. >> These >>>>>>>>>>>>>>>>>>>>>>> parameters MAY include device ID, manufacturer's >>>>>>>>>>>>>>>>>>>>>>> serial number, channel usage and power level >>>>>>>>>>>>>>>>>>>>>>> information. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> P.12ter: The protocol MUST support a channel usage >>>>>>>>>>>>>>>>>>>>>>> message from the master device to the database. >>>>>>>>>>>>>>>>>>>>>>> The channel usage message MUST include parameters >>>>>>>>>>>>>>>>>>>>>>> as required by local regulatory requirement for >> the >>>>>>>>>>>>>>>>>>>>>>> master and its associated slaves. These >> parameters >>>>>>>>>>>>>>>>>>>>>>> MAY include device ID, manufacturer's serial >>>>>>>>>>>>>>>>>>>>>>> number, channel usage and power level information. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> P.12qua: The protocol MUST support a channel usage >>>>>>>>>>>>>>>>>>>>>>> message acknowledgement. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> New O requirements (probably best placed following >>>>>>>>>>>>>>>>>>>>>>> O13): >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> O.13bis: According to local regulatory policy, >>>>>>>>>>>>>>>>>>>>>>> after connecting to a master device's radio >> network >>>>>>>>>>>>>>>>>>>>>>> a slave device MAY inform the master device of the >>>>>>>>>>>>>>>>>>>>>>> actual channel usage. The slave MUST include >>>>>>>>>>>>>>>>>>>>>>> parameters required by local regulatory policy, >> e.g. >>>>>>>>>>>>>>>>>>>>>>> device ID, manufacturer's serial number, channel >>>>>>>>>>>>>>>>>>>>>>> usage and power level information. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> O.13ter: According to local regulatory policy, a >>>>>>>>>>>>>>>>>>>>>>> master device MAY inform the database of the >> actual >>>>>>>>>>>>>>>>>>>>>>> channel usage of the master and its slaves. The >>>>>>>>>>>>>>>>>>>>>>> master MUST include parameters required by local >>>>>>>>>>>>>>>>>>>>>>> regulatory policy, e.g. device ID, manufacturer's >>>>>>>>>>>>>>>>>>>>>>> serial number, channel usage and power level >>>>>>>>>>>>>>>>>>>>>>> information of the master and its slaves. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> New steps could be introduced into one or more use >>>>>>>>>>>>>>>>>>>>>>> cases to cover these Ofcom requirements, e.g. new >>>>>>>>>>>>>>>>>>>>>>> steps 6bis and 9bis in the hotspot use case at >>>>>>>>>>>>>>>>>>>>>>> 4.2.1: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 6bis. Prior to initiating transmission, if >> required >>>>>>>>>>>>>>>>>>>>>>> by local regulation, the master/AP informs the >>>>>>>>>>>>>>>>>>>>>>> database of the channel and power level it has >>>>>>>>>>>>>>>>>>>>>>> chosen. This is repeated for each slave that >>>>>>>>>>>>>>>>>>>>>>> associated with the master. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 9bis. Prior to initiating transmission, if >> required >>>>>>>>>>>>>>>>>>>>>>> by local regulation, the slave informs the >>>>>>>>>>>>>>>>>>>>>>> master/AP of the channel and power level it has >>>>>>>>>>>>>>>>>>>>>>> chosen, and the master/AP relays this information >>>>>>>>>>>>>>>>>>>>>>> to the >>>>>> database. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> - end of new text - >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> For information, for those not accessing the url >> in >>>>>>>>>>>>>>>>>>>>>>> the first paragraph of this email, the full Ofcom >>>>>>>>>>>>>>>>>>>>>>> requirements leading to this new PAWS text are as >>>>>>>>>>>>>>>>>>>>>>> follows: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 3.18 After receiving instructions from a WSDB in >>>>>>>>>>>>>>>>>>>>>>> relation to the maximum permitted EIRPs over the >>>>>>>>>>>>>>>>>>>>>>> DTT channels, and prior to initiating >> transmissions >>>>>>>>>>>>>>>>>>>>>>> within the UHF TV band, a master WSD must >>>>>>>>>>>>>>>>>>>>>>> communicate to the WSDB the following information: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 3.18.1 The lower and upper frequency boundaries^13 >>>>>>>>>>>>>>>>>>>>>>> of the in-block emissions of the master WSD, and >>>>>>>>>>>>>>>>>>>>>>> those of the in-block emissions of its associated >>>>>>>>>>>>>>>>>>>>>>> slaves. A lower frequency will be specified as >> (470 >>>>>>>>>>>>>>>>>>>>>>> + 8k + >>>>>>>>>>>>>>>>>>>>>>> 0.2n) MHz, with the corresponding upper frequency >>>>>>>>>>>>>>>>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3?4 k >>>>>> 3?4 >>>>>>>>>>>>>>>>>>>>>>> 39, 0 3?4 n 3?4 39, 1 3?4 m 3?4 40, and n< m. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 3.18.2 The maximum in-block EIRP spectral >> densities >>>>>>>>>>>>>>>>>>>>>>> (in dBm/(0.2 MHz)) that the master WSD, and its >>>>>>>>>>>>>>>>>>>>>>> associated slaves, actually radiate between each >>>>>>>>>>>>>>>>>>>>>>> reported lower frequency boundary and its >>>>>>>>>>>>>>>>>>>>>>> corresponding upper frequency boundary. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Footnote 13 states: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> The use of upper and lower frequency boundaries >>>>>>>>>>>>>>>>>>>>>>> (defined over a 200 kHz raster) allows a WSDB to >>>>>>>>>>>>>>>>>>>>>>> collect more granular information with regards to >>>>>>>>>>>>>>>>>>>>>>> the usage of the frequency resource by narrowband >>>>>>>>>>>>>>>>>>>>>>> WSD technologies. The upper and lower frequencies >>>>>>>>>>>>>>>>>>>>>>> of a boundary pair do not straddle a DTT channel >>>>>> boundary. >>>>>>>>>>>>>>>>>>>>>>> Note that a WSD may transmit over multiple, >>>>>>>>>>>>>>>>>>>>>>> non-contiguous, whole DTT channels or fractions of >>>>>>>>>>>>>>>>>>>>>>> DTT channels. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 3.19 A master WSD must be able to receive the >>>>>>>>>>>>>>>>>>>>>>> following information^14 from a WSDB: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in >> the >>>>>>>>>>>>>>>>>>>>>>> context of 3.18, that the reported information on >>>>>>>>>>>>>>>>>>>>>>> the DTT channels and EIRP spectral densities >>>>>>>>>>>>>>>>>>>>>>> actually used by the master and slave WSDs were >>>>>>>>>>>>>>>>>>>>>>> received successfully by the WSDB^18 ]. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Footnote 14 states: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 14 While the communication of some of this >>>>>>>>>>>>>>>>>>>>>>> information from a WSDB to a master WSD is >>>>>>>>>>>>>>>>>>>>>>> optional, master WSDs must be able to receive and >>>>>>>>>>>>>>>>>>>>>>> interpret these. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Footnote 18 states: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 18 This forms part of a handshake protocol and may >>>>>>>>>>>>>>>>>>>>>>> be an area where industry could harmonise without >>>>>>>>>>>>>>>>>>>>>>> the need for an explicit requirement in the >>>>>> regulations. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Andy >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> *From:*paws-bounces@ietf.org >>>>>>>>>>>>>>>>>>>>>>> [mailto:paws-bounces@ietf.org] *On Behalf Of >>>>>>>>>>>>>>>>>>>>>>> *Gabor.Bajko@nokia.com *Sent:* 05 March 2012 19:46 >>>>>>>>>>>>>>>>>>>>>>> *To:* paws@ietf.org *Subject:* [paws] WGLC for >>>>>>>>>>>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> The authors of the use cases and requirements >> draft >>>>>>>>>>>>>>>>>>>>>>> have just posted a new version of the draft and >>>>>>>>>>>>>>>>>>>>>>> indicated that there are no unresolved >>>>>>>>>>>>>>>>>>>>>>> comments/issues they are aware of. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Therefore, I'd like to initiate a WG Last Call for >>>>>>>>>>>>>>>>>>>>>>> comments on >>>>>>>>>>>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf- >> paws >>>>>>>>>>>>>>>>>>>>>>> - >>>>>>>>> problem- >>>>>>>>>>>>>> stmt-u >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> seca >>>>>>>>>>>>>>>>>>>>>>> ses-rqmts-03.txt >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Please review the draft and send your comments to >>>>>>>>>>>>>>>>>>>>>>> the list by March 20th, 2012. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> If you review the draft and have no comments, send >>>>>>>>>>>>>>>>>>>>>>> a note to the list that the draft is good as it >> is, >>>>>>>>>>>>>>>>>>>>>>> we need these notes as much as we need the actual >>>>>>>>>>>>>>>>>>>>>>> comments. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks, Gabor >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> paws mailing list >>>>>>>>>> paws@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> paws mailing list >>>>>>>>> paws@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> paws mailing list >>>>>>>>> paws@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> >>>>>> ________________________________ >>>>>> >>>>>> >>>> >> *********************************************************************** >>>>>> * >>>>>> ****************************************** >>>>>> For more information visit www.ofcom.org.uk >>>>>> >>>>>> This email (and any attachments) is confidential and intended for >> the >>>>>> use of the addressee only. >>>>>> >>>>>> If you have received this email in error please notify the >> originator >>>>>> of the message and delete it from your system. >>>>>> >>>>>> This email has been scanned for viruses. However, you open any >>>>>> attachments at your own risk. >>>>>> >>>>>> Any views expressed in this message are those of the individual >>>> sender >>>>>> and do not represent the views or opinions of Ofcom unless >> expressly >>>>>> stated otherwise. >>>>>> >>>> >> *********************************************************************** >>>>>> * >>>>>> ****************************************** >>>>>> _______________________________________________ >>>>>> paws mailing list >>>>>> paws@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>> _______________________________________________ >>>>>> paws mailing list >>>>>> paws@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From budden@nps.edu Wed Mar 21 11:40:27 2012 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 0BB4221F8602 for ; Wed, 21 Mar 2012 11:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.084 X-Spam-Level: X-Spam-Status: No, score=-1.084 tagged_above=-999 required=5 tests=[AWL=-1.086, BAYES_50=0.001, 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 5Opic-EMBno4 for ; Wed, 21 Mar 2012 11:40:23 -0700 (PDT) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id D208C21F8603 for ; Wed, 21 Mar 2012 11:40:23 -0700 (PDT) X-ASG-Debug-ID: 1332355222-036c920494aa3a0001-Z0ZA9G Received: from gulfstream.ern.nps.edu (gulfstream.ern.nps.edu [172.20.24.113]) by mule.nps.edu with ESMTP id z4pWmmtgMhA1173W for ; Wed, 21 Mar 2012 11:40:22 -0700 (PDT) X-Barracuda-Envelope-From: budden@nps.edu Received: from [172.20.58.67] (172.20.58.67) by smtp.nps.edu (172.20.24.113) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 21 Mar 2012 11:40:22 -0700 From: Rex Buddenberg X-ASG-Orig-Subj: [Fwd: Fighting a Wild Land Fire: How Much Spectrum Does Public Safety Need?] To: Content-Type: multipart/mixed; boundary="=-ER1aKCNMkaFUcS4Y+zWb" Date: Wed, 21 Mar 2012 11:39:37 -0700 Message-ID: <1332355177.22388.349.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) X-Barracuda-Connect: gulfstream.ern.nps.edu[172.20.24.113] X-Barracuda-Start-Time: 1332355222 X-Barracuda-URL: http://205.155.65.106:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at nps.edu X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.91864 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Subject: [paws] [Fwd: Fighting a Wild Land Fire: How Much Spectrum Does Public Safety Need?] 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, 21 Mar 2012 18:40:27 -0000 --=-ER1aKCNMkaFUcS4Y+zWb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit A glimpse of the conversation in the emergency services community. The case study here was wildfire in Arizona, geography where we'd expect white space to be available.... --=-ER1aKCNMkaFUcS4Y+zWb Content-Disposition: inline Content-Description: Forwarded message - Fighting a Wild Land Fire: How Much Spectrum Does Public Safety Need? Content-Type: message/rfc822 Received: from morgan.nps.edu (205.155.65.62) by HERCULES.ern.nps.edu (172.20.24.111) with Microsoft SMTP Server id 14.1.355.2; Wed, 21 Mar 2012 11:16:38 -0700 X-ASG-Debug-ID: 1332353777-00af556a7405380001-qo6XFg Received: from haven.nps.navy.mil (haven.nps.navy.mil [131.120.251.28]) by morgan.nps.edu with ESMTP id jGSJghaW0b0AEqqC for ; Wed, 21 Mar 2012 11:16:17 -0700 (PDT) X-Barracuda-Envelope-From: ESC1109583805414_1101582676594_2249_r20@in.constantcontact.com X-Barracuda-Apparent-Source-IP: 131.120.251.28 X-ASG-Whitelist: Client Received: from ccm33.constantcontact.com (ccm33.constantcontact.com [208.75.123.193]) by haven.nps.navy.mil with ESMTP id Ar1JCJmo9p8xaOi0 for ; Wed, 21 Mar 2012 11:16:14 -0700 (PDT) Received: from p2-jbsched06.ad.prodcc.net (p2-pen4.ad.prodcc.net [10.252.0.104]) by p2-mail189.ccm33.constantcontact.com (Postfix) with ESMTP id E7B0A90DC48 for ; Wed, 21 Mar 2012 14:16:13 -0400 (EDT) DKIM-Signature: v=1; q=dns/txt; a=rsa-sha256; c=relaxed/relaxed; s=112877; d=npstc.ccsend.com; h=to:subject:mime-version:message-id:from:date:sender:list-unsubscribe:reply-to; bh=raCjGMnpTocAGG6LETtBwC51mumcac6nFpoYMztfiuU=; b=MwOcopYgLIMHqbEYELF8fepv2S0pepVV0ert02XxFXDh03d6ksujk2XZgl777gKuatHU8KnqPSxjMo0mzxnfDkulHGUauGNbApDZDt6Nz1xHet08lAEDKnADF5gPRpVlpHBCwJdxwu6cWuLanrv4uNTpDsTFG0Y8NCMZF33a8Ew= Message-ID: <1109583805414.1101582676594.2249.6.2514151A@scheduler> Date: Wed, 21 Mar 2012 14:16:13 -0400 From: National Public Safety Telecommunications Council Reply-To: Sender: National Public Safety Telecommunications Council To: Subject: Fighting a Wild Land Fire: How Much Spectrum Does Public Safety Need? X-ASG-Orig-Subj: Fighting a Wild Land Fire: How Much Spectrum Does Public Safety Need? Content-Type: multipart/alternative; boundary="----=_Part_6980129_1823636651.1332353773935" X-Mailer: Roving Constant Contact 2009 (http://www.constantcontact.com) List-Unsubscribe: http://visitor.constantcontact.com/do?p=un&mse=001jyV49J2cwWqdjn8mMORKnpGylNDgUGSx&t=001yiFSOp6dDdFiYaWssbJCXQ%3D%3D&llr=stmdx6bab X-Return-Path-Hint: ESC1109583805414_1101582676594_2249_r20@in.constantcontact.com X-Roving-ID: 1101582676594.2249 X-Lumos-SenderID: 1101582676594 X-Roving-CampaignId: 1109583805414 X-Roving-StreamId: 0 X-Virus-Scanned: by bsmtpd at nps.navy.mil X-Barracuda-Connect: haven.nps.navy.mil[131.120.251.28] X-Barracuda-Start-Time: 1332353777 X-Barracuda-URL: http://morgan.nps.edu:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at nps.edu Return-Path: ESC1109583805414_1101582676594_2249_r20@in.constantcontact.com X-MS-Exchange-Organization-AuthSource: hercules.ern.nps.edu X-MS-Exchange-Organization-AuthAs: Anonymous MIME-Version: 1.0 ------=_Part_6980129_1823636651.1332353773935 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ National Public Safety Telecommunications Council ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ March 21, 2012 How Much Spectrum Does Public Safety Need to Fight a Large Wild Land Fire? In 2003, a large wild land fire called "The Old Fire," caused $42 million in damage and burned an area of more than 35 square miles while destroying 993 homes and causing six fatalities. Fanned by high winds and fueled by abundant dried vegetation, this incident grew quickly and taxed the ability of local emergency officials to manage evacuations and road closures ahead of the fast moving fire storm. At the incident peak, more than 1,000 vehicles were on scene providing fire fighting, security, and support functions. The Assessment of Future Spectrum and Technology Report [http://r20.rs6.net/tn.jsp?et=1109583805414&s=2249&e=001O9MH6yoZ9WdFYIsuMBT0Gfc53zW_n2snVES-ecUqQrL6S4BE8-2hLSQTMzFtAMs6I1lDRBaUi8wez6QF8SjDFHQ187W0CFUNs5dPNIBclWE-3XbRIN39m7luChB9s8z8sE0HZ3sVhVfTW3bLJVPlaWttsSMmn5IYK03hwOHBaxZIQPUtsTMzdERcjaPvKzxlVG67yeJtelGg66w_L209SC57AdpDvRE21WVVs2Dat0I=] issued by NPSTC for comment [http://r20.rs6.net/tn.jsp?et=1109583805414&s=2249&e=001O9MH6yoZ9WdgWuRuAUcShlRextLvmsP_IkAXIlAm04CRYTy1EMLIbOwZvUgn_GjlZ_FlWz0FVfN2_45GYhzDEY7n__aq-2GGumJNARq8a8W_9vAXEBJg5r_Mu4SnnmJG71J8AYnN3PvbYVZsmhcC6GHcHX5gBpYwZDN2qcOXNHtyaALDxt3JQVej66vqjp5mRht7rptbIKCDAFsfC2RQx3gCcvUVo-xuFjBhvlSEjSs=] on February 24 answers that question. The draft report identifies the spectrum and technology required until the year 2020 to meet public safety user requirements and to help drive policy on spectrum and funding; standards development; and the public safety vendor community. NPSTC gathered feedback on broadband applications and usage from public safety practitioners and technologists, through questionnaires and focus groups, to build the case for a desired future for public safety. These sessions brought together multidisciplinary teams to discuss tactics and strategies at the scene of a specific event. As each focus group discussed their response to the emergency event they also identified various data and video applications which would be needed to support their operations. In 1996, the Public Safety Wireless Advisory Committee (PSWAC) published its report on public safety's needs through the year 2010. That groundbreaking report eventually led to public safety spectrum assignments in the 700 MHz and 4.9 GHz bands. NPSTC created the PSWAC Followup: [http://r20.rs6.net/tn.jsp?et=1109583805414&s=2249&e=001O9MH6yoZ9Wca1yRkL-sfez7rsmSuvB1_dteh_fg20mKvHwqnZ_wKAf5CuHz_fF-jz7iTNeXgPbXir-Wts4NeHSeeG7iyDiWzj1LnUyUlypUYGOS1J07RXeTFFcHCFlQ1] Assessment of Future Spectrum and Technology (AFST) Working Group [http://r20.rs6.net/tn.jsp?et=1109583805414&s=2249&e=001O9MH6yoZ9Wca1yRkL-sfez7rsmSuvB1_dteh_fg20mKvHwqnZ_wKAf5CuHz_fF-jz7iTNeXgPbXir-Wts4NeHSeeG7iyDiWzj1LnUyUlypUYGOS1J07RXeTFFcHCFlQ1] to update the PSWAC Report to the year 2020. There is still time to contribute to this important report. Please take the time to review the draft report [http://r20.rs6.net/tn.jsp?et=1109583805414&s=2249&e=001O9MH6yoZ9WdFYIsuMBT0Gfc53zW_n2snVES-ecUqQrL6S4BE8-2hLSQTMzFtAMs6I1lDRBaUi8wez6QF8SjDFHQ187W0CFUNs5dPNIBclWE-3XbRIN39m7luChB9s8z8sE0HZ3sVhVfTW3bLJVPlaWttsSMmn5IYK03hwOHBaxZIQPUtsTMzdERcjaPvKzxlVG67yeJtelGg66w_L209SC57AdpDvRE21WVVs2Dat0I=] and provide feedback using the provided email form [http://r20.rs6.net/tn.jsp?et=1109583805414&s=2249&e=001O9MH6yoZ9WdgWuRuAUcShlRextLvmsP_IkAXIlAm04CRYTy1EMLIbOwZvUgn_GjlZ_FlWz0FVfN2_45GYhzDEY7n__aq-2GGumJNARq8a8W_9vAXEBJg5r_Mu4SnnmJG71J8AYnN3PvbYVZsmhcC6GHcHX5gBpYwZDN2qcOXNHtyaALDxt3JQVej66vqjp5mRht7rptbIKCDAFsfC2RQx3gCcvUVo-xuFjBhvlSEjSs=] . Send the completed form via email to AFSTInput@npstc.org [mailto:AFSTInput@npstc.org] by April 22, 2012. Thank you for your contributions to public safety. NPSTC is a federation of organizations whose mission is to improve public safety communications and interoperability through collaborative leadership. The member organizations of the National Public Safety Telecommunications Council are grateful to the Department of Homeland Security's Science and Technology Directorate, Office for Interoperability and Compatibility (OIC) and the National Protection and Programs Directorate, and Office of Emergency Communications (OEC) for their support to this volunteer public safety organization. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ American Association of State Highway and Transportation Officials | American Radio Relay League | Association of Fish and Wildlife Agencies | Association of Public Safety Communications Officials | Forestry Conservation Communications Association | International Association of Chiefs of Police | International Associate of Emergency Managers | International Association of Fire Chiefs | International Municipal Signal Association | National Association of State Chief Information Officers | National Association of State Emergency Medical Services Officials | National Association of State Foresters | National Association of State Technology Directors | National Sheriffs' Association | National Emergency Number Association ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Forward email http://ui.constantcontact.com/sa/fwtf.jsp?llr=stmdx6bab&m=1101582676594&ea=budden@nps.navy.mil&a=1109583805414 This email was sent to budden@nps.navy.mil by support@npstc.org. Update Profile/Email Address http://visitor.constantcontact.com/do?p=oo&mse=001jyV49J2cwWqdjn8mMORKnpGylNDgUGSx&t=001yiFSOp6dDdFiYaWssbJCXQ%3D%3D&llr=stmdx6bab Instant removal with SafeUnsubscribe(TM) http://visitor.constantcontact.com/do?p=un&mse=001jyV49J2cwWqdjn8mMORKnpGylNDgUGSx&t=001yiFSOp6dDdFiYaWssbJCXQ%3D%3D&llr=stmdx6bab Privacy Policy: http://ui.constantcontact.com/roving/CCPrivacyPolicy.jsp Online Marketing by Constant Contact(R) www.constantcontact.com National Public Safety Telecommunications Council | 8191 Southpark Lane | Unit 205 | Littleton | CO | 80120 ------=_Part_6980129_1823636651.1332353773935 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
=
3D"Logo 
=09
National Public Safety Telecommunications Council
3D"Red

March 21, = 2012 

  

How Much= Spectrum Does Public Safety Need to Fight a Large

Wild Lan= d Fire?

 = ;

In 2003, a large= wild land fire called "The Old Fire," caused $42 million in dama= ge and burned an area of more than 35 square miles while destroying 993 hom= es and causing six fatalities.   Fanned by high winds and fueled = by abundant dried vegetation, this incident grew quickly and taxed the abil= ity of local emergency officials to manage evacuations and road closures ah= ead of the fast moving fire storm.  At the incident peak, more than 1,= 000 vehicles were on scene providing fire fighting, security, and support f= unctions.

 

The Assessment of Future Spectrum and Techno= logy Report  issued by NPSTC for comment  on February 24 answers that= question. The draft report ide= ntifies the spectrum and technology required until the year 2020 to meet pu= blic safety user requirements and to help drive policy on spectrum and fund= ing; standards development; and the public safety vendor community. =

 

NPSTC gathered feedba= ck on broadband applications an= d usage from public safety prac= titioners and technologists, through questionnaires and focus groups, to bu= ild the case for a desired future for public safety.  3D"Focus

These sessions brought together mult= idisciplinary teams to discuss tactics and strategies at the s= cene of a specific event. As each focus group discussed their response to t= he emergency event they also identified various data and video applications= which would be needed to support their operations.  

 

In 1996, the Public Safety Wireless Advisory Committee (PSWAC) publishe= d its report on public safety's needs through the year 2010.  That gro= undbreaking report eventually led to public safety spectrum assignments in = the 700 MHz and 4.9 GHz bands.  NPSTC created the PSWAC Followup:  Assessment of Future S= pectrum and Technology (AFST) Working Group  to update the P= SWAC Report to the year 2020.


 There is still time to contribute to this importa= nt report. Please take the time to review the draft report=   and provide fe= edback using the provided email form .  Send the completed form via email t= o by April 22, 2012.  Thank you for your contribu= tions to public safety.

 

 

NPSTC is a federation of organizat= ions whose mission is to improve public safety communications and interoper= ability through collaborative leadership. <= /span>

  

The member organizations of the Na= tional Public Safety Telecommunications Council are grateful to the Departm= ent of Homeland Security's Science and Technology Directorate,  Office= for Interoperability and Compatibility (OIC) and the = National Protection and Programs Directorate, and Office of Emergency Communications (OEC) for the= ir support to this volunteer public safety organization.

 

 

 

 

 

 

 

=

=

American Association of State High= way and Transportation Officials | American Radio Relay League |  Asso= ciation of Fish and Wildlife Agencies | Association of Public Safety Commun= ications Officials | Forestry Conservation Communications Association | Int= ernational Association of Chiefs of Police | International Associate of Eme= rgency Managers | International Association of Fire Chiefs | International = Municipal Signal Association | National Association of State Chief Informat= ion Officers | National Association of State Emergency Medical Services Off= icials | National Association of State Foresters | National Association of = State Technology Directors | National Sheriffs' Association | National Emer= gency Number Association

3D"Red
 
=20 =20 =09
=20 =20 =20 =20
=20 =20
=09
This email was sent to budden@nps.navy.mil by support@npstc.org |  =
Update Profile/Email Address | = Instant removal with SafeUnsubscribe™ Privacy Pol= icy.
Natio= nal Public Safety Telecommunications Council | 8191 Southpark Lane | Uni= t 205 | Littleton | CO | 80120
------=_Part_6980129_1823636651.1332353773935-- --=-ER1aKCNMkaFUcS4Y+zWb-- From Basavaraj.Patil@nokia.com Wed Mar 21 12:39:14 2012 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 6A19521E80DF for ; Wed, 21 Mar 2012 12:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.133 X-Spam-Level: X-Spam-Status: No, score=-105.133 tagged_above=-999 required=5 tests=[AWL=1.466, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 fpn4+QEEQlEj for ; Wed, 21 Mar 2012 12:39:13 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 85A3F21E80DC for ; Wed, 21 Mar 2012 12:39:13 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2LJcp26024005; Wed, 21 Mar 2012 21:38:52 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Mar 2012 21:38:51 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.150]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0355.003; Wed, 21 Mar 2012 20:38:50 +0100 From: To: , , Thread-Topic: [paws] Time to present my ID in IETF Paris meeting Thread-Index: AQHNAXZBv5MHbxp/JUy4n8zz+YZtX5Zo/brwgAAPzzCAAALlAIAApEwAgAsYQIA= Date: Wed, 21 Mar 2012 19:38:50 +0000 Message-ID: In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716448C60@dfweml504-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.19.59.12] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Mar 2012 19:38:51.0559 (UTC) FILETIME=[3E52E370:01CD079A] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] Time to present my ID in IETF Paris 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: Wed, 21 Mar 2012 19:39:14 -0000 On 3/14/12 8:13 AM, "ext Peter McCann" wrote: >Besides, regardless of one's opinion on the coordinating database >concept, it is really just a minor part of this draft. The draft >goes into quite a bit of detail on an XML schema for device<->WSDB >communication. =20 Agree. My earlier comment about the relevance of the discussion (and why chairs should/may want to intervene) only pertained to the co-ordinating database aspect and not the whole I-D itself. Look forward to the discussion at the meeting. -Raj >I would hope it gets some agenda time in Paris. > >-Pete > From Gabor.Bajko@nokia.com Thu Mar 22 12:19:35 2012 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 4288321E801B for ; Thu, 22 Mar 2012 12:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.997 X-Spam-Level: X-Spam-Status: No, score=-4.997 tagged_above=-999 required=5 tests=[AWL=1.374, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 Ns4T4fpyTe5k for ; Thu, 22 Mar 2012 12:19:33 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 89DBE21E8020 for ; Thu, 22 Mar 2012 12:19:32 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2MJJNsM013452; Thu, 22 Mar 2012 21:19:23 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Mar 2012 21:19:23 +0200 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.157]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0355.003; Thu, 22 Mar 2012 20:19:22 +0100 From: To: , Thread-Topic: WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03 Thread-Index: Acz7CHkh/FNx3kOiQQWaHcNbcyzaWwArxp5AAyoYF1A= Date: Thu, 22 Mar 2012 19:19:22 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601E22BF6@008-AM1MPN1-006.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601E1A52E@008-AM1MPN1-006.mgdnok.nokia.com> <619CDADDCCD2B44380834BE8BF6F7141406914613F@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: <619CDADDCCD2B44380834BE8BF6F7141406914613F@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.21.95.63] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47601E22BF6008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 22 Mar 2012 19:19:23.0449 (UTC) FILETIME=[B07D3290:01CD0860] X-Nokia-AV: Clean Cc: johnny.dixon@bt.com Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03 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 Mar 2012 19:19:35 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601E22BF6008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The document was meant to be structured in a way that the list of parameter= s to be exchanged between the entities are described in the Data Model Requ= irements part, while the protocol operation requirements described in the P= rotocol Requirements part. P.11 and P.12 should not include any wording on = the list of parameters, then it would be no confusion. I'll include this comment into my chair's review. - Gabor From: ext andy.sago@bt.com [mailto:andy.sago@bt.com] Sent: Tuesday, March 06, 2012 9:45 AM To: paws@ietf.org; Bajko Gabor (Nokia-CIC/SiliconValley) Cc: johnny.dixon@bt.com; chris.cheeseman@bt.com Subject: RE: WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03 All I believe that the WG draft has an omission in P.11 relating to the paramet= ers that MAY be sent from the master device to the database. The data model= in D.1 allows for location uncertainty, height and height uncertainty. The= se items are not mentioned in the parameters in P.11, and all (except heigh= t uncertainty) are required by Ofcom in http://www.cept.org/Documents/se-43= /4161/SE43(12)Info03_Draft-UK-regulatory-requirements-for-white-space-devic= es-in-the-UHF-TV-band. I propose the following change: P.11: The protocol MUST support a channel query request from the master de= vice to the database. The channel query request message MUST include param= eters as required by local regulatory requirement. These parameters MAY in= clude device location, location uncertainty, device height, height = uncertainty, device ID, manufacturer's serial number, and antenna = characteristic information. Regards Andy From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Gabor.Baj= ko@nokia.com Sent: 05 March 2012 19:46 To: paws@ietf.org Subject: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03 The authors of the use cases and requirements draft have just posted a new = version of the draft and indicated that there are no unresolved comments/is= sues they are aware of. Therefore, I'd like to initiate a WG Last Call for comments on http://www.i= etf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rqmts-03.txt Please review the draft and send your comments to the list by March 20th, 2= 012. If you review the draft and have no comments, send a note to the list that = the draft is good as it is, we need these notes as much as we need the actu= al comments. Thanks, Gabor --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601E22BF6008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The document was meant= to be structured in a way that the list of parameters to be exchanged betw= een the entities are described in the Data Model Requirements part, while t= he protocol operation requirements described in the Protocol Requirements part. P.11 and P.12 should not include any wo= rding on the list of parameters, then it would be no confusion.<= /span>

I’ll include thi= s comment into my chair’s review.

 

-&nb= sp;         Gabor

 

From: ext andy= .sago@bt.com [mailto:andy.sago@bt.com]
Sent: Tuesday, March 06, 2012 9:45 AM
To: paws@ietf.org; Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: johnny.dixon@bt.com; chris.cheeseman@bt.com
Subject: RE: WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03=

 

All

 

I believe that the WG draft has an omission in P.11 relating to t= he parameters that MAY be sent from the master device to the database. The = data model in D.1 allows for location uncertainty, height and height uncertainty. These items are not mentioned = in the parameters in P.11, and all (except height uncertainty) are required= by Ofcom in http://www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-regulatory= -requirements-for-white-space-devices-in-the-UHF-TV-band. I propose the= following change:

 

P.11:  The protocol MUST support a channel query request fro= m the master device to the database.  The channel query request messag= e MUST include parameters as required by local regulatory requirement.  These parameters MAY include device location, <Inser= t>location uncertainty, device height, height uncertainty, </Insert&g= t;device ID, manufacturer's serial number, and antenna characteristic infor= mation.

 

Regards

 

Andy

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com
Sent: 05 March 2012 19:46
To: paws@ietf.org
Subject: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts= -03

 

The authors of the use cases and requirements dra= ft have just posted a new version of the draft and indicated that there are= no unresolved comments/issues they are aware of.

 

Therefore, I'd like t= o initiate a WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-r= qmts-03.txt

 

Please review the dra= ft and send your comments to the list by March 20th, 2012.

 

If you review the dra= ft and have no comments, send a note to the list that the draft is good as = it is, we need these notes as much as we need the actual comments.

 

Thanks, Gabor

 

--_000_1ECAFF543A2FED4EA2BEB6CACE08E47601E22BF6008AM1MPN1006mg_-- From Gabor.Bajko@nokia.com Thu Mar 22 14:46:00 2012 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 8806821F855F for ; Thu, 22 Mar 2012 14:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.112 X-Spam-Level: X-Spam-Status: No, score=-5.112 tagged_above=-999 required=5 tests=[AWL=1.260, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 FqJz35vYlJNa for ; Thu, 22 Mar 2012 14:46:00 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id D398521F855B for ; Thu, 22 Mar 2012 14:45:59 -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.4) with ESMTP id q2MLjolS032178 for ; Thu, 22 Mar 2012 23:45:55 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.21]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Mar 2012 23:45:53 +0200 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.157]) by 008-AM1MMR1-012.mgdnok.nokia.com ([65.54.30.21]) with mapi id 14.01.0355.003; Thu, 22 Mar 2012 22:45:53 +0100 From: To: Thread-Topic: Chair review of draft-ietf-paws-problem-stmt-usecases-rqmts-03 Thread-Index: Ac0Ia1hz/F8Eg2kgQq6//oVo3SDX7A== Date: Thu, 22 Mar 2012 21:45:52 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601E22C9C@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.21.95.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 22 Mar 2012 21:45:54.0024 (UTC) FILETIME=[28147E80:01CD0875] X-Nokia-AV: Clean Subject: [paws] Chair review of draft-ietf-paws-problem-stmt-usecases-rqmts-03 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 Mar 2012 21:46:00 -0000 Here's my chair review of the http://www.ietf.org/internet-drafts/draft-iet= f-paws-problem-stmt-usecases-rqmts-03.txt draft: In version 2 of the draft there was a use case about offloading, which disa= ppeared in this version. I believe that was a valid use case and see no rea= son for it to be deleted. I think it should be put back. Requirement D.1: s/for the location determination/of the location determination D.2, D.3: I believe the URIs should not be specified in the Data Model, but= rather discovered during the WSDB discovery procedure. Can you confirm the= se? If yes, then these requirements should be deleted. D.4: isn't the regulatory domain also discovered? The Data Model might also= list the regulatory domain, I see no harm in it, but then that is not a ma= ndatory requirement any more. D.10: I think channel availability should either be specified for a locatio= n or for an area, but not both. Change the requirement to: "The Data Model MUST support specifying channel availability information for a single location or for an area in the form o= f a geodetic-shape." P.2: Since P.1 requires database discovery, I see no need for this requirem= ent. P.6, P.7: s/MUST be integrity protected/MUST support integrity protection P.11, P.12: The Data Model already specifies what parameters need to be sup= ported, you do not need to replicate the text here. It looks like keeping t= he first sentence in these requirements is sufficient, the rest can be remo= ved. P.13, P.16: the interface between the slave and the master device is curren= tly out of scope, these requirements should be removed for now. P.17 is a radio interface functionality, not something ietf can specify, so= this should be removed too. P.18: s/lists/information P.19 is also captured earlier in D.10, no need to replicate it.=20 - Gabor From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Baj= ko Gabor (Nokia-CIC/SiliconValley) Sent: Monday, March 05, 2012 11:46 AM To: paws@ietf.org Subject: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03 The authors of the use cases and requirements draft have just posted a new = version of the draft and indicated that there are no unresolved comments/is= sues they are aware of. Therefore, I'd like to initiate a WG Last Call for comments on http://www.i= etf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rqmts-03.txt= =20 Please review the draft and send your comments to the list by March 20th, 2= 012. If you review the draft and have no comments, send a note to the list that = the draft is good as it is, we need these notes as much as we need the actu= al comments. Thanks, Gabor From Gabor.Bajko@nokia.com Sun Mar 25 05:37:31 2012 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 4CF1321F84A6 for ; Sun, 25 Mar 2012 05:37:31 -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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=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 JqHSI631Y-A5 for ; Sun, 25 Mar 2012 05:37:30 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 451B621F84A2 for ; Sun, 25 Mar 2012 05:37:30 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2PCbQSM022111 for ; Sun, 25 Mar 2012 15:37:26 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Mar 2012 15:37:25 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.157]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0355.003; Sun, 25 Mar 2012 14:37:25 +0200 From: To: Thread-Topic: remote participation Thread-Index: Ac0Kg4CVmRc7vOAqRvSpivPOXDL3vg== Date: Sun, 25 Mar 2012 12:37:24 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601E2327B@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.18.124] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47601E2327B008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 25 Mar 2012 12:37:25.0952 (UTC) FILETIME=[08947400:01CD0A84] X-Nokia-AV: Clean Subject: [paws] remote participation 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: Sun, 25 Mar 2012 12:37:31 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601E2327B008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For those of you who would like to remote participate to the Wednesday morn= ing paws session, based on our experience from last time, we are going to u= se skype for audio and meetecho for screen sharing and video. Please connect to ietf.paws skype id before the meeting, then go to http://= www.meetecho.com/ietf83/paws for the screen sharing and video. - Gabor --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601E2327B008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For those of you who would like to remote participat= e to the Wednesday morning paws session, based on our experience from last = time, we are going to use skype for audio and meetecho for screen sharing a= nd video.

 

Please connect to ietf.paws skype id before the meet= ing, then go to http://www.meetecho.com/iet= f83/paws

for the screen sharing and video.

 

-     &= nbsp;    Gabor

--_000_1ECAFF543A2FED4EA2BEB6CACE08E47601E2327B008AM1MPN1006mg_-- From scott.probasco@nokia.com Mon Mar 26 14:32:54 2012 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 E7C9921F8518 for ; Mon, 26 Mar 2012 14:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.764 X-Spam-Level: X-Spam-Status: No, score=-4.764 tagged_above=-999 required=5 tests=[AWL=1.608, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 zP2N6YQH8dJo for ; Mon, 26 Mar 2012 14:32:52 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 4E69F21F8513 for ; Mon, 26 Mar 2012 14:32:49 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2QLWi3u030286 for ; Tue, 27 Mar 2012 00:32:45 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Mar 2012 00:32:44 +0300 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.129]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.01.0355.003; Mon, 26 Mar 2012 23:32:44 +0200 From: To: Thread-Topic: [paws] Chair review of draft-ietf-paws-problem-stmt-usecases-rqmts-03 Thread-Index: AQHNC5f6QEzxQr/OH0uok7MA7F4kVA== Date: Mon, 26 Mar 2012 21:32:43 +0000 Message-ID: In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601E22C9C@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.0.0.100825 x-originating-ip: [10.184.18.24] Content-Type: text/plain; charset="us-ascii" Content-ID: <10F076C79F8C8540B69B5163F97AC1FE@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Mar 2012 21:32:45.0014 (UTC) FILETIME=[FB721F60:01CD0B97] X-Nokia-AV: Clean Subject: Re: [paws] Chair review of draft-ietf-paws-problem-stmt-usecases-rqmts-03 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, 26 Mar 2012 21:32:54 -0000 Hi Gabor, Comments below: Scott-> Kind Regards, Scott On 3/22/12 4:45 PM, "ext Gabor.Bajko@nokia.com" wrote: >Here's my chair review of the >http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases- >rqmts-03.txt draft: > > >In version 2 of the draft there was a use case about offloading, which >disappeared in this version. I believe that was a valid use case and see >no reason for it to be deleted. I think it should be put back. > >Requirement D.1: >s/for the location determination/of the location determination > >D.2, D.3: I believe the URIs should not be specified in the Data Model, >but rather discovered during the WSDB discovery procedure. Can you >confirm these? If yes, then these requirements should be deleted. Scott->If the discovery procedure "uses" the Data Model, then D.2 & D.3 should remain. If the discovery procedure operates independently of the Data Model, then these should be deleted. I.E. The intent was that at some point the URIs will be transported as data via PAWS (discovery procedure) and thus should be in the Data Model. Perhaps there is a separate Data Model (e.g. Schema) for discovery and a separate Data Model for the other aspects of PAWS. IMHO this is not a requirements issue (beyond the discussions already mentioned by John), but an issue to be determined in the specification of the protocol solution. > >D.4: isn't the regulatory domain also discovered? The Data Model might >also list the regulatory domain, I see no harm in it, but then that is >not a mandatory requirement any more. Scott->If PAWS supports more than one regulatory domain (e.g. UK Ofcom and US FCC), then knowledge of the regulatory domain is a MUST requirement. Else how to know which information elements to include to the signals? > >D.10: I think channel availability should either be specified for a >location or for an area, but not both. Change the requirement to: >"The Data Model MUST support specifying channel availability > information for a single location or for an area in the form >of a geodetic-shape." Scott->I believe the protocol signaling can support channel request for a single location (point) or an area (geodetic shape) -- I.E. No reason to ask for and receive both at the same time. But the Data Model must support both points & shapes so that fixed location and mobility may be supported in the protocol. > >P.2: Since P.1 requires database discovery, I see no need for this >requirement. Scott->P.1 is about finding a database to use. P.2 is about accessing the database directly (as allowed by FCC) or accessing the database through a listing service (as allowed by Ofcom). > >P.6, P.7: s/MUST be integrity protected/MUST support integrity protection > >P.11, P.12: The Data Model already specifies what parameters need to be >supported, you do not need to replicate the text here. It looks like >keeping the first sentence in these requirements is sufficient, the rest >can be removed. Scott->Keeping only the first sentence removes the MUST and MAY qualifiers which are not specified anywhere in the Data Model. > >P.13, P.16: the interface between the slave and the master device is >currently out of scope, these requirements should be removed for now. > >P.17 is a radio interface functionality, not something ietf can specify, >so this should be removed too. > >P.18: s/lists/information > >P.19 is also captured earlier in D.10, no need to replicate it. Scott->D.10 only describes storage, i.e. two types of variables. P.19 describes when to use the variables. >=20 > >- Gabor > > >From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >Bajko Gabor (Nokia-CIC/SiliconValley) >Sent: Monday, March 05, 2012 11:46 AM >To: paws@ietf.org >Subject: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03 > >The authors of the use cases and requirements draft have just posted a >new version of the draft and indicated that there are no unresolved >comments/issues they are aware of. > >Therefore, I'd like to initiate a WG Last Call for comments on >http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases- >rqmts-03.txt=20 > >Please review the draft and send your comments to the list by March 20th, >2012. > >If you review the draft and have no comments, send a note to the list >that the draft is good as it is, we need these notes as much as we need >the actual comments. > >Thanks, Gabor > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From ietf@meetecho.com Tue Mar 27 07:38:30 2012 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 25CF521F8736 for ; Tue, 27 Mar 2012 07:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.964 X-Spam-Level: X-Spam-Status: No, score=-0.964 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 PXSQGsYNs75k for ; Tue, 27 Mar 2012 07:38:29 -0700 (PDT) Received: from smtplq04.aruba.it (smtplqs-out26.aruba.it [62.149.158.66]) by ietfa.amsl.com (Postfix) with SMTP id F325421F8512 for ; Tue, 27 Mar 2012 07:38:28 -0700 (PDT) Received: (qmail 28853 invoked by uid 89); 27 Mar 2012 14:38:25 -0000 Received: from unknown (HELO smtp4.aruba.it) (62.149.158.224) by smtplq04.aruba.it with SMTP; 27 Mar 2012 14:38:25 -0000 Received: (qmail 20413 invoked by uid 89); 27 Mar 2012 14:38:25 -0000 Received: from unknown (HELO ?130.129.21.177?) (ietf@meetecho.com@130.129.21.177) by smtp4.ad.aruba.it with SMTP; 27 Mar 2012 14:38:25 -0000 Message-ID: <4F71D0DF.2050902@meetecho.com> Date: Tue, 27 Mar 2012 16:38:23 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: paws@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp4.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq04.aruba.it 1.6.2 0/1000/N Cc: Team Meetecho Subject: [paws] Meetecho support for PAWS WG meeting session X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 14:38:30 -0000 Hi all, a virtual room has been reserved on the Meetecho system for Tuesday's PAWS BOF session. Access to the on-line session (including audio and video streams) will be available at: http://www.meetecho.com/ietf83/paws The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. Remote participants might also send their own voice to the room, if they want to, by either calling a landline phone number, or using our embedded VoIP applet (in this last case they are *strongly* advised to use a headset). A tutorial of interactivity features of the tool can be found at: http://www.meetecho.com/ietf83/tutorials Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From ietf@meetecho.com Tue Mar 27 07:41:39 2012 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 A0CCC21E81CE for ; Tue, 27 Mar 2012 07:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.945 X-Spam-Level: X-Spam-Status: No, score=-0.945 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 EygrFvq1ZQi2 for ; Tue, 27 Mar 2012 07:41:39 -0700 (PDT) Received: from smtplq01.aruba.it (smtplqs-out27.aruba.it [62.149.158.67]) by ietfa.amsl.com (Postfix) with SMTP id 59D4D21E81CD for ; Tue, 27 Mar 2012 07:41:37 -0700 (PDT) Received: (qmail 10974 invoked by uid 89); 27 Mar 2012 14:41:31 -0000 Received: from unknown (HELO smtp8.aruba.it) (62.149.158.228) by smtplq01.aruba.it with SMTP; 27 Mar 2012 14:41:31 -0000 Received: (qmail 17717 invoked by uid 89); 27 Mar 2012 14:41:31 -0000 Received: from unknown (HELO ?130.129.21.177?) (ietf@meetecho.com@130.129.21.177) by smtp8.ad.aruba.it with SMTP; 27 Mar 2012 14:41:31 -0000 Message-ID: <4F71D199.7020504@meetecho.com> Date: Tue, 27 Mar 2012 16:41:29 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: paws@ietf.org References: <4F71D0DF.2050902@meetecho.com> In-Reply-To: <4F71D0DF.2050902@meetecho.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp8.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq01.aruba.it 1.6.2 0/1000/N Subject: Re: [paws] Meetecho support for PAWS WG meeting session X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 14:41:39 -0000 Of course we meant *Wednesday's* PAWS *WG* session... Sorry for the cut/paste error! The Meetecho team Il 27/03/2012 16:38, Meetecho IETF support ha scritto: > Hi all, > > a virtual room has been reserved on the Meetecho system for Tuesday's > PAWS BOF session. > > Access to the on-line session (including audio and video streams) will > be available at: > http://www.meetecho.com/ietf83/paws > > The Meetecho session automatically logs you into the standard IETF > jabber room. So, from there, you can have an integrated experience > involving all media and allowing you to interact with the room. > Remote participants might also send their own voice to the room, if they > want to, by either calling a landline phone number, or using our > embedded VoIP applet (in this last case they are *strongly* advised to > use a headset). > > A tutorial of interactivity features of the tool can be found at: > http://www.meetecho.com/ietf83/tutorials > > Cheers, > the Meetecho team > From ietf@meetecho.com Thu Mar 29 02:17:10 2012 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 B84F921F85A2 for ; Thu, 29 Mar 2012 02:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.929 X-Spam-Level: X-Spam-Status: No, score=-0.929 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 YKK-Zv59cZaI for ; Thu, 29 Mar 2012 02:17:09 -0700 (PDT) Received: from smtplq02.aruba.it (smtplqs-out28.aruba.it [62.149.158.68]) by ietfa.amsl.com (Postfix) with SMTP id 9435521F8A30 for ; Thu, 29 Mar 2012 02:16:58 -0700 (PDT) Received: (qmail 32367 invoked by uid 89); 29 Mar 2012 09:16:43 -0000 Received: from unknown (HELO smtp7.aruba.it) (62.149.158.227) by smtplq02.aruba.it with SMTP; 29 Mar 2012 09:16:43 -0000 Received: (qmail 13732 invoked by uid 89); 29 Mar 2012 09:16:43 -0000 Received: from unknown (HELO ?130.129.21.177?) (alex@meetecho.com@130.129.21.177) by smtp7.ad.aruba.it with ESMTPA; 29 Mar 2012 09:16:43 -0000 Message-ID: <4F742875.2030405@meetecho.com> Date: Thu, 29 Mar 2012 11:16:37 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: paws@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtplq02.aruba.it 1.6.2 0/1000/N Cc: Team Meetecho Subject: [paws] Meetecho session recording available 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, 29 Mar 2012 09:17:11 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of PAWS session at IETF-83 is available. You can watch it by either clicking the proper link on the remote participation page (http://www.ietf.org/meeting/83/remote-participation.html#Meetecho), or by directly accessing the following URL: http://ietf83.conf.meetecho.com/index.php/Recorded_Sessions#PAWS_IETF83 For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to team@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com