PAWS Database Discovery

In PAWS protocol, the master device queries the database for available spectrum, but the device MUST determine the URI for the database before it can send any PAWS messages. The URI of database can be pre-configured manually in the device before it sends any PAWS messages, for example, the owner of the device can configure the URI when he/she wants to use the master device in certain area. This method needs the owner of the device to know the available database that can be used in the regulatory domain. The URI of database can also be obtained by a dynamic discovery process, and this is where this document focuses. Before the device sends any PAWS messages to the database, it first starts a Database Discovery Procedure to retrieve the available database(s) and applicable regulatory domain information. This document provides an optional method for the master device to find an available WSDB. In discovery procedure, the URI for the database SHOULD be obtained from an authorized and authenticated entity. The master device provides its current geo-location information to the entity in Database Discovery Request message, and the entity will return a list of available databases and the regulatory body that has jurisdiction over the master device's location. When the master device gets the information about available database and regulatory body, it can choose the proper database for querying white space spectrum by PAWS procedures. The database discovery mechanism is based on LoST protocol RFC5222.

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 RFC2119. The terminology from PAWS: problem statement, use cases and requirements PAWS RQMTS is applicable to this document. White Space Database (WSDB) In the context of white space and cognitive radio technologies, the database is an entity which contains, but is not limited to, current information as required by the regulatory policies about available spectrum at any given location and time, and other types of related (to the white space spectrum) or relevant information. White Space Database Discovery Server (WSDB DS) A server function provided to a white space device, the client. The white space device contacts a white space database discovery server to receive the service of discovering or identifying one or more white space databases. The white space database discovery server is a known entity to the white space device, which knows at least a useable internet address for the white space database discovery server. The white space database discovery server takes as input positioning information from the white space device and returns both address information which allows the white space device to contact a trusted, regulatory-authorized white space database, suitable for service at the white space device's current location and indication of the regulatory domain governing at the white space device's current location. A single white space database discovery server may have global scope, serving clients located globally. Service boundary A service boundary circumscribes the region within which all locations map to the same service URI or set of URIs for a given service. A service boundary may consist of several non-contiguous geometric shapes. Mapping Mapping is a process that takes a location and a service identifier as inputs and returns one or more URIs. Those URIs can point either to a host providing that service or to a host that in turn routes the request to the final destination.

Before the WSD can query a trusted WSDB for a list of available frequencies or channels for use in the white space spectrum, the WSD must first discover the available databases and addresses serving the regulatory domain in which the device is currently located. At power-up the WSD does not reliably know the regulatory domain corresponding to its current location, and therefore does not reliably know with which white space database(s) it can communicate. Furthermore it is essential that the WSD connect with a trusted WSDB for proper operation and indeed regulatory compliance. While it is possible that a WSD knows its location, or information which may be used to derive its location, it is not reasonable for every WSD to be capable to translate this information into the current regulatory domain, i.e. the WSD needs assistance to know what is the regulatory environment with jurisdiction at its current location. A WSDB Discovery Server (DS) takes as input location information from the WSD and returns to the WSD one or more addresses of WSDBs (or WSDB listing servers as appropriate) to the WSD. If the address or addresses of these WSDB DSs are included in the WSD firmware, a secure starting point for a trusted relationship is established. Figure 1 shows at a high level how white space master devices discover a suitable trusted white space database. In this document we describe how the master device may collect the addresses of one or more white space database. Steps and criteria to sort multiple addresses into a priority order is left to implementation and not specified. Procedures to contact a white space database are specified in PAWS PROTOCOL. Steps and criteria to determine the suitability of a particular white space database are also not considered in this document.

| | | | +-----------------------+ | | contact top priority | ---- | database to determine | | suitability for | | service | +-----------------------+ | | end ]]> After master device has selected a suitable database for service, it can then use the PAWS protocol PAWS PROTOCOL to retrieve the available spectrum for its location. An overview of procedures of how master device gets available spectrum from WSDB is depicted in Figure 2.

| | | | | | Discovery Response | | | (address information, etc) | | |<---------------------------| | | | | | | | | /--------------------------|-----------------------\ | |/ channel request | \| |\ channel response | (PAWS) /| | \--------------------------|-----------------------/ | | | | | | | ]]> (1) Discovery Request procedure. This message is used by master device to query available WSDB from WSDB DS; it conveys master's location and some other related information to WSDB DS. (2) Discovery Response procedure. This procedure conveys the regulatory domain and either the address of a listing server or the address of one or more WSDB authorized to provide service where the WSD is physically located to the master device. If spectrum access is not authorized at the WSD physical location, the response will contain an error code and no address information. After WSDB discovery procedure, the master device can query available white space spectrum from the WSDB using PAWS protocol.

The discovery system is based on client-server model; the basic model is shown as Figure 3, where WSDB DB plays the role of server.

| WSDB DS | +----------+ +----------+ ]]> For the discovery mechanism to work well, some assumptions have to be considered: (1) Master device can get its geo-location directly or indirectly. (2) Master device has gotten the URL (or IP address) of a trusted WSDB DS before starting the discovery procedure. By including contact information of a trusted WSDB DS in the WSD's programmed instructions or firmware, the WSD can reliably determine the address of a trusted database listing server, as appropriate for its current physical location. Because the WSDB DS is selected by the WSD manufacturer, a foundation is set to ensure the WSD will be able to discover a trusted WSDB in every regulatory domain where the manufacturer expects the WSD to be used. The address of at least one WSDB DS is included in the WSD operating instructions or firmware by the manufacturer for example or provisioned using device configuration mechanisms. When the WSD does not have the address of a serviceable WSDB (e.g. at power-up), the WSD sends a Discovery Request message to a WSDB DS. The WSD includes in the Discovery Request information about its current location. The WSDB DS uses this location information to determine the regulatory domain where the WSD is located, and returns a Discovery Response message which includes the address of one or more WSDBs (or WSDB listing server as appropriate) to the WSD.

LoST (Location to Service Translation Protocol) is a protocol for mapping a service identifier (URN) and location information to one or more service URLs and associated information. LoST mapping queries can contain either civic or geodetic location information. LoST queries can be resolved recursively or iteratively. LoST messages are carried in HTTP and HTTPS protocol exchanges, facilitating use of TLS for protecting the integrity and confidentiality of requests and responses. This discovery mechanism utilizes LoST to communicate between master device and WSDB DS, the master device acts as LoST client and WSDB DS plays the role of LoST server. The protocol stack is shown in Figure 4. To use LoST for this discovery mechanism, several issues have to be clarified.

A new service identifier for PAWS database discovery needs to be defined, according to RFC5031, a top-level service and a sub-service are defined here. Service Description paws top-level service of PAWS paws.discovery the PAWS database discovery service So according to the service-identifying labels defined above, the service URN for PAWS database discovery service is as follow: urn:service:paws.discovery

The name of regulatory domain can be conveyed using ]]> element in the LoST response message. [Note: the format and content of the regulatory domain information are TBD.]

The discovery request procedure uses the ]]> query message of LoST for conveying parameters. Master device's location information will be included in the ]]> element. The service identifier defined in section 5.1.1 is specified in the ]]>element. The following is an example of discovery request procedure message, using geodetic coordinates.

37.775 -122.422 urn:service:paws.discovery ]]>

The discovery response procedure uses the ]]> response message of LoST for conveying parameters. After receiving the ]]> query message, the WSDB DS will map the location information and service identifier to one or more available WSDBs' URL. Then in the ]]>message, a list of WSDBs' URL and regulatory domain that has jurisdiction over the current location will be conveyed to master device. The regulatory domain is contained in ]]> element. The service boundary of the WSDB can also be included in the response message to indicate the region for which the service URL returned would be the same as in the actual query. Or a service boundary reference can be returned to master device, and master device retrieve service boundary by this reference as needed. Next time when the master device powers up, if its location is within the service boundary it then may use the WSDB retrieved before. An example of discovery response procedure message is shown as follow:

Federal Communications Commission urn:service:paws.discovery 37.775 -122.4194 37.555 -122.4194 37.555 -122.4264 37.775 -122.4264 37.775 -122.4194 database1.example1.com database2.example2.com ]]>

If the WSDB DS can not provide available WSDB for master device, then it may wish other WSDB DS to serve the master device's query request. In LoST, recursion and iteration patterns are provided for this purpose. In recursive mode, the LoST server initiates queries on behalf of the requester and returns the result to the requester. In iterative mode, the server contacted returns a redirection response indicating the next server to be queried if the server contacted cannot provide an answer itself.

TBD.

Registration of service URN for PAWS database discovery service. Service Description paws top-level service of PAWS paws.discovery the PAWS database discovery service

Thanks to my colleagues for their sincerely help and comments when drafting this document.