Subject: Re: [paws] Requirements

From: <[email-masked]>
Date: Wed, 12 Oct 2011 22:16:40 +0000

I forwarded the below initial list of requirements to the list a while ago, but there was no discussions on them. 
We got today a set of additional requirements from the 802.11af folks (see http://www.ietf.org/mail-archive/web/paws/current/msg00434.html). If there are no objections, I'd like to ask the Editor to include both these set of requirements to the new version of draft-ietf-paws-problem-stmt-usecases-rqmts-00.

- Gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley)
Sent: Friday, September 09, 2011 12:55 PM
To: [email-masked]
Subject: [paws] Requirements

Folks,

If you'll read this draft, you'll notice that section 6, the requirements section, is empty. During the Quebec meeting we agreed that these requirements will be reformulated and discussed on the list before including them onto the draft. I made a first attempt to reformulate the requirements and I'd like to post them to the list to start a discussion on them. There are lots of requirements still missing, so I'd welcome proposals for additional requirements, as well as comments to these requirements:

=====================================
Requirements

D. Data Model Requirements:

D.1: The Data Model MUST support specifying the antenna height parameter of the subject

D.2: The data model MUST support specifying an ID of the subject. This ID would be the ID of the device used to be certified by a regulatory body for a regulatory domain

D.3: The Data Model MUST support specifying the location of the subject and accuracy of location determination

D.4: The Data Model MUST support specifying a list of available channel list and time constrains for the channel list availability.

D.5: The Data Model MUST support specifying the maximum output power of the subject.

D.6: The Data Model MUST support specifying channel availability information for multiple locations.

D.7: The Data Model MUST support specifying channel availability information for an area around a specified location.

P. Protocol Requirements:

P.1: The protocol MUST provide a mechanism for the subject to discover the WS Database it has to use at a given location.

P.2: The protocol MUST support regulatory domain discovery.

P.3: The protocol between the master device and the WS Database MUST support pushing updates in channel availability changes to subjects 

P.4: The protocol between the master device and the WS Database MUST support mutual authentication and authorization.

P.5: The protocol between the master device and the WS Database MUST support integrity and confidentiality protection.

P.6: The protocol MUST support both username/password and digital certificates based authentication.

O. Operational Requirements:

O.1: A master device MUST query the WS Database for the available channels as often as required by the regulation (eg, FCC requires once per day) to verify that the operating 

channels continue to remain available.

O.2: A master device MUST determine its location with the accuracy required by the regulation (eg, FCC requires +/- 100m) before placing a query to the DB

O.3: A master device which changes its location during its operation, MUST query the WS Database for available operating channels each time it moves more than the distance 

specified by the regulation (eg FCC specifies 100m) from the location it previously made the query from.

O.4: 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.

O.5: 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.

O.6: A master device MUST be capable to validate the digital certificate of the WS Database.

O.7: A master device MUST be capable to check the validity of the WS Database certificate and whether it has been revoked or not.

==========================================================
-Gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Friday, September 09, 2011 10:08 AM
To: [email-masked]
Cc: [email-masked]
Subject: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol to Access WS database Working Group of the IETF.

	Title           : Protocol to Access White Space database: PS, use cases and rqmts
	Author(s)       : Scott Probasco
                          Gabor Bajko
                          Basavaraj Patil
                          Brian Rosen
	Filename        : draft-ietf-paws-problem-stmt-usecases-rqmts-00.txt
	Pages           : 25
	Date            : 2011-09-09

   Portions of the radio spectrum that are allocated to a licensed,
   primary user but are unused or unoccupied at specific locations and
   times are defined as &quot;white space&quot;.  The concept of allowing
   secondary transmissions (licensed or unlicensed) in white space is a
   technique to &quot;unlock&quot; existing spectrum for new use.  An obvious
   requirement is that these secondary transmissions do not interfere
   with the primary use of the spectrum.  One approach to using the
   white space spectrum at a given time and location is to verify with a
   database available channels.

   This document describes the concept of TV White Spaces.  It also
   describes the problems that need to be addressed for enabling the use
   of the primary user owned white space spectrum for secondary users,
   without causing interference, by querying a database which knows the
   channel availability at any given location and time.  A number of
   possible use cases of this spectrum and derived requirements are also
   described.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rqmts-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rqmts-00.txt
_______________________________________________
paws mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/paws

---

From: "Mody, Apurva (US SSA)" <[email-masked]>
Date: Fri, 28 Oct 2011 16:04:54 -0400

Dear Gabor and All the PAWS members,

Greetings.

The IEEE 802.22 Working Group has been discussing the requirements for the IETF PAWS and here is our feedback which can be found at the following URL.

https://mentor.ieee.org/802.22/dcn/11/22-11-0127-06-0000-ieee-802-22-inputs-to-ietf-paws.doc

The pdf version of the document has been attached to this e-mail, and for convenience, I am also putting this in a text format below:

Requirements

[AMENDED] D.1: The Data Model MUST support specifying the Following Parametersantenna height parameter of the subject
*       Antenna Parameters (Master WSD => database)
*       Height Parameters
o       mandatory AGL in meters: Unsigned INT, 2 Bytes (0 - 65,535 cm)

Example of the Primitive
Field: Antenna Height
Type: Integer
Length: 1 Byte
Description: Antenna height above ground level in meters

[Note: portable is defined as 1.5 m and base stations in Canada can be at up to 500 m HAAT which could be completely contributed by the antenna AGL (e.g., mounted on a broadcast tower). Two bytes are therefore necessary.]
[Note: our assumption is that the database will compute the HAAT in meters from the antenna AGL and ground elevation at the specified location (lat, long) obtained from a topographic database by the database server.]
*       Gain Parameters
o       Antenna directionality information in dB: relative to the main lobe maximum gain for every 5 degree azimuth clockwise starting from the direction of the maximum antenna gain expressed in unit of 0.25 dB over the range -63.75 dB (encoded 0x00) to 0 dB (0xFF):
Character String of 72 bytes
o       Antenna azimuth in degrees, clockwise from true North:  2 bytes INT

Example of the 802.22 Prmitive

Field: Antenna Information:
Type: Character String
Length: 72 Bytes
Description: Antenna directionality information of the device in dB relative to the main lobe maximum gain for every 5 degree azimuth clockwise starting from the direction of the maximum antenna gain expressed in unit of 0.25 dB over the range -63.75 dB (encoded 0x00) to 0 dB (0xFF). (to allow the database calculation of the channel availability and the maximum allowed EIRP values at the registering location19)

Field: Antenna Azimuth
Type: Integer
Length: 2 Bytes
Description: Antenna azimuth in degrees clockwise from true North

*       RF Mask Parameters (Master WSD => database)
o       Regulatory Domain (3 ASCII Letters), Device Type (Regulatory Class: e. g., Fixed, Personal/Portable, Mobile, etc.) (1 byte INT), Mask Number Index (2 byte INT) (where Mask Number Index corresponds to a particular RF Mask of an equipment that is stored in the database and that has passed the regulatory certification).
Example: 802.22 primitive:

Example of IEEE 802.22 Primitive

Field: Device Type
Type: Integer
Length: 1 Byte
Description: The value identifies the type of device at the geolocation registering
0x00 = Fixed base station
0x01 = Fixed CPE
0x02 = Personal/portable mode
0x03-0xFF = Reserved

[AMENDED] D.2: The data model MUST support specifying an ID of the subject. This ID would becontain the ID of the device used to bethat has been certified by a regulatory body for a its regulatory domain as well as an identification of the technology that is being used.   (Master WSD => database)

Example of IEEE 802.22 Primitive:

Field: Device Type
Type: Integer
Length: 1 Byte
Description: The value identifies the type of device at the geolocation registering
0x00 = Fixed base station
0x01 = Fixed CPE
0x02 = Personal/portable mode
0x03-0xFF = Reserved

Field: Device-ID Length
Type: Integer
Length: 2 Bytes
Description: Length of Device-ID field (# of characters)

Field: Device ID
Type: Character String
Length: Variable
Description: In US, this is FCC-ID

Field: Serial Number Length
Type: Integer
Length: 2 Bytes
Description: Length of Serial Number field (# of characters)

Field: Serial Number
Type: Character String
Length: Variable
Description: Serial Number of the Device

Note: The device-ID and Serial Number could be replaced by a universal identifier made of one or many parts .  The master WSD must also specify, as part of its registration process with the database, the technology that it uses (e.g., IEEE 802.22, IEEE 802.11af, etc.) (see requirement O.7).

[AMENDED] D.3: The Data Model MUST support specifying the location of the subjectWSD, the uncertainty in meters and confidence in percentage and accuracy of for the location determination. (Master WSD => database)

Field: Location Data String Length
Type: Integer
Length: 2 Bytes
Description: Length of Location Data String field (# of characters)

Field: Location Data String
Type: Character String
Length: NMEA 0183 Character String
Description: The value identifies the location of the device (latitude, longitude).20

Note: NMEA 0183 $GPGGA or $GPGLL String can carry latitude and longitude information. In the work of the IEEE 802.22 Working Group, it was assumed that the altitude of a geographic point would be derived at the database based on the latitude and longitude of the location of the WSD (see the note related to HAAT in D.1 above for which ground elevation information would need to be known). In 802.22 networks, the CPEs acquire their geolocation and transmit their latitude and longitude to the base station at the time of association. The base station would augment the location information defined in the NMEA string format with uncertainty (m) and confidence level (%) as the local regulator may want to define it.  These uncertainty and confidence values would be generated at the base station based, for example, on the technology used by the WSDs to acquire their geolocation.  The uncertainty could also be artificially increased to take into account the size of the area around a WSD where other WSD's not requiring geolocation (e.g., Mode I devices in the USA) would operate.

[AMENDED] D.4: The Data Model MUST support specifying a list of available channel along with the maximum EIRP (dBm) that can be accommodated list and time constraints for the channel list availability. (Database => Master WSD)

Field: Number of Channels Available
Type: Integer
Length: 1 Byte
Description: Number of TVWS Channels that are available
{If( Number of Channels Available > 0)

For (i=1; i≤ Number of Channels Available; i++)

Field: Max_EIRP and Channel Availability Schedule for Each Channel
Type: Vector of 2xN bytes and a number of pairs of NMEA 0183 $ZDA strings
Length: Variable
Description: List of available channel numbers and corresponding maximum allowed EIRP expressed in dBm over the range -64 dBm (encoded 0x00) to +63.5 dBm (encoded 0xFF) as well as the availability schedule (start and stop date/time) for each channel in Universal date and time system.

}
}

D.5: The Data Model MUST support specifying the maximum output power of
the subject. (See D.4 above. Also, specifying the "maximum output power" is not sufficient since it may or may not include the antenna gain. Specifying the EIRP is needed. D.5 should be deleted since it is proposed to be covered in D.4.)

[AMENDED] D.6: The Data Model MUST support specifying channel availability information for single and multiple locations. The database MUST also allow a master device to act as a proxy for other WSDs and query on their behalf. (Master WSD => Database)

In case of 802.22 systems which are to provide point-to-multipoint broadband access service primarily to rural areas, the BS acts as a proxy for all its associated CPEs and queries the database for each device. If a query is to be grouped or made in a batch mode, all the information related to each device shall be provided to the BS (i.e., the database is not to perform the intersection for all these devices and locations).

[Note: This option may be useful to 'batch' the database query process but it is not clear whether this would really increase the data transfer efficiency. In the case of the 802.22 WRAN systems, the base station will need to acquire all the information about the available channels for each of these CPEs (and the related maximum EIRP's) so that the operating channel and the backup channels (to which the WRAN cell will need to move if the current operating channel becomes unavailable to ensure a transparent channel move) can be determined locally from the best 'intersection' of these channels for all the associated CPEs.  This will allow database queries for only new CPEs coming on board or being moved, and constraints to be added locally at the base station to execute the 'intersection' process to produce the updated list of operational and backup channels that is to be transmitted to all CPEs for refreshing.

[DISAGREE] D.7: The Data Model MUST support specifying channel availability
information for an area around a specified location. (Database => Master WSD)

In our opinion, this can be done through the normal query process if a query to the database can be done with dummy device IDs, for example for planning purposes, and hence, we feel that this is not really needed. If a query is done to the database with dummy device ID, the database should not register these new devices and only provide the list of available channels. There should therefore be a need to identify whether the included device ID is a real one or not.

[NEW] D.8: The Data Model should support reporting to the database the channels that the master WSD has selected as the operating channel and the backup channels (see requirement O.7).

[AGREE] P.1: The protocol MUST provide a mechanism for the subject to discover
the WS Database it has to use at a given location.

[AGREE] P.2: The protocol MUST support regulatory domain discovery.

[AGREE] P.3: The protocol between the master device and the WS Database MUST
support the ability for the database to pushing updates in on channel availability changes to subjects.

[AGREE] P.4: The protocol between the master device and the WS Database MUST
support mutual authentication and authorization.

[AGREE] P.5: The protocol between the master device and the WS Database MUST
support integrity and confidentiality protection.

[AGREE]P.6: The protocol MUST support both username/password and digital
certificates based authentication.

[NEW] P.7: The protocol MUST require the master WSD to maintain contact with the database as specified by the local regulator as well as to specify and re-register its operating and backup channels with at least the same periodicity.

[AMENDED] O.1: A master device MUST query the WS Database for the available
channels as often as required by the regulation (e.g., FCC requires once
per day) to verify that the operating channels, and backup channels in the case of providing transparent switch-over, continue to remain available.

[AMENDED] O.2: A master device MUST determine its location with the accuracyalong with its uncertainty (e.g., FCC requires +/- 50m) and confidence level (e.g., 95%) and send it to the database so that the proper WSD position and buffer distance around the device can be added to make sure that the worst case situation required by the regulation (e.g., FCC requires +/- ) is considered in the distance calculations taking place at before placing aquery to the DB.

[AMENDED]  O.3: A master device which changes its location during its operation,
MUST query the WS Database for available operating channels each time
it moves more than the distance specified by the regulation (e.g., FCC specifies 100 m) from the location it occupied when it previously made the query from.

[AMENDED] O.4: The WS Database MUST provide the available channel list and the maximum EIRP corresponding to each channel when requested and MAY also provide time constraints for the each channel in the available list and maximum output power to the master device.

[AMENDED] O.5: A master device MUST be able to query the WS Database for itself as well as for its and include the FCC ID of the slave associated devices and compile the channel availability (and maximum EIRP thereof) so that a common channel  can be selected for use by all these WSDs to form a network. Furthermore, common channels may also need to be selected in a similar way to become backup channels to allow for network channel switch that would be transparent to the users in the query before allowing the slave device to
use the available channel.

[AMENDED] O.6: A master device MUST be capable to of validateing the digital
certificate of the WS Database and whether it has been revoked or not.

O.7: A master device MUST be capable to check the validity of the WS
Database certificate and whether it has been revoked or not.[Repeat, see O.6]

[NEW] O.7: The database must be capable of keeping track of the channels that are currently being utilized by the master devices and the technology that they use (e.g., IEEE 802.22, IEEE 802.11af, etc.).

If a request for the available channel is made by another master WSD from the same area and it is found that the new requesting master device technology cannot co-exist, then that channel should be removed from the available channels list going to this new device.  Unless the given master WSD fails to re-query within the specified contact period, the database should make that channel available. Accordingly, the protocol should provide the master WSDs with a means to release their operating channel when not needed.

Note that without an active channel management mechanism (e.g., 802.22 spectrum manager), it is unlikely that having the database just specifying which channels are available to protect incumbent services on a 24 hours cycle will be sufficient to allow for proper operation of multiple WSDs in an area without interference being caused among themselves. Without area specific centralized spectrum management that directs and juggles master WSD channel assignments virtually instantaneously, the result will be inefficient use of White Space spectrum.

Apurva N. Mody, Ph. D.

Chair, IEEE 802.22 Standard Working Group
Mobile: (404)-819-0314
E-mail: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, October 12, 2011 6:17 PM
To: [email-masked]
Subject: Re: [paws] Requirements

- Gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley)
Sent: Friday, September 09, 2011 12:55 PM
To: [email-masked]
Subject: [paws] Requirements

Folks,

device.

---

From: Peter McCann <[email-masked]>
Date: Fri, 28 Oct 2011 20:29:22 +0000

Hi, Apurva,

Mody, Apurva (US SSA) wrote:
> [NEW] O.7: The database must be capable of keeping track of the
> channels that are currently being utilized by the master devices and
> the technology that they use (e.g., IEEE 802.22, IEEE 802.11af, etc.).

I thought the point of whitespace operation was to enable experimental
uses, e.g., completely non-standard air interface technologies.  Do you
expect to enumerate the complete set of allowed technologies?  I don't
think it's possible and it raises all kinds of political questions.

> If a request for the available channel is made by another master WSD
> from the same area and it is found that the new requesting master
> device technology cannot co-exist, then that channel should be removed
> from the available channels list going to this new device.  Unless the
> given master WSD fails to re-query within the specified contact period,
> the database should make that channel available. Accordingly, the
> protocol should provide the master WSDs with a means to release their
> operating channel when not needed.
> 
> Note that without an active channel management mechanism (e.g., 802.22
> spectrum manager), it is unlikely that having the database just
> specifying which channels are available to protect incumbent services on
> a 24 hours cycle will be sufficient to allow for proper operation of
> multiple WSDs in an area without interference being caused among
> themselves. Without area specific centralized spectrum management that
> directs and juggles master WSD channel assignments virtually
> instantaneously, the result will be inefficient use of White Space
> spectrum.

I think the working group agreed that keeping any state in the database
was out of scope for this iteration of the charter items.

-Pete

---

From: "Mody, Apurva (US SSA)" <[email-masked]>
Date: Fri, 28 Oct 2011 16:36:18 -0400

Hello Peter, 

In our opinion, the database service can do much more than just providing the list of available channels. 

Especially now that spectrum sensing is no longer a requirement, how are we going to ensure co-existence between disparate technologies and efficient usage of spectrum? 

Why can' t we create a protocol that is flexible enough so that if some database service provider does want to solve the co-existence problem, they can. In our opinion, eliminating this possibility is too constraining for a technology of the future. 

Thanks

Apurva

Apurva N. Mody, Ph. D.

Chair, IEEE 802.22 Standard Working Group
BAE Systems 
Technology Solutions
130 Daniel Webster Highway, Mail Stop 2350
Merrimack, NH 03054
Work: (603)885 2621, Mobile: (603)-809-0459 
E-mail: [email-masked]

-----Original Message-----
From: Peter McCann [mailto:[email-masked]] 
Sent: Friday, October 28, 2011 4:29 PM
To: Mody, Apurva (US SSA); [email-masked]
Subject: RE: IEEE 802.22 Feedback on PAWS Requirements

Hi, Apurva,

-Pete

---

From: <[email-masked]>
Date: Fri, 28 Oct 2011 20:55:01 +0000

Since more people are bringing up this co-existence topic, I'll reserve some time in the Taipei session to discuss about its in_scope/out_of_scope issue.

-Gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Mody, Apurva (US SSA)
Sent: Friday, October 28, 2011 1:36 PM
To: Peter McCann; [email-masked]
Subject: Re: [paws] IEEE 802.22 Feedback on PAWS Requirements

Hello Peter, 

Thanks

Apurva

Apurva N. Mody, Ph. D.

Chair, IEEE 802.22 Standard Working Group BAE Systems Technology Solutions
130 Daniel Webster Highway, Mail Stop 2350 Merrimack, NH 03054
Work: (603)885 2621, Mobile: (603)-809-0459
E-mail: [email-masked]

-----Original Message-----
From: Peter McCann [mailto:[email-masked]]
Sent: Friday, October 28, 2011 4:29 PM
To: Mody, Apurva (US SSA); [email-masked]
Subject: RE: IEEE 802.22 Feedback on PAWS Requirements

Hi, Apurva,

> the technology that they use (e.g., IEEE 802.22, IEEE 802.11af, etc.).

I thought the point of whitespace operation was to enable experimental uses, e.g., completely non-standard air interface technologies.  Do you expect to enumerate the complete set of allowed technologies?  I don't think it's possible and it raises all kinds of political questions.

> given master WSD fails to re-query within the specified contact 
> period, the database should make that channel available. Accordingly, 
> the protocol should provide the master WSDs with a means to release 
> their operating channel when not needed.
> 
> specifying which channels are available to protect incumbent services 
> on a 24 hours cycle will be sufficient to allow for proper operation 
> of multiple WSDs in an area without interference being caused among 

I think the working group agreed that keeping any state in the database was out of scope for this iteration of the charter items.

-Pete

---

From: Paul Lambert <[email-masked]>
Date: Fri, 28 Oct 2011 17:06:35 -0700

Hi Apurva,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Mody, Apurva (US SSA)
...
> Hello Peter,
> 
> In our opinion, the database service can do much more than just
> providing the list of available channels.
> 
> Especially now that spectrum sensing is no longer a requirement, how
> are we going to ensure co-existence between disparate technologies and
> efficient usage of spectrum?

Googling, I can see an example of your notion of a cognitive radio with sensing and co-existence:
	http://tinyurl.com/3r3ouy7  
However, I do not see why this should be in scope.  This group will be successful if it solves the more narrow problem of just getting the regulatory allowed channels.

While sending channels for coexistence looks like a similar protocol and may use many of the same fields, it has a variety of other complexities that we should avoid.  Specifically:
1) The authentication range of the security is very different for a known regulatory authority versus a recommendation for "co-existence" that may come from another third party.  Coexistence is typically a more local issue and really cannot be bundled in the same authenticated spectral entitlements.  Also - our requirement is to support unlicensed radio, which means it's rally difficult to securely determine who should pay attention to a specific coexistence service.
2) It greatly complicates the database.  As Peter points out - we do not want to have to support this type of stateful behavior.
3) Radio link layer protocols already handle many sensing and detection mechanisms necessary for this type of functionality (802.11v measurements 802.22 coexistance, etc).

So - this group should "just say no" to the whole co-existence quagmire.  It's not necessary for our work and only takes up the bandwidth of this group.  Humm - maybe we should consider it a channel of discussion that is not available :-) 

Paul

> 
> Why can' t we create a protocol that is flexible enough so that if some
> database service provider does want to solve the co-existence problem,
> they can. In our opinion, eliminating this possibility is too
> constraining for a technology of the future.
> 
> Thanks
> 
> Apurva
> 
> 
> Apurva N. Mody, Ph. D.
> 
> period,
> on

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 29 Oct 2011 01:23:52 -0400

There is no question that a service can provide more than just the 
regulatory information.
The service to provide that may or may not be the same service as the 
one that provides the regulatory information.

And more importantly, as Paul observed, we had agreed to focus on 
solving the small problem first.  For the IETF< this has been found to 
be a (arguably the) path to success.  So we should deliver the query / 
response protocol for the regulatory information, and after that is done 
we can entertain other ideas for what can/should/must be done.

Yours,
Joel