Subject: Re: [paws] Revised ETSI standard

From: Cesar Gutierrez <[email-masked]>
Date: Mon, 3 Mar 2014 17:00:45 +0000

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

---

From: "Luzango Mfupe" <[email-masked]>
Date: Wed, 05 Mar 2014 08:51:35 +0200

Vince, Ceser,
I think Vince's proposed wording in Sects 4.4.2, 4.4.4, & 5.2
sufficiently aligns with the current ETSI draft until we get their
stable version.
-Luzango. 

>>> Vincent Chen <[email-masked]> 05/03/2014 04:42 >>>
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. 

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]

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

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

Brian

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
( http://www.mailscanner.info/) , 
and is believed to be clean. 

Please consider the environment before printing this email. 

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 

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 

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