RFC 6953
Protocol to Access White-Space (PAWS) Databases: Use Cases and Requirements
RFC 6953: Protocol to Access White-Space (PAWS) Databases: Use Cases and Requirements 🦋✨
Okay bestie, here's the deal with RFC 6953 🎀. It's an Informational doc from the IETF, dated May 2013, with ISSN 2070-1721. The authors are A. Mancuso, Ed. (Google), S. Probasco (no affiliation listed in the title block), and B. Patil (Cisco Systems). Category is Informational, and the title block doesn't list anything it obsoletes or updates. Super clean 💅
Abstract
So here's the tea ☕ Parts of the radio spectrum that are assigned to a particular use but sit unused or unoccupied at certain places and times are called "white space" 🌸 Letting extra transmissions (licensed or not) use that white space is how you "unlock" existing spectrum for something new. This doc gives the problem statement for building a protocol that accesses a database of white-space information, then walks through use cases and requirements for that protocol. Last but not least, it lists the requirements for the protocol itself 🧚
Status of This Memo
This doc isn't an Internet Standards Track spec, it's published just for info 📚
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It's had public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🤓
For current status, errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6953 🔗
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. ✨
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read these, because they spell out your rights and restrictions for this doc 🙈 Any Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 💜
Table of Contents 🌈
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Introduction to White Space . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 5
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Global Applicability . . . . . . . . . . . . . . . . . . . 6
3.2. Database Discovery . . . . . . . . . . . . . . . . . . . . 8
3.3. Device Registration . . . . . . . . . . . . . . . . . . . 8
3.4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.5. Data Model Definition . . . . . . . . . . . . . . . . . . 9
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Master-Slave White-Space Networks . . . . . . . . . . . . 9
4.2. Offloading: Moving Traffic to a White-Space Network . . . 11
4.3. White Space Serving as Backhaul . . . . . . . . . . . . . 13
4.4. Rapid Network Deployment during Emergencies . . . . . . . 14
4.5. White Space Used for Local TV Broadcaster . . . . . . . . 15
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Data Model Requirements . . . . . . . . . . . . . . . . . 16
5.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 17
5.3. Operational Requirements . . . . . . . . . . . . . . . . . 19
5.4. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . . 221. Introduction ✨
1.1. Introduction to White Space
Okay so wireless spectrum is a commodity, and governments regulate it 🏛️ It gets used for all kinds of things: entertainment (e.g., radio and television), communication (e.g., telephony and Internet access), military (e.g., radars, etc.), and navigation (e.g., satellite communication, GPS) 🛰️ Parts of the radio spectrum assigned to a licensed (primary) user, but unused or unoccupied at specific locations and times, are defined as "white space" 🤍 Allowing additional (secondary) transmissions in that white space (which may or may not be licensed) is how you "unlock" existing spectrum for new use 🔓
Obviously, secondary transmissions can't interfere with the assigned use of the spectrum 🙅♀️ Here's what's interesting: in a given physical location, the primary user(s) often aren't using the entire band assigned to them. So the spectrum available for secondary transmissions depends on where the secondary user is 📍 The real question is how to figure out, for a specific location and a specific time, whether any of the assigned spectrum is free for secondary use 🤔
Academia and industry have studied multiple cognitive radio [CRADIO] mechanisms for this kind of scenario 🧠 One simple mechanism is a geospatial database that holds the spatial and temporal profile of all the primary licensees' spectrum usage. Secondary users are then required to query that database for the spectrum they can use at their location 💌 These databases can be reached and queried by secondary users over the Internet 🌐
Any entity assigned spectrum that isn't densely used might get asked by a government regulatory agency to share it, so more intensive use is possible 🤝 Giving secondary users a way to share spectrum with the primary user is attractive in many bands, in many countries 🌍
This doc includes the problem statement, followed by use cases and requirements for using white-space spectrum as a secondary user through a database query protocol 📋 The final sections cover the requirements for that protocol. Note that the IETF has taken on developing a database query protocol (see [PAWS]) 🫶
1.2. Scope
1.2.1. In Scope
This doc covers requirements for a protocol that lets a device access a database to get spectrum availability information 📡 That protocol should let a device do the following:
- Determine the relevant database to query.
- Connect to and optionally register with the database using a well-defined protocol.
- Provide geolocation and perhaps other data to the database using a well-defined format for querying the database.
- Receive, in response to the query, a list of available white-space frequencies at the specified geolocation, using a well-defined format for the information.
- Send an acknowledgment to the database with information containing channels selected for use by the device and other device operation parameters.
Note: The protocol actions above should explicitly or implicitly support devices re-registering and/or re-querying the database when they change their locations or operating parameters 🔄 That way, they can get permission to operate in their new locations and/or with their new operating parameters, and send acknowledgments to the database that include info on those new operating parameters 💖
1.2.2. Out of Scope
These topics are out of scope for this spec, bestie 🙅♀️
- It's the device's responsibility to query the database for new spectrum when the device moves, changes operating parameters, loses connectivity, etc. Other synchronization mechanisms are out of scope.
- A rogue device may operate without contacting the database to get available spectrum. So enforcing spectrum usage by devices is out of scope. 🚨
- The protocol defines communications between the database and devices. The protocol for communications between devices is out of scope.
- Coexistence and interference avoidance of white-space devices within the same spectrum are out of scope.
- Provisioning (releasing new spectrum for white-space use) is out of scope.
2. Conventions Used in This Document 💅
2.1. Terminology
Here's the vocab you need 📖
- Database: An entity that holds current info about available spectrum at a given location and time, plus other kinds of info related to spectrum availability and usage.
- Device Class: Identifies classes of devices, including fixed, mobile, portable, etc. It may also indicate whether the device is indoor or outdoor 🏠
- Device ID: An identifier for a device 🆔
- Master Device: A device that queries the database, on its own behalf and/or on behalf of a slave device, to get available spectrum information 👑
- Slave Device: A device that queries the database through a master device 🧚
- Trusted Database: A database that a device trusts, or one that provides data objects a device trusts 🤞
- White Space (WS): Radio spectrum that's available for secondary use at a specific location and time 🤍
- White-Space Device (WSD): A device that uses white-space spectrum as a secondary user. A white-space device can be a fixed or portable device, such as an access point, base station, or cell phone 📱
2.2. Requirements Language
Here's where the capital letters matter, so pay attention 👀 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] 💜
3. Problem Statement ✨
okay so the whole magic of white-space spectrum is that a device can ask a database what spectrum is free at its exact spot 🌸 the databases are reachable over the Internet, and the devices asking them are expected to have some kind of Internet connection, direct or indirect 🫶 databases should support the rule set(s) of one or more regulatory domains, and those rules and the spectrum they cover can vary a lot, but the core way the protocol works must stay the same no matter which regulatory environment you're in 💅
here's the high-level architecture of devices and databases, bestie 🦋
-----------
| Master |
|WS Device| ------------
|Lat: X |\ .---. /--------|Database A|
|Long: Y | \ ( ) / ------------
----------- \-------/ \/ o
( Internet) o
----------- /------( )\ o
| Master | / ( ) \ o
|WS Device|/ (_____) \ ------------
|Lat: X | \------|Database B|
|Long: Y | ------------
-----------Figure 1: High-Level View of White-Space Database Architecture
note that there could be multiple databases serving white-space devices ✨ in some countries, like the U.S., the regulator has decided that multiple databases may provide service to white-space devices 🇺🇸
a messaging interface between the white-space devices and the database is required for operating a network using white-space spectrum 🎀 the next sections dig into the different parts of that interface and why we need a standard for it 🧚
3.1. Global Applicability 🌈
white-space spectrum is already approved, or being considered, in lots of regulatory domains, and their rules can be different 🌍 but the need for devices that want to use the spectrum to talk to a database stays the same everywhere, and that's the big common thread 🫶 the database has to enforce rules that protect all primary users, no matter what the white-space devices are like 🛡️ it also has to give a way to specify a schedule of use, because some primary users (like wireless microphones) only operate in limited time slots ⏰
devices need to be able to query a database, directly or indirectly, over the public Internet and/or private IP networks before they operate in available spectrum 💖 the database answers the query with info about available spectrum, schedule, power, etc. 💜 the messaging interface needs to be:
- Interface agnostic - An interface between a master white-space device and database can be wired or unwired (e.g., a radio/air interface technology such as IEEE 802.11af, IEEE 802.15.4m, IEEE 802.16, IEEE 802.22, LTE, etc.) However, the messaging interface between a master white-space device and the database should be agnostic to the interface used for such messaging while being cognizant of the characteristics of the interface technology and the need to include any relevant attributes in the query to the database. 🔌
- Spectrum agnostic - The spectrum used by primary and secondary users varies by country. Some spectrum bands have an explicit notion of a "channel": a defined swath of spectrum within a band that has some assigned identifier. Other spectrum bands may be subject to white-space sharing, but only have actual frequency low/high parameters to define primary and secondary use. The protocol should be able to be used in any spectrum band where white-space sharing is permitted. 📡
- Globally applicable - A common messaging interface between white-space devices and databases will enable the use of such spectrum for various purposes on a global basis. Devices can operate in any location where such spectrum is available, and a common interface ensures uniformity in implementations and deployment. To allow the global use of white-space devices in different countries (whatever the regulatory domain), the protocol should support the database that communicates the applicable regulatory rule-set information to the white-space device. 🌏
- Built on flexible and extensible data structures - Different databases are likely to have different requirements for the kinds of data required for registration (different regulatory rule sets that apply to the registration of devices) and other messages sent by the device to the database. For instance, different regulators might require different device-characteristic information to be passed to the database. 🧩
3.2. Database Discovery 🔍
the master device must obtain the address of a trusted database, which it will query for available white-space spectrum 🗝️ if the master device uses a discovery service to locate a trusted database, it may do the following steps (this description is intended as descriptive, not prescriptive) 🫧
- The master device constructs and sends a request (e.g., over the Internet) to a trusted discovery service. 📨
- If no acceptable response is received within a pre-configured time limit, the master device concludes that no trusted database is available. If at least one response is received, the master device evaluates the response(s) to determine if a trusted database can be identified where the master device is able to receive service from the database. If so, it establishes contact with the trusted database. 🤝
- The master device establishes a white-space network as described in Section 4. 🎉
optionally, and in place of steps 1-2 above, the master device can be pre-configured with the address (e.g., URI) of one or more trusted databases 🎀 the master device can then establish contact with one of these trusted databases 💅
3.3. Device Registration 📝
the master device may register with the database before it queries the database for available spectrum 💌 a registration process may consist of the following steps:
- The master device sends registration information to the database. This information may include the device ID; serial number assigned by the manufacturer; device location; device antenna height above ground; name of the individual or business that owns the device; and the name, postal address, email address, and phone number of a contact person responsible for the device's operation. 🪪
- The database responds to the registration request with an acknowledgment to indicate the success of the registration request or with an error if the registration was unsuccessful. Additional information may be provided by the database in its response to the master device. ✅
3.4. Protocol 🧚♀️
a protocol that lets a white-space device query a database for available spectrum is needed ✨ a device may be required to register with the database, with some credentials, before it's allowed to query ✨ the requirements for that protocol are specified in this document 💜
3.5. Data Model Definition 🗂️
the contents of the queries and responses need to be specified 🧠 a data model is required, and it must let the white-space device query the database while including all the relevant info, like geolocation, radio technology, power characteristics, etc. 📍 those may depend on the country, the spectrum, and the regulatory domain 🌸 all databases are able to interpret the data model and respond to queries using the same data model that every device understands 🫶
4. Use Cases 🌟
there are so many use cases for white-space spectrum 😍 for example, broadband Internet access in urban and densely populated hotspots, plus rural and remote, underserved areas 🏡 it can also be used to provide Internet "backhaul" for traditional Wi-Fi hotspots, or for towns and cities to monitor/control traffic lights, read utility meters, and the like 🚦 other use cases include offloading data traffic from another Internet access network (e.g., 3G cellular network), or delivering data, information, or a service to a user based on the user's location 📲 some of these are described in the following sections, so keep reading 🦋
4.1. Master-Slave White-Space Networks 📡
Okay so there are a bunch of common setups where a master white-space device acts like a proxy or middleman 🫶. It uses its Internet connection to ask the database what spectrum is free, both for itself and for one or more slave devices. The slaves can be fixed or mobile, sitting close together (indoor network or urban hotspot) or way out far (rural or remote WAN) 🌄. Once the slaves switch to white-space spectrum, they can either go out to the Internet through the master or just talk to each other on white space inside the network 🔥. The master can keep running the show, controlling white-space communications from the slaves, and it can tell them when to change white-space frequencies or stop using white space altogether 👑.
Figure 2 shows the basic setup, where the master talks to the database for itself and for its slaves 💖.
--------
|Slave |
|Device| \ \|/ ----------
| 1 | (Air) | |Database|
-------- \ | (----) /|--------|
| \ ------|------ ( ) /
| \| Master | / \
-------- /| |======= ( Internet )
|Slave | / | Device | \ /
|Device| (Air) | | ( )
| 2 | / |-----------| (----)
-------- /
o | /
o | (Air)
o | /
-------- /
|Slave | /
|Device| /
| n |
--------
Figure 2: Master-Slave White-Space NetworkFigure 2: Master-Slave White-Space Network
The protocol requirements for these master-slave setups and other similar scenarios are basically the same 🧚. The protocol must let a master make available-spectrum query requests on behalf of its slaves, passing along device identification, geolocation, and other slave device parameters to the database as needed to get a list of white-space spectrum that one or more slaves can use ✨. Different use cases will obviously use that spectrum info in different ways, and the details of master/slave communications may differ from one use case to another 💅.
Here are the common steps that can happen in master-slave networks 🌸:
- The master device powers up.
- Slave devices may power up and associate with the master device via Wi-Fi or some other over-the-air, non-white-space spectrum. Until the slave device is allocated white-space spectrum, any master-slave or slave-slave communications happen over that non-white-space spectrum.
- The master has Internet connectivity, determines (or knows) its location, and establishes a connection to a trusted database (see Section 3.2).
- The master may register with the trusted database (see Section 3.3).
- The master sends a query to the trusted database requesting a list of available white-space spectrum based upon its geolocation. Query parameters may include the master's location, device identifier, and antenna height. The master may send available-spectrum requests to the database on behalf of slave devices.
- The database responds to the master's query with a list of available white-space spectrum, associated maximum power levels, and durations of time for spectrum use. If the master made requests on behalf of slave devices, the master may transmit the obtained available-spectrum lists to the slaves (or the master may allocate spectrum to slaves from the obtained spectrum lists).
- The master may inform the database of the spectrum and power level it selects from the available spectrum list. If a slave device has been allocated available white-space spectrum, the slave may inform the master of the spectrum and power level it has chosen, and the master may, in turn, relay such slave device usage to the database.
- Further communication among masters and slaves over the white-space network may occur via the selected/allocated white-space spectrum frequencies.
Note: Steps 5 through 7 may be repeated by the master device when it (or a slave device that uses the master as a proxy to communicate with the database) changes its location or operating parameters -- for example, after a master changes location, it may query the database for available spectrum at its new location, then acknowledge the subsequent response received from the database with information on the spectrum and power levels it is using at the new location. 🔁
4.2. Offloading: Moving Traffic to a White-Space Network 🚀
This one is a variant of the master-slave network from the last use case, so it's giving familiar vibes 🦋. Here an access point (AP) offers a white-space service that offloads Internet traffic onto an alternative data path, instead of a more congested or costly Internet wire, wireless, or satellite service 📶.
Figure 3 shows an example of how this scenario gets deployed 🌈.
\|/
|
|--|----------|
\|/ /|Access Point |\
| (Air)--/ |-------------| \
--|------ / \ -----------
|Portable|/ \ (----) | Database|
| Device | \ ( ) /----------
|--------|\ \ / \
\ X( Internet )
\ / \ /
(Air) / ( )
\ / (----)
\ /
\|---------------|/
| Metered |
| Service |
|---------------|Figure 3: Offloading Traffic to a White-Space Network
A simplified version of offloading content, like a video stream, from a congested or costly Internet connection to a white-space service provided by an AP goes like this 🎬:
- The AP contacts the database to determine channels it can use.
- The portable device connects to a paid Internet service and selects a video for streaming.
- The portable device determines if it can offload to a white-space AP:
- A. If the portable device knows its location, it:
- asks the database (using the paid service) for available white-space spectrum;
- listens for and connects to the AP over the permitted white-space spectrum.
- B. If the portable device does not have GPS or other means to determine its position, it:
- uses non-white-space spectrum to listen for and connect to the AP;
- asks the AP to query the database for permitted white-space spectrum on its behalf;
- uses the permitted white-space spectrum to connect to the AP.
- A. If the portable device knows its location, it:
- The portable device accesses the Internet through the AP to stream the selected video. 🍿
4.3. White Space Serving as Backhaul 🌷
In this use case, an Internet connectivity service is provided to users over a common wireless standard, like Wi-Fi, and a white-space master/slave network handles the backhaul connection to the Internet 💜. Wi-Fi shows up in Figure 4 and the discussion that follows, but any other technology can be swapped in for it 🔄.
Figure 4 shows an example of how this scenario gets deployed 🧁.
\|/ White \|/ \|/ Wi-Fi \|/
| Space | | |
| | | |-|----|
(----) |-|----| |-|------|-| | Wi-Fi|
( ) |Master| | Slave |--(Air)--| Dev |
/ \ | |--(Air)--| Bridge | |------|
( Internet )---| | | to Wi-Fi |
\ / |------| |----------| \|/
( ) \ |
(----) \(Air) |-|----|
\--| Wi-Fi|
| Dev |
|------|Figure 4: White-Space Network Used for Backhaul
Once the bridged device (Slave Bridge + Wi-Fi) is connected to a master and WS network, a simplified backhaul scenario for Wi-Fi goes like this 🎀:
- A bridged slave device (Slave Bridge + Wi-Fi) is connected to a master device operating in the WS spectrum (the master obtains available white-space spectrum as described in Section 4.1).
- Once the slave device is connected to the master, the Wi-Fi access point has Internet connectivity as well.
- End users attach to the Wi-Fi network via their Wi-Fi-enabled devices and receive Internet connectivity. 🫧
4.4. Rapid Network Deployment during Emergencies 🚨
okay so emergency orgs run on their own dedicated spectrum 📡, but the disasters they're responding to can literally wipe out that same infrastructure 😭. so when they need a replacement network, the spectrum has to get cleared and handed over to the crisis response org super fast ⚡. automating that allocation and assignment is usually the best move 🫶. the preferred route is a robust protocol that radio manufacturers have already adopted and implemented 🔥. a typical setup might mix wireless access links to the public Internet or a private network, wireless ad hoc radios that work on their own without fixed infrastructure 🦋, and satellite links as a backup for when coverage is lacking, the wireless access links get overloaded, or they go down entirely 🛰️.
Figure 5 shows what this looks like in practice ✨
\|/
| ad hoc
|
|-|-------------|
| Master node | |-------------|
\|/ | with | | White-Space |
| ad hoc /| backhaul link | | Database |
| /---/ |---------------| |-------------|
---|------------/ | \ /
| Master node | | | (--/--)
| without | | -----( )
| backhaul link | | Wireless / Private \
----------------\ | Access ( net or )
\ | \ Internet )
\ \|/ | ------( /
\ | ad hoc | | (------)
\ | | / \
\--|------------- /Satellite ----------
| Master node | / Link | Other |
| with |/ | nodes |
| backhaul link | ----------
-----------------Figure 5: Rapidly Deployed Network with Partly Connected Nodes
okay so in the ad hoc network, every node is a master node 👑 and each one grabs its RF channels from the database (see Section 4.1) 💅. the catch is that not every node has a backhaul link, like the left node in the figure above 🙈. to fix that, a master node that does have a backhaul link relays or proxies the database query on behalf of the nodes that don't 🧚. so master nodes without a backhaul link just follow the procedure defined for clients 💖. the ad hoc radios then use the RF channels they've been given 📻.
⚠️ bestie, forming and maintaining the ad hoc network is NOT part of spectrum allocation. that includes repairing segmented networks, even when the segments are running on different RF channels, so don't go looking for that here 🙅♀️
4.5. White Space Used for Local TV Broadcaster 📺
ngl this one is so iconic 🌈. white-space spectrum can be used in fresh ways to reach hand-held and portable devices that the public uses ✨. one example is sending local TV audio-video content to portable devices belonging to people at an event 🎀. picture an audience at a seminar, a concert, or some other venue, all plugging a tiny TV receiver fob into their laptop, tablet, phone, or whatever portable device they've got 🍓. a master device gets a list of available white-space spectrum (see Section 4.1), then broadcasts the audio-video content to the whole crowd over one of those available frequencies 📡. the audience picks it up with their miniature TV receivers, which are tuned to the right white-space band, and it shows up on their portable device's screen 💜.
Figure 6 shows what this scenario looks like 🦋
|------------|
|White-Space |
| Database |
.---. / |------------|
|-----------| ( ) /
| Master | / \
| |========( Internet)
|-----------| \ /
| ( )
/|\ (---)
(White-Space
Broadcast)
\|/ \|/ \|/ \|/ \|/ \|/ \|/
| | | | | | | .................
----- ----- ----- ----- ----- ----- -----
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
----- ----- ----- ----- ----- ----- -----
USB TV receivers connected to laptops, cell phones, tablets ...Figure 6: White Space Used for Local TV Broadcast
5. Requirements 💅
5.1. Data Model Requirements 📋
okay so these are the data model requirements, and they're kinda the main event 🔥. here's the vibe for each one:
D.1 🌍 The data model MUST support specifying the geolocation of the white-space device, the uncertainty in meters, the height and its uncertainty, and the percentage of confidence in the location determination. The data model MUST support [WGS84].
D.2 📜 The data model MUST support specifying the data and other applicable requirements of the rule set that applies to the white-space device at a specified location.
D.3 🏷️ The data model MUST support device description data that identifies a white-space device (serial number, certification IDs, etc.) and describes device characteristics, such as device class (fixed, mobile, portable, indoor, outdoor, etc.), Radio Access Technology (RAT), etc.
D.4 🔢 The data model MUST support specifying a manufacturer's serial number for a white-space device.
D.5 📡 The data model MUST support specifying the antenna- and radiation-related parameters of the white-space device, such as:
- antenna height
- antenna gain
- maximum output power, Equivalent Isotropic Radiated Power (EIRP) in dBm (decibels referenced to 1 milliwatt)
- antenna radiation pattern (directional dependence of the strength of the radio signal from the antenna)
- spectrum mask with lowest and highest possible frequency
- spectrum mask in dBr (decibels referenced to an arbitrary reference level) from peak transmit power in EIRP, with specific power limit at any frequency linearly interpolated between adjacent points of the spectrum mask
- measurement resolution bandwidth for EIRP measurements
D.6 🤝 The data model MUST support specifying owner and operator contact information for a transmitter. This includes the name of the transmitter owner and the name, postal address, email address, and phone number of the transmitter operator.
D.7 📶 The data model MUST support specifying spectrum availability. Spectrum units are specified by low and high frequencies and may have an optional channel identifier. The data model MUST support a schedule including start time and stop time for spectrum unit availability. The data model MUST support maximum power level for each spectrum unit.
D.8 🗺️ The data model MUST support specifying spectrum availability information for a single location and an area (e.g., a polygon defined by multiple location points or a geometric shape such as a circle).
D.9 ✅ The data model MUST support specifying the frequencies and power levels selected for use by a white-space device in the acknowledgment message.
5.2. Protocol Requirements
okay so this is the protocol checklist, bestie 📋✨ Each item gets an ID like P.1 so we can point at it later.
P.1🔎 The master device has to be able to find a database it can register with and ask for spectrum availability. The protocol MUST support discovering a suitable database from a location the master device gives it. The master device MAY pick a database by discovering one at run time, or by using a pre-programmed URI. It MAY also check discovered or configured database addresses against a list of known databases (for example, databases approved by a regulatory body). Very cautious, very iconic 💅P.2📜 The protocol MUST let the database tell the master which regulatory rules (rule set) apply to the master device, or to any slave devices the master is contacting the database for, at a given location.P.3🪪 The protocol MUST let the database authenticate the master device. Basically it has to be able to check who's knocking 🚪P.4🤝 The protocol MUST let the master device verify the authenticity of the database it's talking to. Two-way trust, no cap 💖P.5🛡️ Messages going from the master device to the database, and messages going from the database to the master device, MUST support integrity protection. Nobody gets to quietly edit the text in the middle 👀P.6🔐 The protocol MUST be able to encrypt messages sent by the master device and the database.P.7🦋 Okay, real talk: if people who run or access a white-space database (database admins, regulatory agencies, and others) can track what master or slave devices do with white-space spectrum, that could be seriously invasive, and privacy rules in some places might care a lot. So the PAWS protocol SHOULD support privacy-sensitive handling of device-provided data where that protection is feasible, allowed, and desired. Privacy matters, bestie 🌸P.8📝 The protocol MUST support the master device registering with the database. See Device Registration (Section 3.3).P.9✅ The protocol MUST support a registration acknowledgment that says whether the master device's registration worked or didn't.P.10🙋 The protocol MUST support an available spectrum request from the master device to the database. It may include one or more of the data items in Data Model Requirements (Section 5.1). The request may carry data the master sends for itself, and/or for one or more slave devices.P.11📬 The protocol MUST support an available spectrum response from the database to the master device. It may include one or more of the data items in Data Model Requirements (Section 5.1). The response may include data about how the master and/or slave devices are supposed to operate.P.12📈 The protocol MUST support a spectrum usage message from the master device to the database. It may include one or more of the data items in Data Model Requirements (Section 5.1). The message may carry data the master sends for itself, and/or for one or more slave devices.P.13👍 The protocol MUST support a spectrum usage message acknowledgment.P.14🔍 The protocol MUST support a validation request from the master device to the database, to validate a slave device. It should include the information needed to identify that slave device to the database.P.15🧾 The protocol MUST support a validation response from the database to the master, saying whether the slave device has been validated. The validation response MUST indicate whether the validation request succeeded or failed.P.16📢 The protocol MUST support the database telling master devices when spectrum availability information changes. Gossip, but make it official 🗞️
5.3. Operational Requirements
okay this section is the operational stuff: how the whole database-and-device system has to behave, separate from the protocol messages themselves 🎀 This part is about what the system does, not just how messages look.
O.1🔌 The master device must be able to connect to the database, send it requests, and receive its responses and acknowledgments. The line has to be open, periodt 📞O.2📍 A master device MUST be able to figure out its location, including uncertainty and confidence level. A fixed master device may use a location that was programmed in at installation. Knowing where you are is literally everything 🗺️O.3⚖️ The master device MUST be configured to understand and follow the rule set of the regulatory body that applies to its operation at its location.O.4🚦 A master device MUST ask the database for available spectrum at a specified location before it starts transmitting in white space at that location. Look before you leap, bestie 👀O.5🧚 A master device MUST be able to ask the database for available spectrum on behalf of a slave device at a specified location, before that slave device starts transmitting in white space at that location. Doing it for your friends too 🫶O.6💌 The database MUST respond to an available spectrum request.
5.4. Guidelines
white-space tech is definitely going to keep growing 🌈 Stuff like coexistence, interference avoidance, spectrum brokering, and alternative spectrum bands might all show up later. So the data model and protocol should be ready for that evolution. Here are the guidelines to keep in mind while building them:
- 🧩 The data model SHOULD be modular, with messaging-specific, administrative-specific, and spectrum-specific parts split into separate modules. Organized closets are a vibe 🎀
- 🔀 The protocol SHOULD support working out which administrative-specific and spectrum-specific modules are being used.
6. Security Considerations 🔐💀
okay this is the serious part, so put on your focus face 😤 PAWS is a protocol where a master device asks for a schedule of available spectrum at its location (or at the locations of its slave devices) before it (or they) can operate on those frequencies. The info from the database has to be accurate and follow the applicable regulatory rules. BUT the database can't use the protocol to enforce that a client device only uses the spectrum it was given. Put plainly, devices can put energy into the air and cause interference without asking the database first 📡😬 So PAWS security considerations do NOT cover protection against malicious use of white-space spectrum. Sorry, that's just not what this protocol is for 🙅♀️
Here's the threat model for the PAWS protocol 🕵️♀️
Assumptions: The link between the master device and the database can be wired or wireless, and it provides IP connectivity. We assume an attacker has full access to the network medium between the master device and the database. The attacker may be able to eavesdrop on any communication between these two. Scary, I know 👻
Threat 1: User modifies a device to masquerade as another valid certified device 🎭 A master device tells the database who it is so it can get info about available spectrum. Without suitable protection mechanisms, devices can listen in on registration exchanges and later register with the database by pretending to be another device's identity. Identity theft, but make it radio 📻
Threat 2: Spoofed database 🪤 A master device tries to find a database (or databases) it can ask for available spectrum information. An attacker might spoof a database and send the master device malicious responses, which could make the master device cause interference to the primary user of the spectrum. Not it 😤
Threat 3: Modifying or jamming a query request 📵 An attacker may change or jam the query request that a master device sends to a database. The attacker might change the device's location or its capabilities (transmit power, antenna height, and so on). As a result, the database could respond with incorrect info about available spectrum or the maximum transmit power allowed. That could let the master device cause interference to the primary user of the spectrum. It could also cause a denial of service for the master device, if the modified database response says no channels are available to it, or if jamming stops the request from reaching the database at all. Ugh, rude 😒
Threat 4: Modifying or jamming a query response 🙃 An attacker may change or jam the query response that the database sends to a master device. For example, an attacker might alter the available spectrum or power-level info in the database response. Then the master device might use spectrum that isn't actually available at its location, or transmit at a higher power than allowed. That kind of unauthorized use can cause interference to the primary user of that spectrum. Or the attacker could alter a database response to say no spectrum is available at a location (or jam the response), which causes a denial of service for the master device. Villain arc 🦹♀️
Threat 5: Third-party tracking of white-space device location and identity 👀📍 A master device may include its identity along with its location in the query request. An eavesdropper could pick up that location and identity info and use it for unauthorized tracking. Stalker energy, absolutely not 🚫
Threat 6: Malicious individual acts as a database to terminate or unfairly limit spectrum access of devices 👑 A database may have a mechanism for revoking the service and spectrum allocated to a master device, by sending it a revoke message. A malicious user can pretend to be a database and send a revoke message to that device. That results in a denial of service for the master device. Who gave them the crown? 👑😤
The security requirements that come out of the threats above are captured in the requirements of Section 5.2. So go back and check those, bestie 🫶
7. Acknowledgments 🌷
The authors would like to thank Gabor Bajko, Teco Boot, Nancy Bravin, Rex Buddenberg, Vincent Chen, Gerald Chouinard, Stephen Farrell, Michael Fitch, Joel M. Halpern, Jussi Kahtava, Paul Lambert, Barry Leiba, Subramanian Moonesamy, Pete Resnick, Brian Rosen, Andy Sago, Peter Stanforth, John Stine, and Juan Carlos Zuniga for their contributions to this document. Team effort, iconic 🥹💖
8. References 📚
8.1. Normative References
[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. This is the one that defines the MUST and SHOULD words, so it's kind of the rulebook for the rulebook 📖✨[WGS84]National Imagery and Mapping Agency, "Department of Defense World Geodetic System 1984, Its Definition and Relationships with Local Geodetic Systems", NIMA TR8350.2 Third Edition Amendment 1, January 2000,<http://earth-info.nga.mil/GandG/publications/tr8350.2/wgs84fin.pdf>. 🌍
8.2. Informative References
[CRADIO]Cognitive Radio Technologies Proceeding (CRTP), "Federal Communications Commission", ET Docket No. 03-108, August 2010,<http://fcc.gov/oet/cognitiveradio>. 📻[PAWS]Chen, V., Ed., Das, S., Zhu, L., Malyar, J., and P. McCann, "Protocol to Access Spectrum Database", Work in Progress, May 2013. This one's still in progress, so keep an eye out 👀🦋
Authors' Addresses ✨
okay bestie, meet the people who made this doc happen 🫶
Anthony Mancuso (editor) 💅, the editor of the doc, rocking a Google address 🎀
Anthony Mancuso (editor)
Google
1600 Amphitheatre Parkway
Mountain View, CA 94043
US
EMail: amancuso@google.comScott Probasco 🌸, reachable at the address below 💜
Scott Probasco
EMail: scott@probasco.meBasavaraj Patil 🦋, over at Cisco Systems 🍓
Basavaraj Patil
Cisco Systems
2250 East President George Bush Highway
Richardson, TX 75082
US
EMail: basavpat@cisco.com📦 where this page comes from
- ietf: rfc6953 2013-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms