idnits 2.17.00 (12 Aug 2021) /tmp/idnits1082/draft-zuniga-paws-uk-use-cases-and-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 16, 2011) is 3863 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 90, but not defined == Outdated reference: draft-ietf-paws-problem-stmt-usecases-rqmts has been published as RFC 6953 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PAWS Working Group JC. Zuniga 3 Internet-Draft InterDigital Communications, LLC 4 Intended status: Informational A. Sago 5 Expires: April 18, 2012 M. Fitch 6 BT 7 October 16, 2011 9 UK Use Cases and Requirements 10 draft-zuniga-paws-uk-use-cases-and-requirements-00 12 Abstract 14 This document proposes a simplification of the PAWS database 15 discovery use case, two new use cases for indoor networking and 16 machine to machine communications, and a set of requirements that 17 drop out of all the use cases included so far in the working 18 document. These use cases and requirements especially address the TV 19 White Spaces needs in the United Kingdom, as currently known. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 18, 2012. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Conventions and Terminology . . . . . . . . . . . . . . . . . . 3 57 2.1. Conventions Used in This Document . . . . . . . . . . . . . 3 58 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Use-Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3.1. TVWS Database Discovery (proposed modifications to WG 61 document) . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.2. Indoor Networking . . . . . . . . . . . . . . . . . . . . . 4 63 3.3. Machine to Machine (M2M) . . . . . . . . . . . . . . . . . 5 64 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.1. Master . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.2. Database . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 4.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 70 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 71 8. Informative References . . . . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 This docuement proposes some modifications to the TV White Spaces use 77 cases and requirements described in 78 [I-D.ietf-paws-problem-stmt-usecases-rqmts]. Similarly, some 79 additional ones are presented. These use cases and requirements are 80 meant to address especifically the regulatory needs of the UK, as 81 currently known. 83 2. Conventions and Terminology 85 2.1. Conventions Used in This Document 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119 [RFC2119]. 91 2.2. Terminology 93 Model ID 94 A unique number for each master device and slave device that 95 identifies the manufacturer, model number and serial number. 97 3. Use-Cases 99 3.1. TVWS Database Discovery (proposed modifications to WG document) 101 This use case is preliminary to creating a radio network using TV 102 white space; it is a prerequisite to other use cases. The radio 103 network is created by a master device. Before the master device can 104 transmit in TV white space spectrum, it must contact a trusted 105 database where the device can learn which channels are available for 106 it to use. The master device will need to discover a trusted 107 database in the relevant regulatory environment, using the following 108 steps: 109 1. The master device is connected to the internet by any means other 110 than using the TV white space radio. 111 2. The master device constructs and sends a service request over the 112 Internet to discover availability of trusted databases in the 113 local domain and waits for responses. 114 3. If no acceptable response is received within a pre-configured 115 time limit, the master device concludes that no trusted database 116 is available. If at least one response is received, the master 117 device evaluates the response(s) to determine if a trusted 118 database can be identified where the device is able to register 119 and receive service from the database. 121 Optionally the initial query will be made to a listing approved by 122 the national regulator for the domain of operation (e.g. a website 123 either hosted by or under control of the national regulator) which 124 maintains a list of TVWS databases and their internet addresses. The 125 query results in the list of databases and their internet addresses 126 being sent to the master, which then evaluates the response to 127 determine if a trusted database can be identified where the master 128 device is able to register and receive service from the database. 130 3.2. Indoor Networking 132 In this use case, the users are inside a house or office. The users 133 want to have connectivity to the internet or to equipment in the same 134 or other houses / offices. This deployment scenario is typically 135 characterized by master devices within buildings, that are connected 136 to the Internet using a method that does not utilise TV whitespace. 137 The master devices can establish TV whitespace links between 138 themselves, or between themselves and one or more user devices. 139 Figure 1 is an illustration of the arrangement. 141 \|/ 142 | 143 +-------+ | 144 |TVWS |\ +-|---------+ 145 |Usr Dev| WS AirIF \ | TVWS |\ 146 +-------+ X|Master Dev | \ 147 / +-----------+ \ 148 +-------+ WS AirIF | \ +----------+ 149 |TVWS |/ | \ (----) | Database | 150 |Usr Dev| | \ ( ) /----------+ 151 +-------+ WS AirIF \ / \ 152 | X( Internet ) 153 | / \ / 154 +-------+ \|/ | / ( ) 155 |TVWS |\ | | / (----) 156 |Usr Dev| WS AirIF | | / 157 +-------+ \ +-|---------+ / 158 \ | TVWS | / 159 |Master Dev |/ 160 +-----------+ 162 Figure 1: Example illustration of indoor TV Whitespace use-case 164 A simplified operational scenario utilizing TV whitespace to provide 165 indoor networking consists of the following steps: 167 1. The master device powers up with its whitespace radio in idle or 168 listen mode only (no active transmission on the whitespace 169 frequency band). 170 2. The master device has internet connectivity and establishes a 171 connection to a trusted white space database (see Section 3.1 172 above). 173 3. The master device sends its geolocation and location uncertainty 174 information, and optionally additional information which may 175 include (1) device ID and (2) antenna characteristics, to a 176 trusted database, requesting a list of available whitespace 177 channels based upon this information. 178 4. The database responds with a list of available white space 179 channels that the master device may use, and optional information 180 which may include inter alia (1) a duration of time for the use 181 of each channel (channel validity time) (2) a maximum radiated 182 power for each channel, (3) an indication of the quality of the 183 spectrum for each channel and (4) directivity and other antenna 184 information. 185 5. Once the master device authenticates the whitespace channel list 186 response message from the database, the master device selects one 187 or more available whitespace channels from the list. 188 6. The user device(s) scan(s) the TV white space bands to locate the 189 master device transmissions, and associates with the master. 190 7. The master device acknowledges to the database which of the 191 available whitespace channels it has selected for its operation, 192 and optionally other information, such as maximum transmit power 193 and antenna characteristics. The database is updated with the 194 information provided by the master device, in order to inform the 195 channel quality information provided to other masters in 196 subsequent requests. 198 3.3. Machine to Machine (M2M) 200 In this use case, machines include a whitespace device and can be 201 located anywhere, fixed or on the move. The machines want to have 202 connectivity to the internet or to other machines in the vicinity. 203 All machines are slave devices, and machine communication over a TVWS 204 channel, whether to a master device or to another machine, is under 205 the control of the master device. This deployment scenario is 206 typically characterized by a master device with internet connectivity 207 by some connection that does not utilize TV white space. Figure 2 is 208 an illustration of the arrangement. 210 \|/ 211 | 212 | 213 +-|---------+ 214 | TVWS |\ 215 /|Master Dev | \ 216 / +-----------+ \ 217 WS AirIF \ +----------+ 218 +-------+ / \ (----) | Database | 219 |Machine| \ ( ) /----------+ 220 +-------+ \ / \ 221 | X( Internet ) 222 WS AirIF \ / 223 | ( ) 224 +-------+ (----) 225 |Machine| 226 +-------+ \ +-------+ 227 WS AirIF-- |Machine| 228 +-------+ 230 Figure 2: Example illustration of M2M TV Whitespace use-case 232 A simplified operational scenario utilizing TV white space to provide 233 indoor networking consists of the following steps: 234 1. The master device powers up with its whitespace radio in idle or 235 listen mode only (no active transmission on the whitespace 236 frequency band). 237 2. The master device has internet connectivity and establishes a 238 connection to a trusted white space database (see Section 3.1 239 above). 240 3. The master device sends its geolocation and location uncertainty 241 information, and optionally additional information which may 242 include (1) device ID and (2) antenna characteristics, to a 243 trusted database, requesting a list of available whitespace 244 channels based upon this information. 245 4. The database responds with a list of available white space 246 channels that the master device may use, and optional information 247 which may include inter alia (1) a duration of time for the use 248 of each channel (channel validity time) (2) a maximum radiated 249 power for each channel, (3) an indication of the quality of the 250 spectrum for each channel and (4) directivity and other antenna 251 information. 252 5. Once the master device authenticates the whitespace channel list 253 response message from the database, the master device selects one 254 or more available whitespace channels from the list. 256 6. The devices fitted to the machines scan the TV bands to locate 257 the master transmissions, and associate with the master device. 258 Further signalling can then take place to establish direct links 259 among those machines that have associated with the master device. 260 7. The master device acknowledges to the database which of the 261 available whitespace channels it has selected for its operation, 262 and optionally other information, such as channel resource 263 information (e.g. duty cycle), maximum radiated power and antenna 264 characteristics. The database is updated with the information 265 provided by the master device, in order to inform the channel 266 quality information provided to other masters in subsequent 267 requests. 269 4. Requirements 271 4.1. Master 273 1. A master device MUST include a mechanism to locate a trusted 274 whitespace database. 275 2. A master device MAY register with a trusted white space 276 database. 277 3. A master device MUST be able to determine its location using 278 latitude-longitude coordinates. 279 4. A master device MUST determine its location with at least +/- x 280 meters accuracy, where the value of x is defined by the 281 regulator for each regulatory domain and is well known. 282 5. A master device MUST place its location into the query it makes 283 to the whitespace database. 284 6. A master device MUST be able to query the whitespace database 285 for channel availability information for a specific expected 286 coverage area around its current location. 287 7. A master device MUST be able to pass the accuracy of its 288 determined location in the query it makes to the whitespace 289 database. 290 8. A master device MAY send additional information in the query it 291 makes to the database such as antenna height above ground level, 292 device ID or antenna characteristics. 293 9. A master device MUST make a fresh query of the whitespace 294 database for the available channels within a particular time 295 interval, using a parameter sent by the database in response to 296 the previous query. On expiry of the time interval then a 297 master device MUST cease transmission in the TVWS band if no 298 successful query attempt has been made or a query has been made 299 but the database has not responded. 300 10. If slave devices change their location during operation, the 301 master device MUST query the whitespace database for available 302 operating channels each time a slave device moves outside the 303 reported coverage location area. 304 11. Before transmitting in the TVWS band, a master device MAY send 305 back to the whitespace database the start and stop frequencies 306 it has chosen for operation and MAY send back additional 307 optional information such as actual radiated power, antenna 308 characteristics or channel resource information. 309 12. A master device MAY be able to indicate to slave devices the 310 start and stop frequencies it has available for operation and 311 the maximum permitted powers for the slave devices, and MAY be 312 able to send additional optional information. 314 4.2. Database 316 1. The whitespace database MUST provide the available channel list 317 on receipt of a query from a master device as start and stop 318 frequencies for each channel. 319 2. The whitespace database MAY also provide allowable power limits 320 for each channel. 321 3. The whitespace database MAY also provide time validity 322 constraints for each channel. 323 4. The whitespace database MAY also provide other parameters to the 324 master device. 325 5. The whitespace database MAY be able to accept optional messaging 326 sent back from master devices indicating the start and stop 327 frequencies the master device has chosen for operation and MAY be 328 able to accept additional information such as actual radiated 329 power, antenna characteristics or channel resource information. 331 4.3. Security 333 1. The protocol between the master device and the WS Database MUST 334 support mutual authentication and authorization. 335 2. The protocol between the master device and the WS Database MUST 336 support integrity and confidentiality protection. 337 3. The WS Database MUST support both username/password and digital 338 certificates based authentication of the master device. 339 4. A master device MUST be capable of validating the digital 340 certificate of the WS Database. 341 5. A master device MUST be capable of checking the validity of the 342 WS Database certificate and whether it has been revoked or not. 344 5. Security Considerations 346 The messaging interface between the white space device and the 347 database needs to be secured. Security requirements are listed in 348 Section 4.3. 350 6. IANA Considerations 352 This document has no requests to IANA. 354 7. Acknowledgements 356 The authors would like to acknowledge Martino Freda for all the 357 fruitful discussions on this topic. 359 8. Informative References 361 [I-D.ietf-paws-problem-stmt-usecases-rqmts] 362 Probasco, S., Bajko, G., Patil, B., and B. Rosen, 363 "Protocol to Access White Space database: PS, use cases 364 and rqmts", draft-ietf-paws-problem-stmt-usecases-rqmts-00 365 (work in progress), September 2011. 367 Authors' Addresses 369 Juan Carlos Zuniga 370 InterDigital Communications, LLC 371 Montreal, Quebec 372 Canada 374 Email: juancarlos.zuniga@interdigital.com 376 Andy Sago 377 BT 378 Martlesham Heath, Suffolk 379 United Kingdom 381 Email: andy.sago@bt.com 383 Michael Fitch 384 BT 385 Martlesham Heath, Suffolk 386 United Kingdom 388 Email: michael.fitch@bt.com