Subject: [paws] updated charter

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 02 Jun 2011 20:26:52 -0600

Here is the charter the emerged from discussions among IESG members and
with the BoF chairs.

###

Protocol to Access White Space database (paws)
------------------------------------------------
Current Status: Proposed Working Group
Last updated: 2011-06-02

Chairs:
TBD

Applications Area Directors:
    Pete Resnick <[email-masked]>
    Peter Saint-Andre <[email-masked]>

Applications Area Advisor:
    Peter Saint-Andre <[email-masked]>

Mailing lists:
    General Discussion: [email-masked]
    To Subscribe: https://www.ietf.org/mailman/listinfo/paws
    Archive: http://www.ietf.org/mail-archive/web/paws/

Description of Working Group:

Background

Radio spectrum is a limited resource.  National and international
bodies assign different frequencies for specific uses, and in
most cases license the rights to use these frequencies.  Locally
unused spectrum is commonly called "white space" and may be made
available to other services on a basis of non-interference with
the primary user of the frequencies concerned (if any). This
technique can help "unlock" existing spectrum, for example to
enable the wireless communications industry to provide more
services over frequencies associated with unused television
channels.  An obvious requirement is that white space uses must
not interfere with the primary use of the spectrum.  This is
achieved through spatial and/or temporal separation of the
primary user and whitespace user with due consideration made to
the radio characteristics of the two uses.

Problem Statement

The fundamental problem is enabling a radio device to determine, in
a specific location and at specific time, if any white space is
available for secondary use.  There are two parties to such an
interaction:

1. A database containing records about the protected contours (in
space and time) of primary spectrum users.  Typically, such databases
will be populated and operated by the appropriate spectrum regulation
bodies in a given locale.

2. A radio device that wishes to query such a database. Typically, the
the nature of the query will depend on the needs of the device.

The contents of white space databases, and the needs of radio devices,
are being defined elsewhere.  However, these parties need a protocol
for communication that will enable radio devices to find out what white
space is available at a given time in a given location.

It is expected that white space databases will be reachable via the
Internet, and that radio devices too will have some form of Internet
connectivity, directly or indirectly.  Therefore, it is appropriate
to define an Internet-based protocol for querying white space databases
and receiving responses from such databases.

In rough outline, such a protocol would enable a radio device that
knows its location to complete the following tasks:

1. Determine the relevant white space database to query.

2. Connect to the database using a well-defined access method.

3. Provide its geolocation and perhaps other data to the database
   using a well-defined wire format for querying the database.

4. Receive in return a list of currently available white space
   using a well-defined wire format for returning information.

Once the device learns of the available white space (e.g., in a TV
white space implementation, the list of available channels at that
location), it can then select one of the bands from the list and
begin to transmit and receive on the selected band.  If the device's
parameters have changed (e.g., if some amount of time has passed or if
the device has changed location beyond a specified threshold), it might
need to query the database again to determine what white space is still
available.

Objectives

The overall goals of this working group are to:

1. Standardize a mechanism for discovering a white space database.

2. Standardize a method for accessing a white space database.

3. Standardize wire formats to be carried over the database
access method (i.e., formats for queries and responses).

4. Ensure that the discovery mechanism, database access method,
and wire formats have appropriate security levels in place.

By "standardize" is not meant that the working group will necessarily
develop new technologies.  In completing its work, the group will:

- Evaluate existing discovery mechanisms to determine if one of
  them provides the necessary application features and security
  properties (or can be extended to do so) for discovering a
  white space database.  Examples might include DNS.

- Evaluate existing application-layer transport protocols to
  determine if one of them provides the necessary application
  features and security properties (or can be extended to do so)
  for use as a building block for communication between location-
  aware devices and white space databases.  If such a method
  exists, the group will reuse it; if not, the group will develop
  one.  Examples might include HTTP.

- Develop a method for querying a white space database.  Such
  a method will utilize, so far as possible, the features of
  the application-layer transport protocol and not re-implement
  them in the new protocol. It will include mechanisms to verify
  that the requests and responses come from authorized sources,
  and that they have not been modified in transit.  Examples might
  include LDAP.

- Define extensible wire formats for both location-specific queries
  and location-specific responses for interaction with radio white
  space databases.  The group will consider whether existing data
  formats can be reused.

The protocol must protect both the channel enablement process and the
privacy of users.  Robust privacy and security mechanisms are needed
to prevent: device identity spoofing, modification of device requests,
modification of channel enablement information, impersonation of
registered database services, and unauthorized disclosure of a device's
location.  The group will consider whether existing privacy and
security mechanisms can be reused.

The task of defining the structure and contents of the databases
themselves is out of scope.  The group will standardize wire formats
for communication between devices and databases, but not the information
models for the databases, since those models are likely to be
country-specific or application-specific.  In addition, the particular
data exchanged between a device and a database might depend on the
ranges of radio spectrum that are to be used, the requirements of the
database operators and their governing regulations, and other factors.
Therefore, the database access method and the query/response data
formats that are exchanged using that method need to be designed for
extensibility rather than being tied to any specific spectrum, country,
or phy/mac/air interface.  For example, the working group should define
extension points for the database access method and the wire formats
that are used to query a database and respond to queries, so that use
cases other than those currently envisioned can be addressed in the
future if a community of interest wishes to do so.  However, the
access method and wire formats will incorporate relevant aspects of
the parameters needed for the currently envisioned use cases to ensure
proper operation.

In accordance with existing IETF processes, the group will communicate
and invite participation with other relevant standards bodies and
groups, and if necessary reuse existing liaison relationships or
request the establishment of new liaison relationships, including but
not limited to IEEE 802.11af and IEEE 802.22.  In order to ensure that
it takes into account a broad range of possible use cases and
requirements, the group should also reach out to other potential
"customers" for a white space database access method and consider input
from regulatory entities that are involved in the specification of the
rules for secondary use of spectrum in specific radio bands.

Deliverables

1. A description of the relevant use cases and requirements.  This
document shall be Informational.  Subject to working group consensus,
draft-probasco-paws-overview-usecases and draft-patil-paws-problem-stmt
might be used as a starting point.

2. A specification of the mechanism for discovering a white space
database, the method for accessing a white space database, and the
wire format for querying and receiving responses from a white space
database.  This document shall be Standards Track.

Milestones

Oct 2011 Submit 'Use Cases and Requirements for Accessing a Radio White
Space Database' to the IESG for publication as Informational

Apr 2012 Submit 'Accessing a Radio White Space Database' to the IESG
for publication as Proposed Standard

###

---

From: Orit Levin <[email-masked]>
Date: Fri, 3 Jun 2011 20:12:50 +0000

A few more comments:

1. In all (nine) places where "wire format" is used, a more appropriate "protocol format" should probably be used. In any case, in reality many times it will happen over the air and not on the wire.

2. More seriously, the statement "[t]ypically, such databases will be populated and operated by the appropriate spectrum regulation bodies in a given locale" should be removed. It is not necessary, is inaccurate, and prejudges a regulatory outcome: the U.S., for example, is permitting private entities to serve as white space database administrators; the UK has proposed the same.

Thanks,
Orit.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
Sent: Thursday, June 02, 2011 7:27 PM
To: [email-masked]
Subject: [paws] updated charter

Here is the charter the emerged from discussions among IESG members and with the BoF chairs.

###

Chairs:
TBD

Mailing lists:

Background

Radio spectrum is a limited resource.  National and international bodies assign different frequencies for specific uses, and in most cases license the rights to use these frequencies.  Locally unused spectrum is commonly called "white space" and may be made available to other services on a basis of non-interference with the primary user of the frequencies concerned (if any). This technique can help "unlock" existing spectrum, for example to enable the wireless communications industry to provide more services over frequencies associated with unused television channels.  An obvious requirement is that white space uses must not interfere with the primary use of the spectrum.  This is achieved through spatial and/or temporal separation of the primary user and whitespace user with due consideration made to the radio characteristics of the two uses.

Problem Statement

The fundamental problem is enabling a radio device to determine, in a specific location and at specific time, if any white space is available for secondary use.  There are two parties to such an
interaction:

1. A database containing records about the protected contours (in space and time) of primary spectrum users.  Typically, such databases will be populated and operated by the appropriate spectrum regulation bodies in a given locale.

2. A radio device that wishes to query such a database. Typically, the the nature of the query will depend on the needs of the device.

The contents of white space databases, and the needs of radio devices, are being defined elsewhere.  However, these parties need a protocol for communication that will enable radio devices to find out what white space is available at a given time in a given location.

It is expected that white space databases will be reachable via the Internet, and that radio devices too will have some form of Internet connectivity, directly or indirectly.  Therefore, it is appropriate to define an Internet-based protocol for querying white space databases and receiving responses from such databases.

In rough outline, such a protocol would enable a radio device that knows its location to complete the following tasks:

Once the device learns of the available white space (e.g., in a TV white space implementation, the list of available channels at that location), it can then select one of the bands from the list and begin to transmit and receive on the selected band.  If the device's parameters have changed (e.g., if some amount of time has passed or if the device has changed location beyond a specified threshold), it might need to query the database again to determine what white space is still available.

Objectives

3. Standardize wire formats to be carried over the database access method (i.e., formats for queries and responses).

4. Ensure that the discovery mechanism, database access method, and wire formats have appropriate security levels in place.

By "standardize" is not meant that the working group will necessarily develop new technologies.  In completing its work, the group will:

The protocol must protect both the channel enablement process and the privacy of users.  Robust privacy and security mechanisms are needed to prevent: device identity spoofing, modification of device requests, modification of channel enablement information, impersonation of registered database services, and unauthorized disclosure of a device's location.  The group will consider whether existing privacy and security mechanisms can be reused.

The task of defining the structure and contents of the databases themselves is out of scope.  The group will standardize wire formats for communication between devices and databases, but not the information models for the databases, since those models are likely to be country-specific or application-specific.  In addition, the particular data exchanged between a device and a database might depend on the ranges of radio spectrum that are to be used, the requirements of the database operators and their governing regulations, and other factors.
Therefore, the database access method and the query/response data formats that are exchanged using that method need to be designed for extensibility rather than being tied to any specific spectrum, country, or phy/mac/air interface.  For example, the working group should define extension points for the database access method and the wire formats that are used to query a database and respond to queries, so that use cases other than those currently envisioned can be addressed in the future if a community of interest wishes to do so.  However, the access method and wire formats will incorporate relevant aspects of the parameters needed for the currently envisioned use cases to ensure proper operation.

In accordance with existing IETF processes, the group will communicate and invite participation with other relevant standards bodies and groups, and if necessary reuse existing liaison relationships or request the establishment of new liaison relationships, including but not limited to IEEE 802.11af and IEEE 802.22.  In order to ensure that it takes into account a broad range of possible use cases and requirements, the group should also reach out to other potential "customers" for a white space database access method and consider input from regulatory entities that are involved in the specification of the rules for secondary use of spectrum in specific radio bands.

Deliverables

1. A description of the relevant use cases and requirements.  This document shall be Informational.  Subject to working group consensus, draft-probasco-paws-overview-usecases and draft-patil-paws-problem-stmt might be used as a starting point.

2. A specification of the mechanism for discovering a white space database, the method for accessing a white space database, and the wire format for querying and receiving responses from a white space database.  This document shall be Standards Track.

Milestones

Oct 2011 Submit 'Use Cases and Requirements for Accessing a Radio White Space Database' to the IESG for publication as Informational

Apr 2012 Submit 'Accessing a Radio White Space Database' to the IESG for publication as Proposed Standard

###

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 03 Jun 2011 14:18:25 -0600

On 6/3/11 2:12 PM, Orit Levin wrote:
> A few more comments:
> 
> 1. In all (nine) places where "wire format" is used, a more
> appropriate "protocol format" should probably be used. In any case,
> in reality many times it will happen over the air and not on the
> wire.

By "wire format" we don't mean literally sending things over a wire, in
contrast to data that is send over a wireless transport. :)

> 2. More seriously, the statement "[t]ypically, such databases will be
> populated and operated by the appropriate spectrum regulation bodies
> in a given locale" should be removed. It is not necessary, is
> inaccurate, and prejudges a regulatory outcome: the U.S., for
> example, is permitting private entities to serve as white space
> database administrators; the UK has proposed the same.

Someone pinged me about that off-list and I proposed changing it to:

   1. A database containing records about the protected contours (in
   space and time) of primary spectrum users.  Typically, such databases
    will be populated by information provided by the appropriate
   spectrum regulation bodies and by spectrum licensees.

It is important to retain a statement about the provenance of the data,
so that everyone is clear it is out of scope for this WG.

/psa

---

From: Orit Levin <[email-masked]>
Date: Sat, 4 Jun 2011 05:06:36 +0000

Thanks Peter!
Please, see inline,
Orit.

> From: Peter Saint-Andre [mailto:[email-masked]]
> Sent: Friday, June 03, 2011 1:18 PM
> To: Orit Levin
> Cc: [email-masked]
> Subject: Re: [paws] updated charter
> 
Of course not! It is just hilarious to see this expression being used today in the wireless context. Also, it may be confusing to those who are not SW developers and have not spent past decades implementing network protocols and/or APIs.

> so that everyone is clear it is out of scope for this WG.
Yes, this is more accurate and conveys the important point much better.

---

From: "M.K.Sajeev sajeev" <[email-masked]>
Date: Sat, 4 Jun 2011 03:27:15 -0700 (PDT)

Hi,

This is Sajeev, interested in whitespace protocols, and an observer of this group. Reading through the charter I would like to clarify the following.
In the below paragraph radio device discovers whitespace channel availability time to time. What happens when the radio device does not find any channels available to initiate transmission, or if it happen during a session? Will the communication be broken, or the radio devices use this as a secondary means of communication? Would like to get some clarity..

Sajeev Manikkoth
Mobile: +919663311378
Email: [email-masked]
http://www.linkedin.com/in/mksajeev

________________________________
From: Peter Saint-Andre <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: Friday, 3 June 2011, 7:56
Subject: [paws] updated charter

###

Chairs:
TBD

Mailing lists:

Background

Problem Statement

Objectives

Deliverables

Milestones

###

_______________________________________________
paws mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/paws

---

From: <[email-masked]>
Date: Mon, 6 Jun 2011 09:31:22 +0000

Hi Sajeev,

If the database replies with an empty channel list (no channels available) then the white space radio must not transmit.

Once a channel list is received with at least one available channel, the white space radio may transmit on one of the available channels. Typically, the white space radio must contact the database regularly to ensure channel availability. If the white space radio is not able to contact the database, then the radio must cease transmission in white space within some period of time. The specific details are specified by the local regulator (e.g. FCC in the US, Ofcom in the UK, etc).

The white space communication will ultimately be broken if contact with the database is lost. Your question about using white space as a secondary means of communication is a reasonable question, but beyond the scope of the database interface. For example, a device may use cellular radio, WiFi and white space radios, switching radios based on some arbitrary decisions (such as power consumption, QoS, subscription rate, etc). However this type of switching scenario is beyond the scope of the database interface and therefore PAWS.

IMHO, these are good questions about typical system operation, but have no impact to the charter text.

Regards,

Scott

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext M.K.Sajeev sajeev
Sent: Saturday, June 04, 2011 5:27 AM
To: Peter Saint-Andre; [email-masked]
Subject: Re: [paws] updated charter

Hi,

Sajeev Manikkoth
Mobile: +919663311378

Email: [email-masked]<mailto:[email-masked]>
http://www.linkedin.com/in/mksajeev

  _____

###

Chairs:
TBD

Applications Area Directors:
    Pete Resnick <[email-masked]<mailto:[email-masked]>>
    Peter Saint-Andre <[email-masked]<mailto:[email-masked]>>

Applications Area Advisor:
    Peter Saint-Andre <[email-masked]<mailto:[email-masked]>>

Mailing lists:
    General Discussion: [email-masked]<mailto:[email-masked]>
    To Subscribe: https://www.ietf.org/mailman/listinfo/paws
    Archive: http://www.ietf.org/mail-archive/web/paws/

Background

Problem Statement

Objectives

Deliverables

Milestones

###

_______________________________________________
paws mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/paws

---

From: "Barlow Keener" <[email-masked]>
Date: Mon, 6 Jun 2011 08:03:18 -0400

Scott,

I think this presents a good question about WS PAWS:

Q "If the database replies with an empty channel list (no channels available) then the white
space radio must not transmit."

I have wondered about this question because if the WS radio attempts to "contact" the database
in order to determine what spectrum/channels are unlicensed in a particular geographical area
- by going through or sending out a transmit signal on the various spectrum/channels that are
"possible" WS channels to use in all geographies, then by definition the WS radio will
"interfere" by using this transmit signal with other licensed spectrum/channels.  Correct?

How is this problem solved?  It is defined in PAWS almost as a question but not answered - at
least that is my view.

Thanks!

Barlow

Barlow Keener

617-671-1202

Barlow Keener | Attorney | Keener Law Group <http://www.keenerlawgroup.com/>  
Internet and telecommunications law

d: 617.671.1202 | m: 781-858-1588 | [email-masked]
Follow me on Twitter http://twitter.com/barlow <http://www.twitter.com/barlow>  | LinkedIn
http://www.linkedin.com/in/barlowkeener  | Blog: www.whydom.com <http://www.whydom.com/>  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, June 06, 2011 5:31 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [paws] updated charter

Hi Sajeev,

If the database replies with an empty channel list (no channels available) then the white space
radio must not transmit.

Once a channel list is received with at least one available channel, the white space radio may
transmit on one of the available channels. Typically, the white space radio must contact the
database regularly to ensure channel availability. If the white space radio is not able to
contact the database, then the radio must cease transmission in white space within some period
of time. The specific details are specified by the local regulator (e.g. FCC in the US, Ofcom
in the UK, etc). 

The white space communication will ultimately be broken if contact with the database is lost.
Your question about using white space as a secondary means of communication is a reasonable
question, but beyond the scope of the database interface. For example, a device may use
cellular radio, WiFi and white space radios, switching radios based on some arbitrary decisions
(such as power consumption, QoS, subscription rate, etc). However this type of switching
scenario is beyond the scope of the database interface and therefore PAWS.

IMHO, these are good questions about typical system operation, but have no impact to the
charter text.

Regards,

Scott

Hi,

This is Sajeev, interested in whitespace protocols, and an observer of this group. Reading
through the charter I would like to clarify the following.

In the below paragraph radio device discovers whitespace channel availability time to time.
What happens when the radio device does not find any channels available to initiate
transmission, or if it happen during a session? Will the communication be broken, or the radio
devices use this as a secondary means of communication? Would like to get some clarity..

Sajeev Manikkoth
Mobile: +919663311378

Email: [email-masked]

  _____  

###

Chairs:
TBD

Mailing lists:

Background

Problem Statement

Objectives

Deliverables

Milestones

###

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 6 Jun 2011 08:56:14 -0400

There are several strategies that can be used.  One end has to have an independent Internet access mechanism.  It can determine what channels it, and it's "clients" can use and broadcast them, or use one channel as a beacon, allow the clients to access it on the beacon channel, and then assign a channel to the client.  There are other strategies.

Brian

On Jun 6, 2011, at 8:03 AM, Barlow Keener wrote:

Scott,

Q “If the database replies with an empty channel list (no channels available) then the white space radio must not transmit.”

I have wondered about this question because if the WS radio attempts to “contact” the database in order to determine what spectrum/channels are unlicensed in a particular geographical area  – by going through or sending out a transmit signal on the various spectrum/channels that are “possible” WS channels to use in all geographies, then by definition the WS radio will “interfere” by using this transmit signal with other licensed spectrum/channels.  Correct?

How is this problem solved?  It is defined in PAWS almost as a question but not answered – at least that is my view.

Thanks!

Barlow

Barlow Keener
617-671-1202

Barlow Keener | Attorney | Keener Law Group<http://www.keenerlawgroup.com/>
Internet and telecommunications law

d: 617.671.1202 | m: 781-858-1588 | [email-masked]<mailto:[email-masked]>
Follow me on Twitter http://twitter.com/barlow<http://www.twitter.com/barlow> | LinkedIn http://www.linkedin.com/in/barlowkeener  | Blog: www.whydom.com<http://www.whydom.com/>

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, June 06, 2011 5:31 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] updated charter

Hi Sajeev,

Regards,
Scott

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of ext M.K.Sajeev sajeev
Sent: Saturday, June 04, 2011 5:27 AM
To: Peter Saint-Andre; [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] updated charter

Hi,

Sajeev Manikkoth
Mobile: +919663311378
Email: [email-masked]<mailto:[email-masked]>
http://www.linkedin.com/in/mksajeev
________________________________
From: Peter Saint-Andre <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Friday, 3 June 2011, 7:56
Subject: [paws] updated charter

###

Chairs:
TBD

Mailing lists:

Background

Problem Statement

Objectives

Deliverables

Milestones

###

<ATT00001..txt>

---

From: Gerald Chouinard <[email-masked]>
Date: Mon, 06 Jun 2011 09:41:17 -0400

All,

This is an interesting discussion that we had in the IEEE 802.22 when we 
realized this conundrum when a customer premise equipment (CPE) tries to 
contact a base station (BS) that it has discovered in its area. The BS may 
be able to operate because the field strength that it produces is low 
enough to avoid interference to the nearby DTV operation.  However, if a 
CPE tries to transmit from where it is located, this generates interference 
to the close-by DTV receivers (note that in 802.22, the BS is used as proxy 
for all its CPEs for the purpose of contacting the database service).  The 
solution that was selected was to reduce the amout of initial information 
to be sent to the BS at the time of association (e.g., CPE identification 
and its geographic location) to reduce the transmit burst length to its 
minimum to reduce the impact to the close-by DTV receivers as much as 
possible.  This can be done at the PHY and MAC level and would be beyond 
the scope of the IETF-PAWS.

Also, I would like to point out that the option for the database service to 
indicate the maximum allowed EIRP that the TVWS can use in its location 
(e.g., 8 bit data field: range -64 dBm (encoded 0x00) to +63.5 dBm (encoded 
0xFF)) should be included rather than only indicating whether the channel 
is available or not (1 bit field).  This option, which automatically 
includes the go/no-go switch (e.g., 0x00: unavailable), would allow for 
much smoother transitions at the edge of the DTV coverage areas and more 
flexibility in the TVWS operation.

Gerald

At 08:56 06-06-11 -0400, Rosen, Brian wrote:
>There are several strategies that can be used.  One end has to have an 
>independent Internet access mechanism.  It can determine what channels it, 
>and it's "clients" can use and broadcast them, or use one channel as a 
>beacon, allow the clients to access it on the beacon channel, and then 
>assign a channel to the client.  There are other strategies.
>
>Brian
>
>>Q “If the database replies with an empty channel list (no channels 
>>available) then the white space radio must not transmit.”
>>
>>I have wondered about this question because if the WS radio attempts to 
>>“contact” the database in order to determine what spectrum/channels are 
>>unlicensed in a particular geographical area  – by going through or 
>>sending out a transmit signal on the various spectrum/channels that are 
>>“possible” WS channels to use in all geographies, then by definition the 
>>WS radio will “interfere” by using this transmit signal with other 
>>licensed spectrum/channels.  Correct?
>>
>>How is this problem solved?  It is defined in PAWS almost as a question 
>>but not answered – at least that is my view.
>>
>>Thanks!
>>
>>Barlow
>>
>>Barlow Keener
>>617-671-1202
>>
>>Barlow Keener | Attorney | <http://www.keenerlawgroup.com/>Keener Law Group
>>d: 617.671.1202 | m: 781-858-1588 | 
>><mailto:[email-masked]>[email-masked]
>>Follow me on Twitter 
>><http://twitter.com/>http://twitter.com/<http://www.twitter.com/barlow>barlow 
>>| LinkedIn 
>><http://www.linkedin.com/in/barlowkeener>http://www.linkedin.com/in/barlowkeener 
>>| Blog: <http://www.whydom.com/>www.whydom.com
>>
>>
>>From: <mailto:[email-masked]>[email-masked] 
>>[mailto:[email-masked]] On Behalf Of 
>><mailto:[email-masked]>[email-masked]
>>To: <mailto:[email-masked]>[email-masked]; 
>><mailto:[email-masked]>[email-masked]; 
>><mailto:[email-masked]>[email-masked]
>>If the database replies with an empty channel list (no channels 
>>available) then the white space radio must not transmit.
>>
>>Once a channel list is received with at least one available channel, the 
>>white space radio may transmit on one of the available channels. 
>>Typically, the white space radio must contact the database regularly to 
>>ensure channel availability. If the white space radio is not able to 
>>contact the database, then the radio must cease transmission in white 
>>space within some period of time. The specific details are specified by 
>>the local regulator (e.g. FCC in the US, Ofcom in the UK, etc).
>>
>>The white space communication will ultimately be broken if contact with 
>>the database is lost. Your question about using white space as a 
>>secondary means of communication is a reasonable question, but beyond the 
>>scope of the database interface. For example, a device may use cellular 
>>radio, WiFi and white space radios, switching radios based on some 
>>arbitrary decisions (such as power consumption, QoS, subscription rate, 
>>etc). However this type of switching scenario is beyond the scope of the 
>>database interface and therefore PAWS.
>>
>>From: <mailto:[email-masked]>[email-masked] 
>>[mailto:[email-masked]] On Behalf Of ext M.K.Sajeev sajeev
>>To: Peter Saint-Andre; <mailto:[email-masked]>[email-masked]
>>This is Sajeev, interested in whitespace protocols, and an observer of 
>>this group. Reading through the charter I would like to clarify the following.
>>In the below paragraph radio device discovers whitespace channel 
>>availability time to time. What happens when the radio device does not 
>>find any channels available to initiate transmission, or if it happen 
>>during a session? Will the communication be broken, or the radio devices 
>>use this as a secondary means of communication? Would like to get some 
>>clarity..
>>
>>Email: <mailto:[email-masked]>[email-masked]
>><http://www.linkedin.com/in/mksajeev>http://www.linkedin.com/in/mksajeev
>>
>>From: Peter Saint-Andre <<mailto:[email-masked]>[email-masked]>
>>To: "<mailto:[email-masked]>[email-masked]" 
>><<mailto:[email-masked]>[email-masked]>
>>     Pete Resnick <<mailto:[email-masked]>[email-masked]>
>>     Peter Saint-Andre <<mailto:[email-masked]>[email-masked]>
>>
>>     Peter Saint-Andre <<mailto:[email-masked]>[email-masked]>
>>
>>Mailing lists:
>>     General Discussion: <mailto:[email-masked]>[email-masked]
>>     To Subscribe: 
>> <https://www.ietf.org/mailman/listinfo/paws>https://www.ietf.org/mailman/listinfo/paws
>>     Archive: 
>> <http://www.ietf.org/mail-archive/web/paws/>http://www.ietf.org/mail-archive/web/paws/
>>
>><mailto:[email-masked]>[email-masked]

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 6 Jun 2011 09:52:02 -0400

Yeah, I should have pointed out that this discussion is beyond the charter.

Thank you for the power suggestion on the return.  While some nations don't allow that, I've heard discussions that it might be allowed in some nations.

Getting a bit ahead of ourselves, what we see in many regulations are "buckets" (enumerated values with associated power levels) rather than explicit values, so the output format would have to have something like a series and a value, where one of the series options was "dBm".  When a regulator has "bucket" power levels, we can create a new series, with the values the regulator specifies.

Brian

---

From: "M.K.Sajeev sajeev" <[email-masked]>
Date: Tue, 7 Jun 2011 09:34:13 -0700 (PDT)

Thanks Scott.

I understand it does not directly relate to the charter, but reading on, got few technical questions and sharing those.

"When channel is not available radio must not transmit"

As white space offers very limited channel space, will the radio device  get into no transmission mode very often? When radio changes location during transmission, and no channel available then the data transmission is interrupted or broken. Or should whitespace radio also do GSM like channel allocation, locking, etc.to ensure uninterrupted transmission? 

Also does these spec anyways relate or scope RDS transmission present in FM Radios?
 
Sajeev Manikkoth
Email: [email-masked]

________________________________
From: "[email-masked]" <[email-masked]>
To: [email-masked]; [email-masked]; [email-masked]
Sent: Monday, 6 June 2011, 15:01
Subject: Re: [paws] updated charter

Hi Sajeev,

 

Regards,
Scott
 
From:[email-masked] [mailto:[email-masked]] On Behalf Of ext M.K.Sajeev sajeev
Sent: Saturday, June 04, 2011 5:27 AM
To: Peter Saint-Andre; [email-masked]
Subject: Re: [paws] updated charter
 
Hi,

 
Sajeev Manikkoth
Mobile: +919663311378
Email: [email-masked]

From:Peter Saint-Andre <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: Friday, 3 June 2011, 7:56
Subject: [paws] updated charter

###

Chairs:
TBD

Mailing lists:

Background

Problem Statement

Objectives

Deliverables

Milestones

###

---

From: <[email-masked]>
Date: Tue, 7 Jun 2011 22:55:15 +0000

Hi Sajeev,

> will the radio device get into no transmission mode very often?

This depends very much on the specific device, its specific location and the specific time of attempted operation. Variables include local regulations (the rules established by the local regulator), the white space device (output power, antenna height, etc), spectrum occupancy by primary users at the given time & location, etc. Shortly, we cannot know this in advance.

>When radio changes location during transmission, and no channel

>available then the data transmission is interrupted or broken. Or should

>whitespace radio also do GSM like channel allocation, locking, etc.to

>ensure uninterrupted transmission?

The white space model is that secondary or unlicensed users cannot cause interference, and cannot expect any protection from interference. Recognizing this, I don't know how a white space radio itself will be able to ensure uninterrupted transmission. The scenario you describe is an interesting use case which I hope is discussed by the WG. One possible solution would be some 'offloading' algorithm in which a device switches transmission to a different radio (e.g. cellular, WiFi, etc) in case the white space radio does not have a channel for transmission. IMHO, it is TBD if such a use case falls within the scope of the WG charter.

> Also does these spec anyways relate or scope RDS transmission present in FM Radios?

I am not aware of any link between white space and FM RDS transmission.

Regards,

Scott

From: ext M.K.Sajeev sajeev [mailto:[email-masked]]
Sent: Tuesday, June 07, 2011 11:34 AM
To: Probasco Scott (Nokia-CIC/Dallas); [email-masked]; [email-masked]
Subject: Re: [paws] updated charter

Thanks Scott.

Sajeev Manikkoth

  _____

Hi Sajeev,

Regards,

Scott

Hi,

Sajeev Manikkoth
Mobile: +919663311378

  _____

###

Chairs:
TBD

Mailing lists:

Background

Problem Statement

Objectives

Deliverables

Milestones

###

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 09 Jun 2011 09:11:48 -0600

> Of course not! It is just hilarious to see this expression being used today in the wireless context. Also, it may be confusing to those who are not SW developers and have not spent past decades imp…

Changed in my working copy to "query/response format".

Peter

-- 
Peter Saint-Andre
https://stpeter.im/