Subject: [paws] TVWS DB discovery use case

From: "Elrefaey, MohamedX" <[email-masked]>
Date: Wed, 27 Jul 2011 14:20:43 +0100

Hello All,
I'm new to this group and I have a small question and can be considered a suggestion as well;

Regarding the TVWS database discovery use case:

Why not we learn from previous efforts done over the internet in similar cases like in web services model? i.e. why not we create a universal TVWS database registry to contains all the TVWS DB for each country or region like the UDDI (Universal Description, Discovery and Integration) in the web services model. And the DB discovery use case will be instead a lookup operation in that registry and once the DB is found the integration will occur and the query-response process will start.

Regards,
Mohamed El-Refaey

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 27 Jul 2011 09:44:06 -0400

Well, among other things, if all you have is a lat/lon for your location, how do you know which country you are in?

Might seem to be a stupid question, but if we don't use a GUI, then you have to intersect your lat/lon with a set of country boundary polygons to determine the country, and then look up the country in the registry.

A more reasonable alternative is LoST (RFC5222), which is designed to do exactly what we need: you query a server with a location: either a lat/lon (we call that a "geo") or a "civic" address (like a street address, although it this case could be just the country name), plus a "Service URN" and you get back a URI.

The service URN is what kind of service you want the URI for.  The original use is emergency calling.  The service urn is "urn:service:sos".  We could, for example, have a service urn for each band, or class of service, like urn:service:ws:tvband
You query LoST with your location and this service URN, it returns the URI(s) of the database.

Brian

On Jul 27, 2011, at 9:20 AM, Elrefaey, MohamedX wrote:

Hello All,
I’m new to this group and I have a small question and can be considered a suggestion as well;

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

---

From: "Elrefaey, MohamedX" <[email-masked]>
Date: Wed, 27 Jul 2011 14:53:46 +0100

Thanks Brian for your reply. However using LoST will give you the way you can use to communicate your location, but still my suggestion is why not have such a universal registry for TVWS with a hierarchical levels per country and use it similar to UDDI to web services.
So a combination of LoST and UDDI-like, we can have a neat model for TVWS DB lookup and discover and this will ease things at implementation time. Because at the end of the day you don't need to define the way you communicate your lat/long but how these databases will be constructed or accessed.

My two cents :)

Regards,
Mohamed El-Refaey

From: Rosen, Brian [mailto:[email-masked]]
Sent: Wednesday, July 27, 2011 3:44 PM
To: Elrefaey, MohamedX
Cc: [email-masked]
Subject: Re: [paws] TVWS DB discovery use case

Brian

Hello All,

Regards,
Mohamed El-Refaey

---

From: Paul Lambert <[email-masked]>
Date: Wed, 27 Jul 2011 11:10:55 -0700

I was not able to get this into yesterdays meeting but hope the attached slides will generate some comments on the list.

I'll also translate them into  a ascii text contribution.

Paul

Paul A. Lambert |  Marvell  | +1 650 787 9141

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 28 Jul 2011 16:00:02 -0400

<hat type='individual'/>

On 7/27/11 2:10 PM, Paul Lambert wrote:
>  
> 
> I was not able to get this into yesterdays meeting but hope the attached
> slides will generate some comments on the list.

That's good input. It's unfortunate that you weren't able to present. I
agree with you that the WG needs to consider the requirements of
authorities other than the FCC.

I have one question. You say:

   PAWS protocol must support naming of
   devices by multiple Regulatory Authorities.

Does that mean that the same device might be named by multiple authorities?

> I’ll also translate them into  a ascii text contribution.

That would be great!

Peter

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

---

From: Paul Lambert <[email-masked]>
Date: Thu, 28 Jul 2011 13:32:03 -0700

Hi Peter,

> Does that mean that the same device might be named by multiple

Yes.  Devices will that may operate in more than one region
need to meet the certification and naming requirements 
multiple Regulatory Authorities.

There may be multiple Regulatory Authorities in a region
(e.g. FCC and Military) and some devices may have multiple
modes of operation in a region.

Every Regulatory Authority will have its own way to assign 
names to device models/types.  FCC has one way - the FCC ID.
For example:
	"FCC ID: E2K24B4BNHM"

Online you can find this string and determine if this product 
is certified by the FCC for operation against a particular 
set of FCC rules.

The same product has some text and a cryptic string indicating
that it can operate in Singapore.

Any one Regional Authority cannot be expected to share and 
understand a name from another region.  However, there
also could be cooperation and reuse of a name between regions.

The FCC approach embeds a vendor identification into the front
of the string valued Device Model.  So this is actually a three
level hierarchy of Regional Authority, Vendor and Device Model.

Paul

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 28 Jul 2011 16:41:51 -0400

<as individual>
Certainly a device may be able to work in multiple countries, and in multiple bands, and in multiple modes/modulation/...

It's clear that in many cases there will be identifiers that the local authorities require to be used for auditing purposes.

I don't think that the protocol will care if there is any structure to the identifier.  We may care which series (FCC ID, OfCOM ID, ...) it is part of.   So, we have a requirement to carry an identifier, and we may have a requirement to carry a series enumeration.

We don't need a nation ID, the nation you are in may determine which database you discover however.

The may be true of the band, but I probably would suggest that we allow an identifier of band in the input; it's certainly feasible for one database to serve multiple bands.  So, there is another requirement: the band is an input to database discovery and is also an input on the query.

Similarly, you can imagine that different classes of devices could be served by the same or different databases.  That means device class (which may mean modulation, power, mobility capability, installer method, …) has to be both a criteria for database discovery and an parameter in the query.

Brian

On Jul 28, 2011, at 4:32 PM, Paul Lambert wrote:

> [email-masked]

---

From: Paul Lambert <[email-masked]>
Date: Thu, 28 Jul 2011 14:50:45 -0700

> From: Rosen, Brian [mailto:[email-masked]]
...
> 
> <as individual>
> Certainly a device may be able to work in multiple countries, and in
> multiple bands, and in multiple modes/modulation/...
> 
> It's clear that in many cases there will be identifiers that the local
> authorities require to be used for auditing purposes.
> 
> I don't think that the protocol will care if there is any structure to
> the identifier.  We may care which series (FCC ID, OfCOM ID, ...) it is
> part of.   So, we have a requirement to carry an identifier, and we may
> have a requirement to carry a series enumeration.

Series enumeration?  The protocol may not care what type of field indicates
the Device Model Id, but these fields need to coordinated across
many Regional Authorities so the naming has structure.

> The may be true of the band, but I probably would suggest that we allow
> an identifier of band in the input; it's certainly feasible for one
> database to serve multiple bands.  So, there is another requirement:
> the band is an input to database discovery and is also an input on the
> query.
Yes.. and the short power point I sent expands the notion of band to
include a specific set of rules.  There are often multiple sets of
rules from a Regulatory Authority covering the same spectral range.
The name or identifier of a "band" needs to encompass both the frequency
and the desired operating rule set.

This is different from specific device characteristics operating in  
a band

> 
> Similarly, you can imagine that different classes of devices could be
> served by the same or different databases.  That means device class
> (which may mean modulation, power, mobility capability, installer
> method, ...) has to be both a criteria for database discovery and an
> parameter in the query.

Yes - OFCOM rules suggest that a devices spectral mask may determine
it's allowed power based on interference in adjacent channels.  This
is an interesting capability (better control of interference and
allowing better spectrum utilization).  This seems to be an orthogonal
description of the modulation than the "band/rule set" and would
relate to specifically identifiable modulation techniques.  This
could be mapped to something like the MCS rates in 802.11

This Operating Class would need to be optionally indicated per
requested Band since we anticipate multi-band devices.

This gives the following set of names / identifiers in the presentation
 - Regulatory Authority 
 - Device Model (assigned by a Regulatory Authority)
 - Band (overloaded here to mean band and specific rule set - another name might help)
 - Operating Class (optional indication of modulation specific characteristics)

I left out:
 - Device Id (which is Device Model + Device Serial Number)

Names above are a strawman - not sure I like serial number since it's usually a string,
"Band" might be confusing and need to be lengthened to indicate it's a regulatory defined
set of Rules and spectral range. 

Paul