Re: [paws] draft document for Discovery

["Benjamin A. Rolfe" <[e-mail]>]

Thanks Scott,
Yes, there is an presumption that the WSD knows where it is located on earth.  It has to know this to make a database request of course.  What we're looking for then is a global means to determine what the initial contact needs to be depending on location.  It seems like the steps necessary to find a database may be different region by region. That should make it fun!

-Ben

Hi Ben,

If the WSD will never have the possibility to be turned on outside the UK, this could work. But about the case where the device is carried to another regulatory domain somewhere in the world? Discovery is needed for this case; to find an authorized database no matter where the device is when turned on (assuming white space is authorized in the country where the device is turned on).

Kind Regards,

Scott

From: "ext Benjamin A. Rolfe" <[e-mail]>
Date: Thu, 12 Jul 2012 12:24:15 -0700
To: "[e-mail]" <[e-mail]>
Subject: Re: [paws] draft document for Discovery

Thanks Andy,
So in this case the is it expected the device knows the URI for Ofcom's list and should start there?
-Ben

All

 

Just to highlight that Ofcom requires that the list of available databases (maintained by Ofcom) is consulted once every 24 hours (so that misbehaving database operators can be removed from the list and devices stop using their channel allocations). Ofcom doesn’t permit a master device to have a pre-arrangement with a database (such as a pre-programmed URI), or at least, the validity of any pre-programmed URI has to be checked every 24 hours with Ofcom’s listing. The discovery problem is similar to US, but two step through an intermediate listing.

 

Regards

 

Andy

 

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: 10 July 2012 22:44
To: [e-mail]
Subject: Re: [paws] draft document for Discovery

 

Hi All,

 

It is simple. Vendors could support it forever. And if for example the roaming agreement becomes a preferred solution, the vendor could program one or more addresses into the device (SW update, device management, etc). In the use case & requirements document the assumption has been that a simple case of discovery is hard-coded addresses in the device.

 

Best Regards,

Scott

 

From: "ext Rosen, Brian" <[e-mail]>
Date: Tue, 10 Jul 2012 17:17:46 -0400
To: "ext com>" <[e-mail]>
Cc: Scott Probasco <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [paws] draft document for Discovery

 

That would work.

 

This would happen every time the device booted.  That could be a fair amount of traffic for a high volume manufacturer.   They have to support this forever.

 

It's simple.

 

I wonder if the device mfg would agree to that?

 

Brian

 

On Jul 10, 2012, at 5:09 PM, Peter Stanforth wrote:

on this topic a completely different approach would be for the device to call home, to the manufacturer, with the ability for the manufacturer to point it to the appropriate DB for that location. This works well, and simply if we assume the device has the relationship with the DB. If it is a user (Say network operator) then I would expect them to configure their devices to go where they desire them to go.  

On Jul 10, 2012, at 3:50 PM, "Rosen, Brian" <[e-mail]> wrote:

When I do the discovery, I don't know which country I am in.  I can't know enough to query the right DS unless we put country boundary polygons in the device.

 

Of course, I forgot to add to this that if there is the U.S. model of competing DBs, then the whole discovery mechanism falls apart, and you need configuration, because if the device knows who its business relationship is with, it can know the URI.

 

Brian

 

 

On Jul 10, 2012, at 3:38 PM, <[e-mail]> <[e-mail]> wrote:

Hi Brian,

 

Comments below: MSP->

 

Kind Regards,

Scott

 

From: "ext Rosen, Brian" <[e-mail]>
Date: Mon, 9 Jul 2012 17:27:31 -0400
To: Scott Probasco <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [paws] draft document for Discovery

 

This re-invents LoST without the extensive mechanisms for self organizing databases.

LoST has a query that sends location in, with a Service URN (which for this use would be "I want a WSDB for this location" and you get back (a list of) URIs.  

 

That's what you propose, without the service URN because you want a special location based discovery mechanism just for WSDBs.

 

What you don't deal with is how a WSDB DS finds out about all other WSDB DSs.  That's the LoST "Forest Guide".  The FG works without a root, and allows cooperating LoST servers to  refer queries to the right server.

MSP->If each WSD vendor arranges a service level agreement with a WSDB DS (or provides their own WSDB DS) then it is not obvious to me why a WSDB DS would need to find out about other WSDB DSs. Each WSDB DS is independent. If vendor X intends their WSD to operate in Country Y, then WSDB DS used by vendor X must include appropriate Country Y mapping information (location to WSDB or WSDB listing server) in their WSDB DS.

 

It's not really a great idea to bake a URI into a device.  Who knows what will happen over the life of a device?

MSP->Including an address in the device does not imply that the address cannot be changed if needed. SW updates, device management or similar can allow for changes if needed. I take your point, these changes should be exceptions rather than regular events.

 

The existing LoST discovery mechanism is built for widespread deployment in ISPs.   We may need something that works well without that.  There aren't a lot of good mechanisms that really work well - you either have a root of some sort, or, as you propose, a starting seed.  The root problem is who runs the root, and the starting seed problem is the lifetime of the seed.  You note that the seed gets nothing out of the exchange - it doesn't get to serve the query, it only gets to refer to someone who does.  

MSP->It is not clear to me what business model would support a sophisticated infrastructure as described in the LoST Architecture & Framework RFC 5582.

 

I actually think this is not an important problem to solve really well.  The most common deployment model is going to be a tower and clients.  The tower can be configured, and either the clients learn from the tower, or the tower handles the database query itself.  Client discovery in that case could be the LoST discovery mechanism.

 

We have to handle the self organizing case (say a MANET) where one or more devices have some other path to the Internet to get to the WSDB.  They will need real discovery and may not have a cooperating ISP.  While I really don't like configuration, it may be the only viable way to do it.

MSP->Configuration is pragmatic and can be easily deployed

 

Brian

 

On Jul 9, 2012, at 5:04 PM, <[e-mail]> wrote:

Hello All,

 

Please find a link below to a draft submission for the Discovery process as described in the Use Cases & Requirements document. We are looking forward to your review and comments as well as discussion at IETF#84.

 

Abstract:

   A white space master device needs to query a white space database and

   obtain information about available spectrum/channels prior to

   operation.  White space databases which contain information about

   available spectrum/channels are associated with a regulatory domain.

   A white space master device needs to discover the relevant white

   space database(s) given its current location and in which regulatory

   domain that it is operating.  The white space database discovery is

   the preliminary step that a white space master device has to perform.

 

 

URL:             http://www.ietf.org/internet-drafts/draft-probasco-paws-discovery-00.txt" rel="nofollow">http://www.ietf.org/internet-drafts/draft-probasco-paws-discovery-00.txt

Htmlized:        http://tools.ietf.org/html/draft-probasco-paws-discovery-00" rel="nofollow">http://tools.ietf.org/html/draft-probasco-paws-discovery-00

 

Kind Regards,

Scott & Raj

 

 

 

_______________________________________________
paws mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/paws" rel="nofollow">https://www.ietf.org/mailman/listinfo/paws

 

_______________________________________________
paws mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/paws" rel="nofollow">https://www.ietf.org/mailman/listinfo/paws

 

_______________________________________________
paws mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/paws" rel="nofollow">https://www.ietf.org/mailman/listinfo/paws

 

_______________________________________________ paws mailing list [e-mail]://www.ietf.org/mailman/listinfo/paws" rel="nofollow">https://www.ietf.org/mailman/listinfo/paws

_______________________________________________ paws mailing list [e-mail] https://www.ietf.org/mailman/listinfo/paws" rel="nofollow">https://www.ietf.org/mailman/listinfo/paws

_______________________________________________ paws mailing list [e-mail] https://www.ietf.org/mailman/listinfo/paws" rel="nofollow">https://www.ietf.org/mailman/listinfo/paws