Subject: [paws] UC&R I-D: section 4.1 (TVWS database discovery, device registration with trusted database)

From: <[email-masked]>
Date: Thu, 2 Feb 2012 16:21:45 +0000

Hello All,

As editors of the problem statement, use cases & requirements draft we are
attempting to prepare a completed draft which could be ready for working
group last call before IETF83. In the coming days we will post the
sections of the draft to the mailing list. Our request is that you review
these sections and reply to the email with any comments.

Below is the text for sections on protocol services (new section
numbering). This text has been marked up from version-02 as uploaded
January 26, 2012 to include the previous comments on the mail reflector
about use cases vs. protocol services, plus a few suggestions from the
editor (removing 'TV' since PAWS applies to all white space, correcting
for the fact that we only know at this time the FCC's specific
requirements for registration).

Our goal is that any discussion on this text will conclude by February 9.
To be clear, approval of the document will go through the normal process
of last calls etc.. We are simply asking for your assistance in preparing
a complete & accurate document that could progress the work. So please
review the text and send your comments either directly to the editor or to
the mailing list.

Kind Regards,
Raj & Scott

<Insert>

4.1 Protocol Services

A complete protocol solution must provide all services that are essential
to enable the white space paradigm. Before a white space device can
request service from a white space database, such as a query for a list of
available channels, the white space device must first locate or
"discover" a suitable database. Additionally, some regulatory
authorities require the white space device to register with the database
as a
first step. This section describes the services required from the protocol.
</Insert>

4.1.1.  <Delete>TVWS</Delete><Insert>White space</Insert> database
discovery

<Delete>This use case</Delete><Insert>White space database
discovery</Insert> is preliminary to creating a radio network using
<Delete>TV</Delete>
   white space; it is a prerequisite to
<Delete>other</Delete><Insert>the</Insert> use cases
<Insert>below</Insert>.  The radio
   network is created by a master device.  Before the master device can
   transmit in <Delete>TV</Delete> white space spectrum, it must contact a
trusted
   database where the device can learn if any channels are available for
   it to use.  The master device will need to discover a trusted
   database in the relvant regulatory domain, using the following steps:

   1.  The master device is connected to the internet by any means other
       than using the <Delete>TV</Delete> white space radio.

   2.  The master device constructs and sends a service request over the
       Internet to discover availability of trusted databases in the
       local <Insert>regulatory</Insert> domain and waits for responses.

   3.  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
       register and receive service from the database.

   Optionally the radio device is pre-programmed with the internet
   address of at least one trusted database.  The device can establish
   contact with a trusted database using one of the pre-programmed
   internet addresses and establish a <Delete>TV</Delete> white space
network (as
   described in one of the following use cases).

   Optionally the initial query will be made to a listing approved by
   the national regulator for the domain of operation (e.g. a website
   either hosted by or under control of the national regulator) which
   maintains a list of <Delete>TV</Delete>WS databases and their internet
addresses.  The
   query results in the list of databases and their internet addresses
   being sent to the master, which then evaluates the repsonse to
   determine if a trusted database can be identified where the master
   device is able to register and receive service from the database.

4.1.2.  Device registration with trusted Database

   <Delete>This use case</Delete><Insert>Registration</Insert> is
preliminary to creating a radio network using <Delete>TV</Delete>
   white space; it is a prerequisite to
<Delete>other</Delete><Insert>the</Insert> use cases
<Insert>below</Insert>.  The radio
   network is created by a master device.  Before the master device can
   transmit in <Delete>TV</Delete> white space spectrum, it must contact a
trusted
   database where the device can learn if any channels are available for
   it to use.  Before the database will provide information on available
   <Delete>TV</Delete><Insert>radio</Insert> channels, the master device
must register with the trusted
   database.  Specific requirements for registration come from
   individual regulatory domains and may be different.

   The figure below shows an example deployment of this scenario.

                              \|/                            ----------
                               |                             |Database|
                               |                     .---.   /---------
                             |-|---------|          (     ) /
     \|/                     |  Master   |         /       \
      |                   /  |           |========( Internet )
      |                  /   |-----------|         \        /
    +-|----+   (TDD AirIF)                          (      )
    |Master|  /                                      (----)
    |      | /
    +------+

     Figure 2: Example illustration of registration requirement in
<Delete>TV</Delete>
                           white space use-case

   A simplified operational scenario showing registration consists of
   the following steps:

   1.  The master device must register with
<Delete>the</Delete><Insert>its</Insert> most current and up-to-
       date information.  Typically the master device will register
       prior to operating in <Delete>TV</Delete> white space for the first
time after
       power up, after changing location by a predetermined distance,
       and after regular time intervals.

   2.  The master device shall provide to the database during
       registration <Insert>all information required according to local
regulatory requirements. This information may include, but is not limited
to, </Insert><Delete>a minimum of</Delete> the Device ID, serial number
assigned by the manufacturer <Delete>and</Delete> the device's
location<Insert>, device antenna height above ground, name of the
individual or business that owns the device, name of a contact person
responsible for the device's operation, address for the
       contact person, email address for the contact person and phone
number of the contact person.</Insert>

<Delete>
   3.  Depending upon regulatory domain requirements, the device may
       also provide device antenna height above ground, name of the
       individual or business that owns the device, name of a contact
       person responsible for the device's operation, address for the
       contact person, email address for the contact person and phone
       number of the contact person to the database during registration.
</Delete>

---

From: <[email-masked]>
Date: Thu, 2 Feb 2012 19:02:26 +0000

Scott

The Device Registration use case at 4.1.2 is shown as a pre-requisite, but may not be required in all regulatory domains. I take your point though that at present we only have firm requirements from the FCC.

I guess that the left most device in the diagram in 4.1.2 should be labelled slave, not master.

There is a conflict between the use case (elsewhere) that allows for WS backhaul, and step 1 of database discovery in 4.1.1. It is possible for a master to send a service request to the database over the WS, if it does so as a slave to another master on that master's allowed frequencies. We could correct step 1 to reflect this as follows:

1.  The master device is connected to the internet by any means other than using the <Delete>TV</Delete> white space radio. <Insert>An exception is where the master device also has slave capabilities and is already connected to the internet as a slave of the white space radio network of another master.</Insert>

Regards

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 02 February 2012 16:22
To: [email-masked]
Subject: [paws] UC&R I-D: section 4.1 (TVWS database discovery, device registration with trusted database)

Hello All,

As editors of the problem statement, use cases & requirements draft we are attempting to prepare a completed draft which could be ready for working group last call before IETF83. In the coming days we will post the sections of the draft to the mailing list. Our request is that you review these sections and reply to the email with any comments.

Below is the text for sections on protocol services (new section numbering). This text has been marked up from version-02 as uploaded January 26, 2012 to include the previous comments on the mail reflector about use cases vs. protocol services, plus a few suggestions from the editor (removing 'TV' since PAWS applies to all white space, correcting for the fact that we only know at this time the FCC's specific requirements for registration).

Our goal is that any discussion on this text will conclude by February 9.
To be clear, approval of the document will go through the normal process of last calls etc.. We are simply asking for your assistance in preparing a complete & accurate document that could progress the work. So please review the text and send your comments either directly to the editor or to the mailing list.

Kind Regards,
Raj & Scott

<Insert>

4.1 Protocol Services

A complete protocol solution must provide all services that are essential to enable the white space paradigm. Before a white space device can request service from a white space database, such as a query for a list of available channels, the white space device must first locate or "discover" a suitable database. Additionally, some regulatory authorities require the white space device to register with the database as a first step. This section describes the services required from the protocol.
</Insert>

4.1.1.  <Delete>TVWS</Delete><Insert>White space</Insert> database discovery

<Delete>This use case</Delete><Insert>White space database discovery</Insert> is preliminary to creating a radio network using <Delete>TV</Delete>
   white space; it is a prerequisite to
<Delete>other</Delete><Insert>the</Insert> use cases <Insert>below</Insert>.  The radio
   network is created by a master device.  Before the master device can
   transmit in <Delete>TV</Delete> white space spectrum, it must contact a trusted
   database where the device can learn if any channels are available for
   it to use.  The master device will need to discover a trusted
   database in the relvant regulatory domain, using the following steps:

   internet addresses and establish a <Delete>TV</Delete> white space network (as

   maintains a list of <Delete>TV</Delete>WS databases and their internet addresses.  The

   <Delete>This use case</Delete><Insert>Registration</Insert> is preliminary to creating a radio network using <Delete>TV</Delete>
   white space; it is a prerequisite to
<Delete>other</Delete><Insert>the</Insert> use cases <Insert>below</Insert>.  The radio
   network is created by a master device.  Before the master device can
   transmit in <Delete>TV</Delete> white space spectrum, it must contact a trusted
   database where the device can learn if any channels are available for
   it to use.  Before the database will provide information on available
   <Delete>TV</Delete><Insert>radio</Insert> channels, the master device must register with the trusted
   database.  Specific requirements for registration come from
   individual regulatory domains and may be different.

                              \|/                            ----------
                               |                             |Database|
                               |                     .---.   /---------
                             |-|---------|          (     ) /
     \|/                     |  Master   |         /       \

     Figure 2: Example illustration of registration requirement in <Delete>TV</Delete>
                           white space use-case

   1.  The master device must register with <Delete>the</Delete><Insert>its</Insert> most current and up-to-
       date information.  Typically the master device will register
       prior to operating in <Delete>TV</Delete> white space for the first time after
       power up, after changing location by a predetermined distance,
       and after regular time intervals.

   2.  The master device shall provide to the database during
       registration <Insert>all information required according to local regulatory requirements. This information may include, but is not limited to, </Insert><Delete>a minimum of</Delete> the Device ID, serial number assigned by the manufacturer <Delete>and</Delete> the device's location<Insert>, device antenna height above ground, name of the individual or business that owns the device, name of a contact person responsible for the device's operation, address for the
       contact person, email address for the contact person and phone number of the contact person.</Insert>

<Delete>

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

---

From: <[email-masked]>
Date: Thu, 2 Feb 2012 20:17:34 +0000

Hi Andy,

Thank you for reviewing, you have indeed discovered an inconsistency. I
believe Figure 2 is accurate, this was meant to cover the ability of a
Master device to initialize and register over TVWS, as anticipated by the
FCC in 47 CFR Part 15 subpart H § 15.711 (e). As you point out, the text
in step 1 clearly does not support this, and thus should be improved. As
this applies to a Master device which is not already connected to the
internet, I wonder if you would be okay with the following replacement
text:

"A local regulator may identify exception cases where a Master may
initialize over white space (e.g. the FCC allows a Master to initialize
over TV white space in certain conditions)."

Kind Regards,
Scott

On 2/2/12 1:02 PM, "ext [email-masked]" <[email-masked]> wrote:

>Scott
>
>The Device Registration use case at 4.1.2 is shown as a pre-requisite,
>but may not be required in all regulatory domains. I take your point
>though that at present we only have firm requirements from the FCC.
>
>There is a conflict between the use case (elsewhere) that allows for WS
>backhaul, and step 1 of database discovery in 4.1.1. It is possible for a
>master to send a service request to the database over the WS, if it does
>so as a slave to another master on that master's allowed frequencies. We
>could correct step 1 to reflect this as follows:
>
>than using the <Delete>TV</Delete> white space radio. <Insert>An
>exception is where the master device also has slave capabilities and is
>already connected to the internet as a slave of the white space radio
>network of another master.</Insert>
>
>Regards
>
>Andy
>
>As editors of the problem statement, use cases & requirements draft we
>are attempting to prepare a completed draft which could be ready for
>working group last call before IETF83. In the coming days we will post
>the sections of the draft to the mailing list. Our request is that you
>review these sections and reply to the email with any comments.
>
>review the text and send your comments either directly to the editor or
>to the mailing list.
>
>Kind Regards,
>Raj & Scott
>
>
>
><Insert>
>
>4.1 Protocol Services
>
>request service from a white space database, such as a query for a list
>of available channels, the white space device must first locate or
>"discover" a suitable database. Additionally, some regulatory authorities
>require the white space device to register with the database as a first
>step. This section describes the services required from the protocol.
></Insert>
>

---

From: <[email-masked]>
Date: Tue, 21 Feb 2012 16:46:18 +0000

Hi Andy, All,

Following up on your keen observation about registration as a
pre-requisite. It may not be required in all regulatory domains, and also
not for all device types. If there are no objections, I will make the
following correction:

Registration <delete>is</delete><insert>may be</insert> preliminary to
creating a radio network using white space; <insert>in some regulatory
domains, for some device types,</insert> it is a prerequisite to the use
cases below.  The radio network is created by a master device.

Kind Regards,
Scott

---

From: <[email-masked]>
Date: Tue, 21 Feb 2012 16:53:38 +0000

Scott

Good for me. A consequential revision would be consistent in the (old) 4.1.1 on database discovery. At step 3 it says "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 register and receive service from the database." I suggest the intent is the same and the application consistent across regulatory domains if "register and receive service" is changed to "receive service".

Regards

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 21 February 2012 16:46
To: Sago,AJ,Andy,COD R; [email-masked]
Subject: Re: [paws] UC&R I-D: section 4.1 (TVWS database discovery, device registration with trusted database)

Hi Andy, All,

Following up on your keen observation about registration as a pre-requisite. It may not be required in all regulatory domains, and also not for all device types. If there are no objections, I will make the following correction:

Registration <delete>is</delete><insert>may be</insert> preliminary to creating a radio network using white space; <insert>in some regulatory domains, for some device types,</insert> it is a prerequisite to the use cases below.  The radio network is created by a master device.

Kind Regards,
Scott

On 2/2/12 1:02 PM, "ext [email-masked]" <[email-masked]> wrote:

>backhaul, and step 1 of database discovery in 4.1.1. It is possible for 
>a master to send a service request to the database over the WS, if it 
>does so as a slave to another master on that master's allowed 
>frequencies. We could correct step 1 to reflect this as follows:
>
>To be clear, approval of the document will go through the normal 
>process of last calls etc.. We are simply asking for your assistance in 
>preparing a complete & accurate document that could progress the work. 
>So please review the text and send your comments either directly to the 
>editor or to the mailing list.
>
>Kind Regards,
>Raj & Scott
>
>
>
><Insert>
>
>4.1 Protocol Services
>
>A complete protocol solution must provide all services that are 
>essential to enable the white space paradigm. Before a white space 
>device can request service from a white space database, such as a query 
>for a list of available channels, the white space device must first 
>locate or "discover" a suitable database. Additionally, some regulatory 
>authorities require the white space device to register with the 
>database as a first step. This section describes the services required from the protocol.
></Insert>
>
>regulatory requirements. This information may include, but is not 
>limited to, </Insert><Delete>a minimum of</Delete> the Device ID, 
>serial number assigned by the manufacturer <Delete>and</Delete> the 
>device's location<Insert>, device antenna height above ground, name of 
>the individual or business that owns the device, name of a contact

---

From: <[email-masked]>
Date: Tue, 21 Feb 2012 16:59:13 +0000

Hi Andy,

I agree with you.

Kind Regards,
Scott

On 2/21/12 10:53 AM, "ext [email-masked]" <[email-masked]> wrote:

>Scott
>
>Good for me. A consequential revision would be consistent in the (old)
>4.1.1 on database discovery. At step 3 it says "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
>register and receive service from the database." I suggest the intent is
>the same and the application consistent across regulatory domains if
>"register and receive service" is changed to "receive service".
>
>Regards
>
>Andy
>
>Subject: Re: [paws] UC&R I-D: section 4.1 (TVWS database discovery,
>device registration with trusted database)
>
>Hi Andy, All,
>