Subject: [paws] Extensibility for Ofcom

From: Vincent Chen <[email-masked]>
Date: Wed, 13 Mar 2013 22:16:52 -0700

Cesar,

Thanks for joining the call for the IETF/PAWS.

I want to follow up with you on the parameter names and values that we
should consider adding to the draft to support Ofcom White Space rules. In
particular:

 - What is the "unique device identifier" intended to be? Is there a
separate certification ID apart from the serial number?

 - What should be the parameter name for "device class"? What are the
possible values and what do they mean?

 - What should be the parameter name for "technology ID"? What are the
possible vales and what do they mean?

Are you aware of other parameters that must be defined for Ofcom?

Thanks for your help.

-- 
-vince

---

From: Vincent Chen <[email-masked]>
Date: Mon, 18 Mar 2013 16:42:27 -0700

Hi Cesar,

Thanks for your input.

For timing, we are hoping to get to "last call" in the next couple of
months. We need to address the open issues raised at the Face-to-Face.
There will be a final review process that will extend that time frame some
more.

It would be nice to encode the Ofcom/Etsi parameters in the base PAWS
protocol document.
For example, should we use "etsiHs" prefix for all the parameter names you
have listed?
We can at least start by adding the names, even though the final parameter
values have not been determined yet.

What do you think?

On Fri, Mar 15, 2013 at 3:45 AM, Cesar Gutierrez <
[email-masked]> wrote:

>  Hi Vince,
>
>
>
> Thanks for this. Note that we have not made final decisions on a number of
> aspects of the UK regulations and of the ETSI Harmonised Standard, so some
> of the parameters are still work in progress. Please see below my comments
> on the points you raise:
>
> -        Unique Device Identifier. Predictably, its purpose is to enable
> databases to uniquely identify a device. In that sense it is similar to the
> pair FCC Identifier + serial number in the US regulations. However, we do
> not have an equivalent to the FCC Identifier in Europe, so the Unique
> Device Identifier would be the set of 1) a manufacturer identifier, 2) a
> model number and  3) the serial number. We haven’t concluded on the formats
> of these in ETSI BRAN. However, it is probably safe to say that 2) and 3)
> would be strings of characters whose content is decided by the
> manufacturer. On the other hand, it is less clear at present what the
> manufacturer identifier could be. Options under consideration are a IEEE
> OUI, or the manufacturer’s name in text.
> We will not have a certification ID in the ETSI standard or the UK
> regulations.
>
> -        Device class. A better name is Device Emission Class. It
> characterises the out of block emissions of the device. There will be a
> number of classes specified in ETSI Harmonised Standard – there four in the
> current draft (class 1 to class 4) but the count may change in the coming
> months.
>
> -        Technology ID. I think “Technology ID” is good as a name. Access
> technologies may be developed in the future that provide better protection
> to incumbents, and databases will need to know the technology of the device
> if they are to apply protection ratios that account for it. Currently, ETSI
> HS defines this parameter as a string.
>
> -        Other device parameters currently in the ETSI HS are the device
> Category and the device Type. Device Category can take the values “Master”
> and “Slave”, and it is very unlikely to change or to have additional new
> values. The current draft of the HS allows for two values for the Type
> parameter: Type A and Type B. Simplistically, Type A is a fixed device and
> Type B is a mobile device. However, there is considerable debate on the
> types ongoing, and in any case we expect to add new types in the future.
> These will take letter values such as Type E, Type C.
>
> -        In addition, the database will send the device two parameters
> that I believe are not captured in PAWS. These are the “Maximum total
> bandwidth” and the “Maximum nominal channel bandwidth”. They represent the
> maximum number of channels and the maximum number of contiguous channels
> that the device can use, respectively. Both are integer in value. In PAWS,
> they probably should go into the “SpectrumSchedule” or “Spectrum”
> parameters.
>
>
>
> I think you also raised questions about the ruleset. The issue is whether,
> at this point, the ruleset should be based on European regulation or UK
> regulation. I think there might be no difference in practice between the
> two approaches, since we expect that all UK requirements with regards to
> devices will be captured in the ETSI Harmonised Standard. However, I think
> we need to reflect on this a bit more in Ofcom and in ETSI.
>
>
>
> This raises the question of timelines. Do you have a deadline for changes
> to the parameters in your draft?
>
>
>
> Thank you and regards,
>
> Cesar
>
>
>
>
>
> *From:* Vincent Chen [mailto:[email-masked] <[email-masked]>]
> *Sent:* 14 March 2013 05:17
> *To:* Cesar Gutierrez; [email-masked]
> *Subject:* Extensibility for Ofcom
>
>
>
> Cesar,
>
>
>
> ------------------------------
>
>
> ******************************************************************************************************************
> For more information visit www.ofcom.org.uk
>
> This email (and any attachments) is confidential and intended for the use
> of the addressee only.
>
> If you have received this email in error please notify the originator of
> the message and delete it from your system.
>
> This email has been scanned for viruses. However, you open any attachments
> at your own risk.
>
> Any views expressed in this message are those of the individual sender and
> do not represent the views or opinions of Ofcom unless expressly stated
> otherwise.
>
> ******************************************************************************************************************
>

-- 
-vince