Subject: Re: [paws] Revised ETSI standard

From: "Luzango Mfupe" <[email-masked]>
Date: Tue, 04 Mar 2014 08:58:15 +0200

Hi Cesar,
 
What will be the implications regulatory-wise of not including this new ETSI requirement in PAWS version 1?, is this not an optional requirement?
Regards
Luzango.

>>> Cesar Gutierrez <[email-masked]> 03/03/2014 19:00 >>>
Gabor, Brian,

I think that what we would be looking for is a new parameter added to the SpectrumSpec element.

I suggest the following:

Parameter name: etsiEnSimultaneousChannelOperationRestriction
Parameter usage location: SpectrumSpec (Section 5.9)
Specification document: Specifies the constraint on the device maximum total EIRP, as defined by the ETSI Harmonised Standard  [ETSI-EN-301-598].  The values are represented by numeric strings,  such as "0", "1", etc.  Consult the documentation for the specification of the power constrain corresponding to each parameter value.

It would be great if we could consider this at the WG meeting tomorrow.

Thanks and regards,
Cesar

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: 27 February 2014 15:51
To: Gabor Bajko
Cc: Cesar Gutierrez; [email-masked]
Subject: Re: [paws] Revised ETSI standard

Can do.  We'll cover this at the end of the -protocol discussion.

Brian

On Feb 26, 2014, at 6:22 PM, Gabor Bajko <[email-masked]> wrote:

> The need for this requirement should be discussed on the list; and if
> agreed, it can be incorporated by the editor into a future draft
> version.
> I won't be there in London, but perhaps, if you or someone else could
> propose text this week, Brian could add it to next week's agenda.
>
> - Gabor
>
> On Wed, Feb 26, 2014 at 10:12 AM, Cesar Gutierrez
> <[email-masked]> wrote:
>> Dear all,
>>
>>
>>
>> There is a new version available of ETSI EN 301 598 (this is the
>> standard that lays out the requirements for operation in Europe).
>> Most of the changes relate to RF requirements, but there is also an
>> additional information element that the database will have to communicate to the Master device.
>> This element indicates whether simultaneous transmission over
>> multiple channels must be restricted in power, and it can take the values of 0 and 1.
>>
>>
>>
>> EN 301 598 v1.0.9 can be found here:
>>
>> http://www.etsi.org/deliver/etsi_en/301500_301599/301598/01.00.09_30/
>> en_301598v010009v.pdf
>>
>> and the addition I am referring to is described in section 4.2.3.4
>> and in table 4.
>>
>>
>>
>> Is it still possible to incorporate this new information element to
>> the PAWS specification?
>>
>>
>>
>> Thanks and regards,
>>
>> 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.
>> *********************************************************************
>> *********************************************
>>
>> _______________________________________________
>> paws mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/paws
>>
>
> _______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws

________________________________

******************************************************************************************************************
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.
******************************************************************************************************************

-- 
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.

Please consider the environment before printing this email.

---

From: Cesar Gutierrez <[email-masked]>
Date: Tue, 4 Mar 2014 10:59:04 +0000

Luzango,
Support for this parameter is mandatory in ETSI EN 301 598. A device manufacturer that chooses the route of compliance with the ETSI EN to put products in the EU market will have to implement it. Secondly, Ofcom will most likely require WS databases and devices to support the parameter when we set up the licence exemption regime next year.
This doesn't mean it must be supported in PAWS right now. Database providers and device manufacturers using PAWS could implement it as a proprietary addendum. However, it would make a lot of sense to include it in PAWS at this stage in my view.
It would be preferable that the PAWS specification support all functionality required by the current version of the ETSI EN. This version of the ETSI EN is now at the stage of a vote by national standard organisations, and it is very very unlikely to change. Additional functionality cannot be incorporated now - an new work item needs to be started in ETSI for this, and it will take more than a year to get to a stable draft anyway. It is therefore a good point in time to align both documents.
In summary, regulatory-wise it is not an absolute must, but it will be highly advisable.
Regards,
Cesar

From: Luzango Mfupe [mailto:[email-masked]]
Sent: 04 March 2014 06:58
To: Gabor Bajko; Brian Rosen; Cesar Gutierrez
Cc: [email-masked]
Subject: Re: [paws] Revised ETSI standard

Hi Cesar,

>>> Cesar Gutierrez <[email-masked]<mailto:[email-masked]>> 03/03/2014 19:00 >>>
Gabor, Brian,

I suggest the following:

Thanks and regards,
Cesar

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: 27 February 2014 15:51
To: Gabor Bajko
Cc: Cesar Gutierrez; [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] Revised ETSI standard

Brian

On Feb 26, 2014, at 6:22 PM, Gabor Bajko <[email-masked]<mailto:[email-masked]>> wrote:

> <[email-masked]<mailto:[email-masked]>> wrote:
>> Dear all,
>>
>>
>>
>> For more information visit www.ofcom.org.uk<http://www.ofcom.org.uk>
>>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

******************************************************************************************************************
For more information visit www.ofcom.org.uk<http://www.ofcom.org.uk>

This message has been scanned for viruses and dangerous content by MailScanner<http://www.mailscanner.info/>,
and is believed to be clean.

---

From: Vincent Chen <[email-masked]>
Date: Tue, 4 Mar 2014 10:09:31 -0800

Cesar,

Looking at the ETSI EN 301 598 v1.0.9 doc, it looks like this parameter is
optional:

  Within Table 4:  "The default value is 0"
  Note 2: "If the simultaneous channel operation power restriction
parameter is not provided, ..."

So I would list this as an OPTIONAL parameter in section 9.2.2.2 (the IANA
section for ETSI specifics).
Does that sound right?

Thanks.

-vince

On Tue, Mar 4, 2014 at 2:59 AM, Cesar Gutierrez <
[email-masked]> wrote:

>  Luzango,
>
> Support for this parameter is mandatory in ETSI EN 301 598. A device
> manufacturer that chooses the route of compliance with the ETSI EN to put
> products in the EU market will have to implement it. Secondly, Ofcom will
> most likely require WS databases and devices to support the parameter when
> we set up the licence exemption regime next year.
>
> This doesn’t mean it must be supported in PAWS right now. Database
> providers and device manufacturers using PAWS could implement it as a
> proprietary addendum. However, it would make a lot of sense to include it
> in PAWS at this stage in my view.
>
> It would be preferable that the PAWS specification support all
> functionality required by the current version of the ETSI EN. This version
> of the ETSI EN is now at the stage of a vote by national standard
> organisations, and it is very very unlikely to change. Additional
> functionality cannot be incorporated now – an new work item needs to be
> started in ETSI for this, and it will take more than a year to get to a
> stable draft anyway. It is therefore a good point in time to align both
> documents.
>
> *From:* Luzango Mfupe [mailto:[email-masked]]
> *Sent:* 04 March 2014 06:58
> *To:* Gabor Bajko; Brian Rosen; Cesar Gutierrez
> *Cc:* [email-masked]
>
> *Subject:* Re: [paws] Revised ETSI standard
>
>
>
> Hi Cesar,
>
>
>
> What will be the implications regulatory-wise of not including this new
> ETSI requirement in PAWS version 1?, is this not an optional requirement?
>
> Regards
>
> Luzango.
>
> Specification document: Specifies the constraint on the device maximum
> total EIRP, as defined by the ETSI Harmonised Standard  [ETSI-EN-301-598].
> The values are represented by numeric strings,  such as "0", "1", etc.
> Consult the documentation for the specification of the power constrain
> corresponding to each parameter value.
>
>
> From: Rosen, Brian [mailto:[email-masked]<[email-masked]>
> ]
> If you have received this email in error please notify the originator of
> the message and delete it from your system.
>
> 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.
>
> This message is subject to the CSIR's copyright terms and conditions,
> e-mail legal notice, and implemented Open Document Format (ODF) standard.
> This message has been scanned for viruses and dangerous content by
> *MailScanner* <http://www.mailscanner.info/>,
> ------------------------------
>
>
> If you have received this email in error please notify the originator of
> the message and delete it from your system.
>
> 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

---

From: Cesar Gutierrez <[email-masked]>
Date: Tue, 4 Mar 2014 18:56:27 +0000

Vince,

I recognise that the ETSI standard is not very clear on this and people may end up with different interpretations. The intention is that devices must support that parameter. However, if the database does not send it then the device must react as if the default value had been provided.

The rationale is that the power constraint indicated by a value of 1 will only be activated in special occasions, for instance when there is a high concentration of devices. The rest of the time the value would be either 0 or not communicated.

The ETSI standard  deals with device requirements only, and does two things in my view:

1)    it requires that devices support the parameter, and

2)    it specifies the behaviour of the device in both scenarios: 1) the parameter is provided and 2) the parameter is not provided (just in case).

I am not sure whether this makes the parameter optional from the perspective of PAWS.

Regards,
Cesar

From: Vincent Chen [mailto:[email-masked]]
Sent: 04 March 2014 18:10
To: Cesar Gutierrez
Cc: Luzango Mfupe; Gabor Bajko; Brian Rosen; [email-masked]
Subject: Re: [paws] Revised ETSI standard

Cesar,

Looking at the ETSI EN 301 598 v1.0.9 doc, it looks like this parameter is optional:

  Within Table 4:  "The default value is 0"
  Note 2: "If the simultaneous channel operation power restriction parameter is not provided, ..."

So I would list this as an OPTIONAL parameter in section 9.2.2.2 (the IANA section for ETSI specifics).
Does that sound right?

Thanks.

-vince

On Tue, Mar 4, 2014 at 2:59 AM, Cesar Gutierrez <[email-masked]<mailto:[email-masked]>> wrote:
Luzango,
Support for this parameter is mandatory in ETSI EN 301 598. A device manufacturer that chooses the route of compliance with the ETSI EN to put products in the EU market will have to implement it. Secondly, Ofcom will most likely require WS databases and devices to support the parameter when we set up the licence exemption regime next year.
This doesn’t mean it must be supported in PAWS right now. Database providers and device manufacturers using PAWS could implement it as a proprietary addendum. However, it would make a lot of sense to include it in PAWS at this stage in my view.
It would be preferable that the PAWS specification support all functionality required by the current version of the ETSI EN. This version of the ETSI EN is now at the stage of a vote by national standard organisations, and it is very very unlikely to change. Additional functionality cannot be incorporated now – an new work item needs to be started in ETSI for this, and it will take more than a year to get to a stable draft anyway. It is therefore a good point in time to align both documents.
In summary, regulatory-wise it is not an absolute must, but it will be highly advisable.
Regards,
Cesar

From: Luzango Mfupe [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 04 March 2014 06:58
To: Gabor Bajko; Brian Rosen; Cesar Gutierrez
Cc: [email-masked]<mailto:[email-masked]>

Hi Cesar,

Gabor, Brian,

I suggest the following:

Thanks and regards,
Cesar

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: 27 February 2014 15:51
To: Gabor Bajko
Cc: Cesar Gutierrez; [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] Revised ETSI standard

Brian

--
-vince

---

From: Vincent Chen <[email-masked]>
Date: Tue, 4 Mar 2014 18:42:18 -0800

Thanks Cesar,

Here's the proposed language:

      etsiEnSimultaneousChannelOperationRestriction:  Specifies a

         constraint on simultaneous channel operation.  The Database MAY

         include this field within the SpectrumSpec (Section 5.9)

         parameter of the AVAIL_SPECTRUM_RESP (Section 4.4.2) and

         AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4) messages.  If it is

         not provided, the Device MUST assume the value of "0".  If it

         is provided, the Device MUST NOT ignore it.

I believe it captures the intent.

-vince

On Tue, Mar 4, 2014 at 10:56 AM, Cesar Gutierrez <
[email-masked]> wrote:

>  Vince,
>
>
>
> I recognise that the ETSI standard is not very clear on this and people
> may end up with different interpretations. The intention is that devices
> must support that parameter. However, if the database does not send it then
> the device must react as if the default value had been provided.
>
>
>
> The rationale is that the power constraint indicated by a value of 1 will
> only be activated in special occasions, for instance when there is a high
> concentration of devices. The rest of the time the value would be either 0
> or not communicated.
>
>
>
> 2)    it specifies the behaviour of the device in both scenarios: 1) the
> parameter is provided and 2) the parameter is not provided (just in case).
>
>
>
> *From:* Vincent Chen [mailto:[email-masked]]
> *Sent:* 04 March 2014 18:10
> *To:* Cesar Gutierrez
> *Cc:* Luzango Mfupe; Gabor Bajko; Brian Rosen; [email-masked]
>

-- 
-vince

---

From: Cesar Gutierrez <[email-masked]>
Date: Wed, 5 Mar 2014 14:25:43 +0000

Vince – thanks for this, I agree it captures the requirement.

Cesar

From: Vincent Chen [mailto:[email-masked]]
Sent: 05 March 2014 02:42
To: Cesar Gutierrez
Cc: Luzango Mfupe; Gabor Bajko; Brian Rosen; [email-masked]
Subject: Re: [paws] Revised ETSI standard

Thanks Cesar,

On Tue, Mar 4, 2014 at 10:56 AM, Cesar Gutierrez <[email-masked]<mailto:[email-masked]>> wrote:
Vince,

Regards,
Cesar

From: Vincent Chen [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 04 March 2014 18:10
To: Cesar Gutierrez
Cc: Luzango Mfupe; Gabor Bajko; Brian Rosen; [email-masked]<mailto:[email-masked]>

Cesar,

Thanks.

-vince

Hi Cesar,

Gabor, Brian,

I suggest the following:

Thanks and regards,
Cesar

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: 27 February 2014 15:51
To: Gabor Bajko
Cc: Cesar Gutierrez; [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] Revised ETSI standard

Brian

--
-vince

--
-vince