Subject: [its] Fwd: [ETSI_ITS_NEWS] ITS G5: European Standard for ITS operating in the 5 GHz frequency band published

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 16 Jul 2013 15:15:45 +0200

Hi ITSers,

For your information, ETSI ITS announces it just published this document.

ETSI EN 302 663 V1.2.1
http://www.etsi.org/deliver/etsi_en/302600_302699/302663/01.02.01_60/en_302663v010201p.pdf

One interesting aspect is that, in my humble reading, it does not seem
to prohibit the use of IP over an access layer operating at 5880 MHz at
33dBm EIRP (which is relatively high power, approx. 1km in line of sight).

It and its references insist this particular channel G5-SCH1 is
'dedicated basically for ITS road safety' and that is 'the default
channel for announcing and offering ITS services for safety & road
efficiency under the DCC state ACTIVE and RESTRITIVE of the CCH. The
transmissions of other message-types on the SCH1 are allowed if channel
conditions according to the restrictions in the present document permit.'

This would mean, IMHO, that it still possible to exchange IP packets,
directly between vehicles, over a MAC over a particular PHY at 5880MHz
G5-SCH1, provided some conditions are met.

One other interesting aspect is the changes from an earlier version in 2009:
- the 10Mhz bands around 5910MHz and 5920MHz are now new bands
   allocated for 'ITS road traffic efficiency'. (previously they were
   not dedicated to anything).
- renaming of another channel typically used for Radio LANs.

Alex

-------- Message original --------
Sujet: 	[ETSI_ITS_NEWS] ITS G5: European Standard for ITS operating in
the 5 GHz frequency band published
Date : 	Wed, 10 Jul 2013 11:05:16 +0200
De : 	Martin Arndt <[email-masked]>
Répondre à : 	Martin Arndt <[email-masked]>
Pour : 	<[email-masked]>

Dear all,

Please note that the following European Standard has been published
recently. You can download it for free via the link given below.

*ETSI EN 302 663 V1.2.1
<http://www.etsi.org/deliver/etsi_en/302600_302699/302663/01.02.01_60/en_302663v010201p.pdf>*

Intelligent Transport Systems (ITS);

Access layer specification for Intelligent Transport Systems operating
in the 5 GHz frequency band

This European Standard addresses the European Commission Standardization
Mandate M/453.

Kind regards,

Martin

##############################

Martin ARNDT

Technical Officer

ETSI Operations (OPS)

Committee Support Centre (CSC)

Telephone: +33 4 92 94 42 49

Skype: Mr Wavelength

Email: [email-masked]

Web: http://www.etsi.org

##############################

---

From: "Dr. Hans-Joachim Fischer" <[email-masked]>
Date: Tue, 16 Jul 2013 16:25:19 +0200

There seems to be also a further significant change in this EN compared 
to earlier versions (as it was discussed recently at ETSI). The usage of 
the BRAN band is no more supported. This is a severe drawback for road 
operators who need to use RSUs to connect to passing cars. Allowing the 
BRAN band (which is allowed by the base standard IEEE 802.11 (p-mode) 
and by the ISO 21215 standard (which was published before the EN from 
ETSI covering the same issue)) a RSU could use the CCH to send out 
service advertisement messages (FSAP, ISO 24102-5) which include a 
request to change channel (select a channel in the BRAN band to run the 
session). There we have enough bandwidth to allow for a system where the 
RSU implemented as a multi-channel device which can simultaneously 
operate several orthogonal channels, serving several cars 
simultaneously. ISO 21215 does not restrict its usage to any kind of 
networking protocol.

My two cents on what the end user really needs.

We should be aware that the set of standards from ETSI is designed in a 
way to specify a system around the GeoNetworking / Congestion Control 
Protocols which are covered by IPRs. Luckily nobody needs to implement a 
specific standard as long as there is no related regulation.

Hans-Joachim

Am 16.07.2013 15:15, schrieb Alexandru Petrescu:
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>

-- 
------------------------------------------------------------------------------
ESF online-news:    http://fischer-tech.eu/Feeds/esf.rss
C-ITS online news:  http://its-standards.info/Feeds/cits.rss
------------------------------------------------------------------------------
The information contained in this message is confidential and may be legally privileged. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, dissemination, or reproduction is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
------------------------------------------------------------------------------
Dr. Hans-Joachim Fischer
ESF GmbH
Fichtenweg 9
89143 Blaubeuren
+49 (7344) 175340
+49 (7344) 919123 (Fax)
http://fischer-tech.eu : Main web of ESF GmbH
http://its-standards.eu : News on cooperative ITS standardization
http://its-testing.org : International consultancy for cooperative ITS
------------------------------------------------------------------------------

---

From: "Dr. Hans-Joachim Fischer" <[email-masked]>
Date: Wed, 17 Jul 2013 07:21:06 +0200

This is all true, but only half of the story. You can set MIB parameter 
dot11OCBActivated to true and consequently 
dot11SpectrumManagementRequired to false and nevertheless a station can 
implement spectrum management. It is not said that you need to use a 
functionality of a semiconductor device which implements 802.11. The 
requirement in the harmonized standard is simply that in the BRAN band 
you have to check whether a channel is used before you use it yourself. 
This is why car-to-car communication in the BRAN band is not very 
reasonable, as there are only real peers. For roadside-to-car 
communication you can design your system such that communications always 
is initiated by the roadside ITS station unit and thus the requirment 
for spectrum management in combination with p-mode can be fulfilled.

By the way, car-to-car communications at 5 GHz in channels with 10 MHz 
channel spacing is a dream. In most road traffic scenarios we will face 
severe radio channel congestion problems. Further on, my private 
opinion, car-to-car communication in no way can significantly improve 
road traffic safety. We need autonomeous systems (in-car radar) and 
distribution of trustable traffic information (coming for a trusted 
source which can perform sensor fusion and plausibility checks). 
Distribution of such trusted information via 5 GHz from roadside ITS 
station units, or via LTE, is the solution for day 1 procurement.

Hans-Joachim

Am 17.07.2013 00:24, schrieb Richard Roy:
>
> See below regarding G5C (BRAN usage) ...
>
> > -----Original Message-----
>
> > From:Dr. Hans-Joachim Fischer [mailto:[email-masked]]
>
> > Sent: Tuesday, July 16, 2013 4:25 PM
>
> > To: [email-masked]
>
> > Subject: Re: [its] Fwd: [ETSI_ITS_NEWS] ITS G5: European Standard for ITS
>
> > operating in the 5 GHz frequency band published
>
> >
>
> >
>
> > the BRAN band is no more supported.
>
> [RR>] From 302 663 v1.2.1:
>
> " The requirement of TPC and DFS is covered in IEEE 802.11-2012 [3] 
> through the MIB parameter
>
> dot11SpectrumManagementRequired set to true. When setting the MIB 
> parameter dot11OCBActivated to
>
> true, dot11SpectrumManagementRequired is false, thus the two modes of 
> operation are mutually exclusive.
>
> Hence, communication outside the context of a basic service set is not 
> possible in the ITS-G5C band. But short range
>
> communication with a fixed station in the context of a BSS in 
> combination with spectrum management is possible
>
> (e.g. in a garage) even though not specified for ITS-G5 stations at 
> time of preparation of the present document."
>
> Unfortunately the ETSI guys didn't get it right this time either.  
> There is nothing that states dot11OCBActivated has to be true in the 
> G5C band.  You simply execute normal 802.11 operations in that band 
> using DFS and you are good to go. By writing the blanket statement 
> that for ITS-G5 (meaning ALL G5 channels including G5C) 
> dot11OCBActivated must be set to true, they shot themselves in the 
> foot unnecessarily. (They were warned on many occasions by the 
> way:^))) Again, there is NO REASON why a G5C radio needs to have 
> dot11OCBActivated set to true.  Set it to false for that interface, 
> turn on the SpectrumManagement stuff and anything else you want, and 
> voila ... DFS!
>
> Point is, anyone can ignore the part of the spec that say 
> dot11OCBActivated has to be true in the G5C band and no one should 
> care or complain.
>
> RR
>
> > This is a severe drawback for road
>
> > http://www.etsi.org/deliver/etsi_en/302600_302699/302663/01.02.01_60/en_30
>
> > 2663v010201p.pdf
>
> > >
>
> > >
>
> > > 33dBm EIRP (which is relatively high power, approx. 1km in line of
>
> > > sight).
>
> > >
>
> > > conditions according to the restrictions in the present document
>
> > permit.'
>
> > >
>
> > > One other interesting aspect is the changes from an earlier version in
>
> > > 2009:
>
> > > Sujet:     [ETSI_ITS_NEWS] ITS G5: European Standard for ITS operating
>
> > in
>
> > > Pour :<[email-masked]>
>
> > >
>
> > >
>
> > >
>
> > > Dear all,
>
> > >
>
> > <http://www.etsi.org/deliver/etsi_en/302600_302699/302663/01.02.01_60/en_3
>
> > 02663v010201p.pdf>*
>
> > >
>
> > >
>
> > --------------------------------------------------------------------------
>
> > ----
>
> > ESF online-news:http://fischer-tech.eu/Feeds/esf.rss
>
> > C-ITS online news:http://its-standards.info/Feeds/cits.rss
>
> > --------------------------------------------------------------------------
>
> > ----
>
> > The information contained in this message is confidential and may be
>
> > legally privileged. The message is intended solely for the addressee(s).
>
> > If you are not the intended recipient, you are hereby notified that any
>
> > use, dissemination, or reproduction is strictly prohibited and may be
>
> > unlawful. If you are not the intended recipient, please contact the sender
>
> > by return e-mail and destroy all copies of the original message.
>
> > --------------------------------------------------------------------------
>
> > ----
>
> >Dr. Hans-Joachim Fischer
>
> > ESF GmbH
>
> > Fichtenweg 9
>
> > 89143 Blaubeuren
>
> > +49 (7344) 175340
>
> > +49 (7344) 919123 (Fax)
>
> > --------------------------------------------------------------------------
>
> > ----
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Jul 2013 11:18:27 +0200

Hello Hans-Joachim,

Le 17/07/2013 07:21, Dr. Hans-Joachim Fischer a écrit :
>
> This is all true, but only half of the story. You can set MIB
> parameter dot11OCBActivated to true and consequently
> dot11SpectrumManagementRequired to false and nevertheless a station
> can implement spectrum management. It is not said that you need to
> use a functionality of a semiconductor device which implements
> 802.11. The requirement in the harmonized standard is simply that in
>  the BRAN band you have to check whether a channel is used before you
>  use it yourself.

Ok, that sounds normal to check the channel availability before using
it.  I guess 802.11p doesn't do this, but 802.11a (where BRAN was
originated?) may do it.

Also, I think power limits for 802.11p on BRAN frequencies (5470 to
5725MHz) are still below the limits of some of the control and service
channels on ITS frequencies (around 5880 and around 5900MHz).

Which still makes these two latter channels very attractive for
IP-straight-over-802.11p, compared to any other channel.

> reasonable, as there are only real peers.

I tend to agree the BRAN band is less attractive for car-to-car
communications, for these reasons.

> For roadside-to-car communication you can design your system such
> that communications always is initiated by the roadside ITS station
> unit and thus the requirment for spectrum management in combination
> with p-mode can be fulfilled.

In a sense yes, spectrum management combined with p-mode, and on BRAN
bands, may be useful for car-to-roadside.  But even in car-to-roadside
it may be advantageous to benefit from the p-mode at high power levels
(rather than BRAN lower power levels).

> By the way, car-to-car communications at 5 GHz in channels with 10
> MHz channel spacing is a dream. In most road traffic scenarios we
> will face severe radio channel congestion problems.

Well yes and no.

In a traffic jam where there are as many p devices as cars, obviously
there would be congestion if only pure p-mode were used.  But they go
slower too.

But in other remote areas maybe the vehicles are so distanced and Access
Points absent, that there would be little congestion.

> Further on, my private opinion, car-to-car communication in no way
> can significantly improve road traffic safety.

In this sense, there is difficulty of passing 5GHz-band messages in some
configurations - if a driver can't see, then there's little chance that
the 5GHz-band messages gets through either, voiding the claims of
wireless 'invisible' help to safety.

(we've experienced this at some intersection configurations: once the
line of sight is interrupted by some building or other vehicles, no IP
message gets through.  Once the line of sight is re-established the
communication gets through, but the driver could see as well.)

> We need autonomeous systems (in-car radar)

Well, I am not an expert on non-IP radio communications.

But, I suppose that although in-bumper radars (or above car turning
devices) may be more reliable at their very simple task, may not help
better than p-mode when there is no line of sight.

I think this is so because of their higher and higher frequencies (5,
10, 60, 300GHz).  The higher they are the straighter the line of sight
must be, the worse they get through rain, the shorter the range, etc.

I guess lower frequencies (WiFi 2.4GHz, UHF, and why not 27MHz) would be
better at detecting obstacles and approaching vehicles around obstacles.

Unless of course operators install some form of mirroring in center of
intersections, or equip these traffic lights with wireless repeaters, or
similar.

> and distribution of trustable traffic information (coming for a
> trusted source which can perform sensor fusion and plausibility
> checks). Distribution of such trusted information via 5 GHz from
> roadside ITS station units, or via LTE, is the solution for day 1
> procurement.

This sounds like a requirement.

Whereas 800MHz LTE solutions may already be deployed along some routes
(to be confirmed), the deployment of ITS stations is in its infancy.

When this happens, in order to distribute quickly trusted information
via the 5GHz bands, one may need IPv6 communications, with fixed ITS
stations, but maybe without the long delays of a complex core network.

In this sense, it may be necessary to have simple protocols for quickly
establishing connectivity between the vehicle and the nearest fixed ITS
station.

What do you think?

Alex

>>> To:[email-masked]
>> true, dot11SpectrumManagementRequired is false, thus the two modes
>>  of operation are mutually exclusive.
>>
>> Hence, communication outside the context of a basic service set is
>>  not possible in the ITS-G5C band. But short range
>>
>> There is nothing that states dot11OCBActivated has to be true in
>> the G5C band.  You simply execute normal 802.11 operations in that
>>  band using DFS and you are good to go. By writing the blanket
>> statement that for ITS-G5 (meaning ALL G5 channels including G5C)
>> turn on the SpectrumManagement stuff and anything else you want,
>> and voila ... DFS!
>>
>>>> Email:[email-masked]
>>
>>>>
>>
>>>> Web:http://www.etsi.org
>>
>>>>
>>
The information contained in this message is confidential and may be
legally privileged. The message is intended solely for the addressee(s).
If you are not the intended recipient, you are hereby notified that any
use, dissemination, or reproduction is strictly prohibited and may be
unlawful. If you are not the intended recipient, please contact the
sender by return e-mail and destroy all copies of the original message.
Dr. Hans-Joachim Fischer
> ESF GmbH Fichtenweg 9 89143 Blaubeuren +49 (7344) 175340 +49 (7344)
> 919123 (Fax) http://fischer-tech.eu  : Main web of ESF GmbH
> _______________________________________________ its mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/its
>