Individual Submission S. Probasco, Ed. Internet-Draft G. Bajko Intended status: Informational B. Patil Expires: January 13, 2012 Nokia July 12, 2011 Protocol to Access White Space database: Use cases and requirements draft-probasco-paws-overview-usecases-01 Abstract Wireless spectrum is a commodity that is regulated by governments. The spectrum is used for various purposes which include entertainment (eg. radio and television), communication (telephony and Internet access), military (radars etc.) and, navigation (satellite communication, GPS). Portions of the radio spectrum that are unused or unoccupied at specific locations and times are defined as "white space". TV White space refers to those unused channels, within the range allocated for TV transmission, that can be used without interfering with the primary purpose for which it is allocated. This document describes examples of how a radio system might operate using TV white space spectrum and associated requirements. Not only does it describe the operation of a radio system, but also how the radio system including a white space database enables additional services. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 13, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the Probasco, et al. Expires January 13, 2012 [Page 1] Internet-Draft PAWS: Use Cases July 2011 document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2.1. Conventions Used in This Document . . . . . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. TVWS database discovery . . . . . . . . . . . . . . . . . 5 3.2. Hot-Spot: urban internet connectivity service . . . . . . 5 3.3. Wide-Area or Rural internet broadband access . . . . . . . 7 3.4. Offloading: moving traffic to a white space network . . . 9 3.5. TVWS for backhaul . . . . . . . . . . . . . . . . . . . . 11 3.6. Location based service usage scenario . . . . . . . . . . 12 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1. Master . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. Database . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Probasco, et al. Expires January 13, 2012 [Page 2] Internet-Draft PAWS: Use Cases July 2011 1. Introduction Wireless spectrum is a commodity that is regulated by governments. The spectrum is used for various purposes which include entertainment (eg. radio and television), communication (telephony and Internet access), military (radars etc.) and, navigation (satellite communication, GPS). Additionally spectrum is allocated for use either on a license basis or for unlicensed use. Television transmission until now has primarily been analog. The switch to digital transmission has begun. As a result the spectrum allocated for television transmission can now be more effectively used. Unused channels and bands between channels can be used as long as they do not interfere with the primary service for which that channel is allocated. While urban areas tend to have dense usage of spectrum and a number of TV channels, the same is not true in rural and semi- urban areas. There can be a number of unused TV channels in such areas that can be used for other services. The figure below shows TV white space within the lower UHF band: Avg | usage| |-------------- White Space | | | | | | 0.6| || || V V || | || ||| | || 0.4| || |||| | || | || |||| | ||<----TV transmission 0.2| || |||| | || |---------------------------------------- 400 500 600 700 800 Frequency in MHz -> Figure 1: High level view of TV White Space Regulatory entities in several countries including the US, Canada, UK, Finland to name a few are specifying the regulations for the use of TV white space. The availability of TV white space opens up the potential for its use for various purposes. Regulation may mandate its use for certain specific applications or services. This document describes an example of how a radio system might operate using TV white space spectrum. Not only does it describe the operation of a radio system for providing Internet access at a hot spot or in a rural area, but also how the radio system including a white space database enables location based services. The description is high level and generic, it is not meant to be specific Probasco, et al. Expires January 13, 2012 [Page 3] Internet-Draft PAWS: Use Cases July 2011 to any particular radio technology. 2. Conventions and Terminology 2.1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2.2. Terminology The Terminology Section of the latest version of draft-patil-paws-problem-stmt [PAWS-PS] shall be included by reference. Location Based Service An application or device which provides data, information or service to a user based on their location. Master Device A device which queries the WS Database to find out the available operating channels. Slave Device A device which uses the spectrum made available by a master device. 3. Use cases There are many potential use cases that could be considered for the TV white space spectrum. Providing broadband internet access in hot spots, rural and underserved areas are examples. Available channels may also be used to provide internet 'backhaul' for traditional Wi-Fi hot spots, or by towns and cities to monitor/control traffic lights or read utility meters. Still other use cases include the ability to offload data traffic from another internet access network (e.g. 3G cellular network) or to deliver location based services. Some of these use cases are described in the following sections. Probasco, et al. Expires January 13, 2012 [Page 4] Internet-Draft PAWS: Use Cases July 2011 3.1. TVWS database discovery This use case is preliminary to creating a radio network using TV white space; it is a prerequisite to other use cases. The radio network is created by a master device which can be an access point that establishes Hot Spot coverage, a base station that establish cellular coverage, or a device that establishes a peer-to-peer or ad- hoc network. Before the master device can trasmit in TV white space spectrum, it must contact a trusted database where the device can learn if any channels are available for it to use. In the simplest case the radio device is pre-programmed with the internet address of at least one trusted database. The device can establish contact with a trusted database using one of the pre- programmed internet addresses and establish a TV white space network (as described in one of the following use cases). If the radio device (master) does not have a pre-programmed address for a trusted white space database, or if the trusted database at the pre-programmed address is not responsive, or perhaps the trusted database does not provide service for the radio device's current location, or at the user's choice, the device may attempt to "discover" a trusted database which provides service at the current location. 1. The master is connected to the internet by any means other than using the TV white space radio. 2. The master constructs and broadcasts a query message over the internet and waits for responses. 3. If no acceptable response is received within a pre-configured time limit, the device concludes that no trusted database is available. If one or more response is received, the device evaluates the response to determine if a trusted database can be identified where the device is able to register and receive service from the database. 3.2. Hot-Spot: urban internet connectivity service In this use case internet connectivity service is provided in a "hot spot" to local users. Typical deployment scenarios include urban areas where internet connectivity is provided to local businesses and residents, and campus environments where internet connectivity is provided to local buildings and relatively small outdoor areas. This deployment scenario is typically characterized by multiple masters (APs or hot spots) in close proximity, with low antenna height, cells with relatively small radius (a few kilometers or less), and limited Probasco, et al. Expires January 13, 2012 [Page 5] Internet-Draft PAWS: Use Cases July 2011 numbers of available radio channels. Many of the masters/APs are assumed to be individually deployed and operated, i.e. there is no coordination between many of the masters/APs. The masters/APs in this scenario use a TDD radio technology and transmit at or below a relatively low transmit power threshold. Each master/AP has a connection to the internet and provides internet connectivity to multiple end user or slave devices. The figure below shows an example deployment of this scenario. ------- |Slave|\ \|/ ---------- |Dev 1| (TDD AirIF) | |Database| ------- \ | .---. /--------- o \ |-|---------| ( ) / o | Master | / \ o / | |========( Internet ) o / |-----------| \ / ------- (TDD AirIF) ( ) |Slave| / (----) |Dev n| ------- Figure 2: Hot-spot service using TV white space spectrum Once a master/AP has been correctly installed and configured, a simplified power up and operation scenario utilizing TV White Space to provide Internet connectivity service consists of the following steps: 1. The master/AP powers up; however its WS radio and all other WS capable devices will power up in idle/listen only mode (no active transmissions on the WS frequency band). 2. The master/AP has Internet connectivity and establishes a connection to a trusted white space database (see use case "TVWS database discovery" above). 3. The master/AP registers its geolocation, address, contact information, etc. associated with the owner/operator of the master/AP with the trusted database administrator (if not currently registered). Depending upon local regulator policy, the DB administrator may be required to store and forward the registration information to the regulatory authority. Probasco, et al. Expires January 13, 2012 [Page 6] Internet-Draft PAWS: Use Cases July 2011 4. Following the registration process, the master/AP will send a query to the trusted database requesting a list of available WS channels based upon its geolocation. 5. If the master/AP has been previously authenticated, the database responds with a list of available white space channels that the master may use, and optionally a duration of time for their use. 6. Once the master/AP authenticates the WS channel list response message from the database, the AP selects an available WS channel(s) from the list. 7. The master/AP acknowledges to the database which of the available WS channels it has selected for its operation. The database is updated with the information provided by the master/AP. 8. The slave or user device scans the TV bands to locate a master/AP transmission, and associates with the AP. The slave/user device queries the master for a channel list, based on the slaves' geolocation. 9. The master provides the list of channels locally available to the slave/user device. If the channel that the user terminal is currently using is not included in the list of locally available channels, the slave/user device ceases all operation on its current channel. The slave/user device may scan for another AP transmission on a different channel. 3.3. Wide-Area or Rural internet broadband access In this use case internet broadband access is provided as a Wide-Area Network (WAN) or Wireless Regional Area Netwowk (WRAN). A typical deployment scenario is a wide area or rural area, where internet broadband access is provided to local businesses and residents from a master (i.e. BS) connected to the internet. This deployment scenario is typically characterized by one or more fixed master(s)/ BS(s), cells with relatively large radius (tens kilometers up to 100 km), and many available radio channels. Many of the masters/BSs are assumed to be deployed and operated by a single entity, i.e. there is coordination between many of the masters/BSs. The BS in this scenario use a TDD radio technology and transmit at or below a transmit power threshold established by the local regulator. Each base station has a connection to the internet and provides internet connectivity to multiple slave/end-user devices. End user terminals or devices may be fixed or portable. The figure below shows an example deployment of this scenario. Probasco, et al. Expires January 13, 2012 [Page 7] Internet-Draft PAWS: Use Cases July 2011 ------- |Slave|\ \|/ ---------- |Dev 1| (TDD AirIF) | |Database| ------- \ | .---. /---------- o \ |-|---------| ( ) / o | Master | / \ o / | (BS) |========( Internet ) o / |-----------| \ / ------- (TDD AirIF) ( ) |Slave| / (----) |Dev n| ------- Figure 3: Rural internet broadband access using TV white space spectrum Once the master/BS has been professionally installed and configured, a simplified power up and operation scenario utilizing TV White Space to provide rural internet broadband access consists of the following steps: 1. The master/BS powers up; however its WS radio and all other WS capable devices will power up in idle/listen only mode (No active transmissions on the WS frequency band) 2. The master/BS has internet connectivity and establishes a connection to a trusted white space database (see use case "TVWS database discovery" above). 3. The master/BS registers its geolocation, address, contact information, etc. associated with the owner/operator of the master/BS with the trusted database service (if not currently registered). Meanwhile the DB administrator may be required to store and forward the registration information to the regulatory authority. If a trusted white space database administrator is not discovered, further operation of the WRAN may be allowed according to local regulator policy (in this case operation of the WRAN is outside the scope of the PAWS protocol). 4. Following the registration process, the master/BS will send a query to the trusted database requesting a list of available WS channels based upon its geolocation. 5. If the master/BS has been previously authenticated, the database responds with a list of available white space channels that may be used and optionally a maximum transmit power (EIRP) for each channel and a duration of time the channel may be used. Probasco, et al. Expires January 13, 2012 [Page 8] Internet-Draft PAWS: Use Cases July 2011 6. Once the master/BS authenticates the WS channel list response message from the database, the master/BS selects an available WS channel(s) from the list. The operator may disallow some channels from the list to suit local needs if required. 7. The master/BS acknowledges to the database which of the available WS channels the BS has selected for its operation. The database is updated with the information provided by the BS. 8. The slave or user device scans the TV bands to locate a WRAN transmission, and associates with the master/BS. The slave/user device queries the master for a channel list, based on the slaves' geolocation. 9. The master provides the list of channels locally availabe to the slave/user device. If the channel that the user terminal is currently using is not included in the list of locally available channels, the slave/user device ceases all operation on its current channel. The slave/user device may scan for another WRAN transmission on a different channel. 3.4. Offloading: moving traffic to a white space network In this use case internet connectivity service is provided over TV white space as a supplemental or alternative datapath to a 3G or other internet connection. In a typical deployment scenario an end user has a primary internet connection such as a 3G cellular packet data subscription. The user wants to use a widget or application to stream video from an online service (e.g. youtube) to their device. Before the widget starts the streaming connection it checks connectivity options available at the current time and location. Both 3G cellular data is available as well as TVWS connectivity (the user is within coverage of a TVWS master -- hot spot, WAN, WRAN or similar). The user may decide for many and various reasons such as cost, RF coverage, data caps, etc... to prefer the TVWS connection over the 3G cellular data connection. Either by user selection, preconfigured preferences, or other algorithm, the streaming session is started over the TVWS internet connection instead of the 3G cellular connection. This deployment scenario is typically characterized by a TVWS master/AP providing local coverage in the same geographical area as a 3G cellular system. The master/AP is assumed to be individually deployed and operated, i.e. the master/AP is deployed and operated by the user at his home or perhaps by a small business such as a coffee shop. The master/AP has a connection to the internet and provides internet connectivity to the slave/ end-user's device. The figure below shows an example deployment of this scenario. Probasco, et al. Expires January 13, 2012 [Page 9] Internet-Draft PAWS: Use Cases July 2011 \|/ | | |-|---------| | Master/AP |\ /| Router | \ Streaming/ |-----------| \ -------- / \ ----------- |Slave/| / \ (----) | Database | |WS Dev| \ ( ) /---------- ------- \ \ / \ \ X( Internet ) \ / \ / Signaling \|/ / ( )\ \ | / (----) \---------- \ | / | YouTube | \|-|---------| / ---------- | Master / | / | 3G BTS |/ |-----------| Figure 4: Offloading: moving traffic to a white space network Once a dual or multi mode device (3G + TVWS) is connected to a 3G network, a simplified operation scenario of offloading selected content such as video stream from the 3G connection to the TWVS connection consists of the following steps: 1. The dual mode (or multi mode) device (3G + TVWS) is connected to a 3G network. The device has contacted a trusted database to discover the list of available TV channels at is current location. The device has located a TVWS master/AP operating on an available channel and has associated or connected with the TVWS master/AP. 2. The user activates a widget or application that streams video from YouTube. The widget connects to YouTube over 3G cellular data. The user browses content and searches for video selections. 3. The user selects a video for streaming using the widget's controls. Before the widget initiates a streaming session, the widget checks the available connections in the dual mode device and finds a TVWS master/AP is connected. 4. Using either input from the user or pre-defined profile preferences, the widget selects the TVWS master/AP as the Probasco, et al. Expires January 13, 2012 [Page 10] Internet-Draft PAWS: Use Cases July 2011 connection to stream the video. 3.5. TVWS for backhaul In this use case internet connectivity service is provided to users over a traditional wireless protocol, one common example is Wi-Fi. The TV white space network provides the "backhaul" or connection from the Wi-Fi to the internet. In a typical deployment scenario an end user has a device with a radio such as Wi-Fi. A service provider or shop owner wants to provide Wi-Fi internet service for their customers. The location where the service provider wants to provide Wi-Fi is within range of a TVWS master (e.g. Hot-Spot or Wide-Area/ Rural network). The service provider installs a TVWS slave device and connect this slave to a Wi-Fi access point. This deployment scenario is typically characterized by a TVWS master/AP/BS providing local coverage. The master/AP has a connection to the internet and provides internet connectivity to the slave device. The slave device is then 'bridged' to a Wi-Fi network The figure below shows an example deployment of this scenario. \|/ white \|/ \|/ WiFi \|/ | space | | | | | | |-|----| |--------| |-|---------| |-|------|-| | WiFi | | | | Master | | Slave | | Dev | |internet|------| (AP/BS) | | Bridge | |------| | | | | | to WiFi | |--------| |-----------| |----------| \|/ | |-|----| | WiFi | | Dev | |------| Figure 5: TVWS for backhaul Once the bridged device (TVWS+WiFi) is connected to a master and TVWS network, a simplified operation scenario of backhaul for WiFi consists of the following steps: 1. A bridged device (TVWS+WiFi) is connected to a master device operating in the TVWS. The bridged device operates as a slave device in either Hot-Spot or Wide-Area/Rural internet use cases described above. Probasco, et al. Expires January 13, 2012 [Page 11] Internet-Draft PAWS: Use Cases July 2011 2. Once the slave device is connected to the master, the Wi-Fi access point configures its internet settings automatically based on the backhaul connection (i.e. it uses DHCP). 3. End users connect their WiFi device to the bridged device and receive internet connectivity. 3.6. Location based service usage scenario The owner of a shopping mall wants to provide internet access to customers when they are at the shopping mall. His internet service provider (ISP) recommends using master/AP devices in the TV white space frequency band since these radios will have good propagation characteristics, and thus will require fewer devices, and also because the frequency band used by traditional Wi-Fi is crowded with users such as individual stores operating their own Wi-Fi network and also Bluetooth devices. The ISP installs APs in each large store in the mall, and several other APs throughout the mall building. For each AP, the professional installer programs the location (latitude and longitude) of the device. Special tools are required to determine the location, since typical GPS receivers do not function indoors. When each AP is powered on, the radio does not transmit initially. The AP contacts a white space database, using its wired internet connection, via a URL and provides its programmed location coordinates plus other information required by the database. A reply is received by the AP from the database containing a list of available channels where the AP can operate its transmitter. The AP selects a channel for operation and notifies the database, which records information about the AP including the identity of the AP and its location coordinates. The AP activates its radio and begins to function as a typical wireless AP, providing internet access to connected devices. A user has a slave device that is capable of operating in the TV white spaces frequency band. A typical device would be a smartphone with multiple radios, including a cellular radio, a Wi-Fi radio, and TV white space radio. The user arrives at the shopping mall and enters the building. The white space radio in the smartphone is on, and is scanning for a master/AP. As the user gets near the entrance to the shopping mall, the smartphone locates one of the APs in the building and connects to it. The smartphone begins to use this TVWS radio for internet access. This internet access does not count against the users cellular data cap (the mall owner is providing the internet access) and also the data rates are better than cellular data. As the user walks throughout the mall the smartphone moves between coverage of different APs, and the smartphone connects to a new AP when the user and smartphone move near it. Probasco, et al. Expires January 13, 2012 [Page 12] Internet-Draft PAWS: Use Cases July 2011 In order to encourage customers to come to the shopping mall, the mall owner has a loyalty program where members register, build points, and receive coupons and other notices from the shops in the mall. Before installing the internet service in the mall, all loyalty program information was mailed to the user, at an address which was provided by the user when joining the loyalty program. The ISP provider describes to the mall owner how the loyalty program can be improved using the internet service provided by the APs in the TV white space. A new app is developed for this loyalty program, and promoted to users, asking them to install the app on their smartphone. The app is provisioned with the user's loyalty program information. When the user comes to the shopping mall, the smartphone locates the master/AP providing internet service and connects to the AP. The app in the smartphone sees that a radio connection to an AP in the TV white space frequency band is now active. The app registers the identity of the AP and forwards this to the home server for the loyalty program, using the internet connection provided by the AP in the TV white space band. The loyalty program server registers the identity of the user from the loyalty program credentials and also the identity of the AP. Next the loyalty program server contacts the TV white space database and requests the location of the master/AP having the identity forwarded by the app and smartphone. When the TV white space database replies with the location coordinates of the AP, the loyalty program server knows the approximate location of the user and smartphone. With this location information, the loyalty program server can now forward loyalty program information to the user. As the user moves through the mall, the smartphone connects to different APs. The process is repeated, allowing the loyalty program to delivery current location based information to the user. 1. The master create a TVWS network as described in use case "Hot- Spot: urband internet connectivity service." 2. An application running on the user's slave device (e.g. smartphone) determines that a network connection exists in the TVWS band. The identify of the master/AP is recorded by the application and forwarded to a server in the internet cloud. 3. The server queries the trusted white space database with the master identity provided by the application in the user's smartphone. 4. The trusted white space database replies to the server with the location of the master device. Probasco, et al. Expires January 13, 2012 [Page 13] Internet-Draft PAWS: Use Cases July 2011 5. The server uses the location of the master/AP to determine the approximate location of the user's smartphone. The server provides location-specific service to the user via the application running in the smartphone. 4. Requirements 4.1. Master 1. A master device MUST include, directly or indirectly, its antenna height in the query to the WS Database. 2. A master device MUST query the WS Database for the available channels at least once a day to verify that the operating channels continue to remain available. 3. A master device MUST determine its location with at least =/-50 meters accuracy and MUST place that location into the query it makes to the WS Database. 4. A master device MAY indicate the accuracy by which it determined its location in the query to the WS Database. 5. A master device which changes its location during operation MUST query the WS Database for available operating channels each time it moves more than 100 meters from the location it previously made the query. 6. A master device MUST be able to receive channel availability updates from a WS Database. 7. A master device MUST be able to query the WS Database for channel availability information for multiple locations. 8. A master device MUST be able to query the WS Database for channel availability information for a specific area around its current location. 9. A master device MUST query the WS Database and include the FCC ID of the slave device in the query before allowing the slave device to use the available channel. 4.2. Database 1. The WS Database MUST provide the available channel list when requested and MAY also provide time constraints for the channel list and maximum output power to the master device. Probasco, et al. Expires January 13, 2012 [Page 14] Internet-Draft PAWS: Use Cases July 2011 4.3. Security 1. The protocol between the master device and the WS Database MUST support mutual authentication and authorization. 2. The protocol between the master device and the WS Database MUST support integrity and confidentiality protection. 3. The WS Database MUST support both username/password and digital certificates based authentication of the master device. 4. A master device MUST be capable to validate the digital certificate of the WS Database. 5. A master device MUST be capable to check the validity of the WS Database certificate and whether it has been revoked or not. 5. IANA Considerations This document has no requests to IANA. 6. Security Considerations The messaging interface between the master and the database must be secure to ensure confidentiality, authenticity and integrity of the data exchanged between devices. A master queries a database with information which identifies owner/operator of the device and also the location of the device. Such information can reasonably considered to be sensitive information which must remain confidential. A well-functioning white space network relies upon trusted devices exchanging trusted information, thus each participant in the protocol exchange must be authenticated. A white space network must ensure the protection of the primary user of the radio spectrum, therefore the integrity of the message exchange must be ensured. 7. Summary and Conclusion The document describes some examples of the role of the white space database in the operation of a radio network and also shows an examples of a services provided to the user of a TVWS device. From these use cases requirements are determined. These requirements are to be used as input to the definition of a Protocol to Access White Space database (PAWS). Probasco, et al. Expires January 13, 2012 [Page 15] Internet-Draft PAWS: Use Cases July 2011 8. Acknowledgements The authors acknowledge Tom Derryberry as contributor to version 00 of this document. 9. References 9.1. Normative References [PAWS-PS] IETF, "Protocol to Access White Space database: Problem statement; https://datatracker.ietf.org/doc/ draft-patil-paws-problem-stmt/", July 2011. [RFC2119] IETF, "Key words for use in RFCs to Indicate Requirement Levels; http://www.rfc-editor.org/rfc/pdfrfc/rfc2119.txt.pdf", March 1997. 9.2. Informative References [FCC Ruling] FCC, "Federal Communications Commission, "Unlicensed Operation in the TV Broadcast Bands; http://edocket.access.gpo.gov/2010/pdf/2010-30184.pdf", December 2010. [TV Whitespace Tutorial Intro] IEEE 802 Executive Committee Study Group on TV White Spaces, "TV Whitespace Tutorial Intro; http:// grouper.ieee.org/groups/802/802_tutorials/2009-03/ 2009-03-10%20TV%20Whitespace%20Tutorial%20r0.pdf", March 2009. Authors' Addresses Scott Probasco (editor) Nokia 6021 Connection drive Irving, TX 75039 USA Email: scott.probasco@nokia.com Probasco, et al. Expires January 13, 2012 [Page 16] Internet-Draft PAWS: Use Cases July 2011 Gabor Bajko Nokia 200 South Mathilda Ave Sunnyvale, CA 94086 USA Email: gabor.bajko@nokia.com Basavaraj Patil Nokia 6021 Connection drive Irving, TX 75039 USA Email: basavaraj.patil@nokia.com Probasco, et al. Expires January 13, 2012 [Page 17]