Subject: Re: [geonet/its] FYI - ETSI ITS - work on cooperative cruise control, platooning

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 19 Jan 2015 16:52:42 +0100

Hello geonet/its'ers,

ETSI ITS continues work on C-ACC and Platooning.  A f2f meeting a few 
days ago reveals, among other things, a possibility of developping a 
requirement for direct communication between vehicles ("The C-ACC system 
shall be able to receive data from other vehicle ITS-S or road side ITS-S").

What do you think?

Alex

Le 24/10/2014 17:16, Alexandru Petrescu a écrit :
> Hello geonet/itsers,
>
> ETSI ITS group is an SDO in Europe.  They produced many standards in the
> past for vehicular communications, e.g. ETSI ITS geo-networking among
> others.
>
> ETSI ITS recently agreed to start working on pre-standardization items
> called "Cooperative Cruise Control" and "Platooning".  These two
> applications make automobiles (and trucks) talk to each other
> continuously to keep speed constant.  It helps relieve automobile driver
> stress in jam situation or reduce gas consumption by 'platooning'.
>
> Currently the focus is on requirements including communication
> requirements.
>
> In my oppinion, and this is why I forward it to this group, establishing
> direct IP connections between vehicles may open paths for exchanging IP
> data containing speed/location and trigger a control process of adapting
> the speed.  One already controls vehicles by sending IP data to them,
> from the infrastructure.  It would be a simple matter for IP experts to
> send that same data from other vehicle, without going to the
> infrastructure.
>
> Thoughts?
>
> Yours,
>
> Alex
>
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 20 Jan 2015 08:20:25 +0000

This certainly sounds interesting, to the extent that the IETF can add value to the work done in ETSI with our specific expertise.  

Question - how does the ETSI work relate to IEEE 1609 and IEEE 802.11p? 

Thanks and Regards,

Dan

> -----Original Message-----
> From: its [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
> Sent: Monday, January 19, 2015 5:53 PM
> To: [email-masked]
> Subject: Re: [geonet/its] FYI - ETSI ITS - work on cooperative cruise control,
> platooning
> 
> Hello geonet/its'ers,
> 
> ETSI ITS continues work on C-ACC and Platooning.  A f2f meeting a few days
> ago reveals, among other things, a possibility of developping a requirement
> for direct communication between vehicles ("The C-ACC system shall be able
> to receive data from other vehicle ITS-S or road side ITS-S").
> 
> What do you think?
> 
> Alex
> 
> > ETSI ITS group is an SDO in Europe.  They produced many standards in
> > the past for vehicular communications, e.g. ETSI ITS geo-networking
> > among others.
> >
> > continuously to keep speed constant.  It helps relieve automobile
> > driver stress in jam situation or reduce gas consumption by 'platooning'.
> >
> > In my oppinion, and this is why I forward it to this group,
> > establishing direct IP connections between vehicles may open paths for
> > exchanging IP data containing speed/location and trigger a control
> > process of adapting the speed.  One already controls vehicles by
> > sending IP data to them, from the infrastructure.  It would be a
> > simple matter for IP experts to send that same data from other
> > vehicle, without going to the infrastructure.
> >
> > Thoughts?
> >
> > Yours,
> >
> > Alex
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mail
> > man_listinfo_its&d=AwIF-
> g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQ
> >
> zvlsiLQfucBXRucPvdrphpBsFA&m=7phbjG6Z2qP7PNOqvxHWe2s55dJcKMrSyf
> GAFrrU-
> > ms&s=GtUI3ETS930uY9YD5VlodU3wr4wfc4BXjjteZu_242c&e=
> >
> >
> 
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_its&d=AwIF-
> g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd
> rphpBsFA&m=7phbjG6Z2qP7PNOqvxHWe2s55dJcKMrSyfGAFrrU-
> ms&s=GtUI3ETS930uY9YD5VlodU3wr4wfc4BXjjteZu_242c&e=

---

From: Jérôme Härri <[email-masked]>
Date: Tue, 20 Jan 2015 09:48:48 +0100

Hi Dan,

ETSI does not relate to IEEE 1609, as it proposes its own architecture,
although having similar goals and principles. The ETSI architecture is also
based on IEEE 802.11p (a.k.a 802.11-2012 OCB @ 5GHz nowadays) but under a
specific denomination: ETSI ITS G5. As WAVE, the ETSI architecture provide
an IPv6 stack as well as a non-IP stack (called GeoNetworking).  

The requirement is indeed described. Now the question is whether IP is
required in this specific case(s). But at this time, the ETSI requires use
case formulations (as well as communication requirements from these use
cases), so inputs from the IETF ITS WG would of course be welcomed.

You should contact Lan Lin and Katrin Sjöberg, who are the two rapporteurs
for the CACC and platooning respectively. 

Best Regards,

Jérôme

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Tuesday 20 January 2015 09:20
To: Alexandru Petrescu; [email-masked]
Subject: Re: [geonet/its] FYI - ETSI ITS - work on cooperative cruise
control, platooning

This certainly sounds interesting, to the extent that the IETF can add value
to the work done in ETSI with our specific expertise.  

Thanks and Regards,

Dan

> Subject: Re: [geonet/its] FYI - ETSI ITS - work on cooperative cruise 
> control, platooning
> 
> Hello geonet/its'ers,
> 
> requirement for direct communication between vehicles ("The C-ACC 
> system shall be able to receive data from other vehicle ITS-S or road side
ITS-S").
> > ETSI ITS recently agreed to start working on pre-standardization 
> > items called "Cooperative Cruise Control" and "Platooning".  These 
> > two applications make automobiles (and trucks) talk to each other 
> > establishing direct IP connections between vehicles may open paths 
> > for exchanging IP data containing speed/location and trigger a 
> > control process of adapting the speed.  One already controls 
> > vehicles by sending IP data to them, from the infrastructure.  It 
> > would be a simple matter for IP experts to send that same data from 
> > other vehicle, without going to the infrastructure.
> >
> > Thoughts?
> >
> > Yours,
> >
> > Alex
> >

---

From: Rex Buddenberg <[email-masked]>
Date: Tue, 20 Jan 2015 11:23:23 -0800

Dan,

Let me try to complement Jerome's and others replies. 

There are two (at least) tacit philosophies here.  With lots of bits and
pieces that may or may not fit together.

The more 'IETF view' is 'extend the internet to mobile platforms'.  An
example would be an instrumented ambulance where casualty vital signs
would be telemetered to the hospital ER and the vehicle's position would
be reported to the 911 dispatcher.  This is very much an internetworking
point of view where IP is the conventional layer 3 solution.  

The WAVE set of protocols eschews IP (and TCP) and is much more narrowly
focused.  The idea is vehicle-to-vehicle with collision avoidance in the
requirements set.  The repeated references in the e-mail to a specific
flavor of ethernet and the eschewing of both TCP and IP in the layer 3-5
protocol space, and the rather tight apparent coupling to a specific
application show a quite different philosophy.  
     A use case here would be the same ambulance in the illustration
above broadcasting its position and a 'virtual siren' message.  
     I've poked at this paradigm a few times over the last year or so
and don't quite swallow it all.  By eschewing IP, the protocol
apparently denies internetworking (meaning no LAN in the vehicle to
internetwork with the radio link).  And if you take the label 'TCP' out
of the discussion but ask about the features (e.g. reliable delivery)
you get a feature list that sounds eerily like TCP.  The geonetworking
discussion has the same kind of disquiets: if you code lat/long into a
layer 3 datagram, then how do you read it at layer 6-7 without creating
an insecurity vector (maybe we should be encoding the same data, in the
same format, as part of the MIB?)
     In general, the vehicle-to-vehicle discussion (at least on this
list) seems to confuse the 'what' (e.g. traffic alerts) with the
'how' (e.g. gotta use xyz flavor of ethernet with no internetworking).  
     Not losing any sleep over this -- the protocol discussion routinely
allows a dual stack with a conventional IP stack alongside the WAVE
stack.  So the virtual ambulance siren example does not exclude the
instrumented ambulance example.  

The above is my take on what I've seen on the list (with a dollop of my
own opinions and experiences plowed in).  I've no problem whatsoever
with the notion of a self-driving automobile and am a firm believer in
better information having the potential for a safer environment.

---

From: Jérôme Härri <[email-masked]>
Date: Wed, 21 Jan 2015 10:17:00 +0100

Dear Dick, dear All

Nice that we could get various detailed feedback. And I agree with the need
to evaluate the required changes in the IPv6 suite for such application. But
I still would like to play the devil's advocate and suggest that we should
really differentiate the 'how' from the 'why'. 

With modifications (if any), it is clear that IP could be allocated by both
ETSI and WAVE to handle C-ACC and Platooning.  The question (again playing
the devil's advocate here..) is 'why would we need IP packets for C-ACC and
Platooning'??  
We need to build use cases before we even start thinking how this could be
done. According to the ETSI definition of C-ACC and Platooning, we are
talking of local communication (either between a platoon leader and its
followers, or between immediate C-ACC vehicles). As Dick mentioned, we could
use Facilities messages transmitted on CALM FAST, ETSI GeoNet, WAVE SMP or
any other non-IP protocol as well. One potential benefit from IP in this
context would be if we use heterogeneous technologies (LTE-D, DSRC, Visible
Light Comm, etc..) and expect service continuity...maybe there are others...

Best Regards,

Jérôme

-----Original Message-----
From: Richard Roy [mailto:[email-masked]] 
Sent: Wednesday 21 January 2015 04:10
To: 'Rex Buddenberg'; 'Jérôme Härri'
Cc: 'Romascanu, Dan (Dan)'; 'Alexandru Petrescu'; [email-masked]
Subject: RE: [geonet/its] FYI - ETSI ITS - work on cooperative cruise
control, platooning

A few clarifications might be useful.

First, the 1609 set of standards coupled with IEEE 802.11 at 5.9GHz form
what is commonly referred to in the US as WAVE, and devices built conformant
to these standards are WAVE devices (see 1609.0).  IPv6 is explicitly
mentioned in 1609.3 (the networking services standard where you'll find the
specifications for the WAVE Short Message Protocol (WSMP) and the WAVE
Service Advertisement (WSA), both of which are undergoing revision now). In
fact, included in the WSA is an (optional) WAVE Router Advertisement (WRA)
which contains sufficient information for an application in a WAVE device to
correctly form an IPv6 packet for transmission to the indicated service
provider using the indicated RF resources.  SLAAC is used by the mobile
device to create a valid IPv6 address from the IPv6 pin the WRA.

Thus, on the mobile side, there is not much to do except to implement the
various IPv6 functions necessary.  Maintaining an IP-based session while
moving from RSU to RSU travelling down the freeway is another story which is
still being worked on in the IETF as I understand it.  

As far as ETSI is concerned, they are developing standards, built on the ISO
21217 architecture of the ITS station (ITS-S), which are largely
concentrated on V2V communications for safety applications.  Nothing they
are doing prohibits the use of IPv6 at the network layer and all the
transport protocols that are associated therewith.  Furthermore, nothing
prevents implementers, such as those working on the Corridor project, from
implementing ISO's Fast Network & Transport Protocol (which is being
harmonized with 1609.3 WSMP at this moment) as a more effective and
efficient protocol for V2V safety messages (esp. CAMs/DENMs/BSMs).

That said, the question for the geonet/its group is/should be: what
modifications, if any, to the IPv6 suite of protocols might be necessary to
support the use of IPv6 networking in platooning and C-ACC applications.
All the issues surrounding the data to be exchanged to implement these
services are application considerations and are therefore outside the scope
of the networking layer.  

Hope this helps somewhat.

Cheers,

RR

> From: Rex Buddenberg [mailto:[email-masked]]
> Sent: Tuesday, January 20, 2015 11:23 AM
> To: Jérôme Härri
> Cc: 'Romascanu, Dan (Dan)'; 'Alexandru Petrescu'; [email-masked]
> There are two (at least) tacit philosophies here.  With lots of bits 
> and pieces that may or may not fit together.
> 
> would be telemetered to the hospital ER and the vehicle's position 
> would be reported to the 911 dispatcher.  This is very much an 
> internetworking point of view where IP is the conventional layer 3
solution.
> 
> The WAVE set of protocols eschews IP (and TCP) and is much more 
> narrowly focused.  The idea is vehicle-to-vehicle with collision 
> avoidance in the requirements set.  The repeated references in the 
> e-mail to a specific flavor of ethernet and the eschewing of both TCP 
> and IP in the layer 3-5 protocol space, and the rather tight apparent 
> coupling to a specific application show a quite different philosophy.
> internetwork with the radio link).  And if you take the label 'TCP' 
> out of the discussion but ask about the features (e.g. reliable 
> delivery) you get a feature list that sounds eerily like TCP.  The 
> geonetworking discussion has the same kind of disquiets: if you code 
> lat/long into a layer 3 datagram, then how do you read it at layer 6-7 
> without creating an insecurity vector (maybe we should be encoding the 
> same data, in the same format, as part of the MIB?)
> list) seems to confuse the 'what' (e.g. traffic alerts) with the 'how' 
> (e.g. gotta use xyz flavor of ethernet with no internetworking).
>      Not losing any sleep over this -- the protocol discussion 
> routinely allows a dual stack with a conventional IP stack alongside 
> the WAVE stack.  So the virtual ambulance siren example does not 
> exclude the instrumented ambulance example.
> 
> The above is my take on what I've seen on the list (with a dollop of 
> my own opinions and experiences plowed in).  I've no problem 
> whatsoever with the notion of a self-driving automobile and am a firm 
> believer in better information having the potential for a safer
environment.
> > ETSI does not relate to IEEE 1609, as it proposes its own 
> > architecture, although having similar goals and principles. The ETSI 
> > architecture is
> also
> > based on IEEE 802.11p (a.k.a 802.11-2012 OCB @ 5GHz nowadays) but 
> > under
> a
> > The requirement is indeed described. Now the question is whether IP 
> > is required in this specific case(s). But at this time, the ETSI 
> > requires
> use
> > case formulations (as well as communication requirements from these 
> > use cases), so inputs from the IETF ITS WG would of course be welcomed.
> >
> > Subject: Re: [geonet/its] FYI - ETSI ITS - work on cooperative 
> > cruise control, platooning
> >
> > This certainly sounds interesting, to the extent that the IETF can 
> > add
> value
> > > Subject: Re: [geonet/its] FYI - ETSI ITS - work on cooperative 
> > > cruise control, platooning
> > >
> > > Hello geonet/its'ers,
> > >
> > > ETSI ITS continues work on C-ACC and Platooning.  A f2f meeting a 
> > > few days ago reveals, among other things, a possibility of 
> > > developping a requirement for direct communication between 
> > > vehicles ("The C-ACC system shall be able to receive data from 
> > > other vehicle ITS-S or road
> side
> > ITS-S").
> > >
> > > What do you think?
> > >
> > > Alex
> > >
> > > > ETSI ITS group is an SDO in Europe.  They produced many 
> > > > standards in the past for vehicular communications, e.g. ETSI 
> > > > ITS geo-networking among others.
> > > >
> > > > items called "Cooperative Cruise Control" and "Platooning".  
> > > > These two applications make automobiles (and trucks) talk to 
> > > > each other continuously to keep speed constant.  It helps 
> > > > relieve automobile driver stress in jam situation or reduce gas 
> > > > consumption by
> > 'platooning'.
> > > >
> > > > establishing direct IP connections between vehicles may open 
> > > > paths for exchanging IP data containing speed/location and 
> > > > trigger a control process of adapting the speed.  One already 
> > > > controls vehicles by sending IP data to them, from the 
> > > > infrastructure.  It would be a simple matter for IP experts to 
infrastructure.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 21 Jan 2015 14:26:57 +0100

Le 21/01/2015 10:17, Jérôme Härri a écrit :
> Dear Dick, dear All
>
> Nice that we could get various detailed feedback. And I agree with
> the need to evaluate the required changes in the IPv6 suite for such
> application. But I still would like to play the devil's advocate and
> suggest that we should really differentiate the 'how' from the
> 'why'.
>
> With modifications (if any), it is clear that IP could be allocated
> by both ETSI and WAVE to handle C-ACC and Platooning.  The question
> (again playing the devil's advocate here..) is 'why would we need IP
> packets for C-ACC and Platooning'??

I think this is a good question that deserves discussion.

My point of view is that C-ACC and Platooning are applications.  For
example, a java client in one vehicle connects to a server in the nearby
vehicle and sends it its current location and speed.  To have it work
that easily, one would have to first establish and maintain an IP path
between the two LANs in each vehicle.  This is currently an unknown,
although several people on the list have some precise - and contrasting
- idea, about how to do it.

But still C-ACC (cooperative cruise control) and Platooning are
applications from my point of view.

I wonder what the others think of why we need IP packets for C-ACC and
Platooning?

> We need to build use cases before we even start thinking how this
> could be done.

I agree.

In that sense, we may discuss use cases.  Several drafts were published
in this list about use-cases.  We need to write such a use-case draft
which focuses on C-ACC and Platooning, and other use-cases which may
need the same vehicle-to-vehicle communication technology (some that
come to mind very quickly are: the ambulance use-case, and the
"Sentinelle" system used since 2005 by Dakar vehicles to signal their
presence to each other).

> According to the ETSI definition of C-ACC and Platooning, we are
> talking of local communication (either between a platoon leader and
> its followers, or between immediate C-ACC vehicles).

YEs, I agree.  We need to list these cases.

> As Dick mentioned, we could use Facilities messages transmitted on
> CALM FAST, ETSI GeoNet, WAVE SMP or any other non-IP protocol as
> well.

YEs, we should.

> One potential benefit from IP in this context would be if we use
> heterogeneous technologies (LTE-D, DSRC, Visible Light Comm, etc..)
> and expect service continuity...

I agree.  We should list these technologies as potential support to
transmit data.

> maybe there are others...

YEs.  I wonder what are the other use-cases akin to C-ACC and
Platooning, needing V2V concepts, that members of this list are working
with?

Let us work on these use-cases.

Alex

>
> Best Regards,
>
> Jérôme
>
>
>
> -----Original Message----- From: Richard Roy
> [mailto:[email-masked]] Sent: Wednesday 21 January 2015 04:10
> To: 'Rex Buddenberg'; 'Jérôme Härri' Cc: 'Romascanu, Dan (Dan)';
> 'Alexandru Petrescu'; [email-masked] Subject: RE: [geonet/its] FYI -
> ETSI ITS - work on cooperative cruise control, platooning
>
> First, the 1609 set of standards coupled with IEEE 802.11 at 5.9GHz
> form what is commonly referred to in the US as WAVE, and devices
> built conformant to these standards are WAVE devices (see 1609.0).
> IPv6 is explicitly mentioned in 1609.3 (the networking services
> standard where you'll find the specifications for the WAVE Short
> Message Protocol (WSMP) and the WAVE Service Advertisement (WSA),
> both of which are undergoing revision now). In fact, included in the
> WSA is an (optional) WAVE Router Advertisement (WRA) which contains
> sufficient information for an application in a WAVE device to
> correctly form an IPv6 packet for transmission to the indicated
> service provider using the indicated RF resources.  SLAAC is used by
> the mobile device to create a valid IPv6 address from the IPv6 pin
> the WRA.
>
> Thus, on the mobile side, there is not much to do except to
> implement the various IPv6 functions necessary.  Maintaining an
> IP-based session while moving from RSU to RSU travelling down the
> freeway is another story which is still being worked on in the IETF
> as I understand it.
>
> As far as ETSI is concerned, they are developing standards, built on
> the ISO 21217 architecture of the ITS station (ITS-S), which are
> largely concentrated on V2V communications for safety applications.
> Nothing they are doing prohibits the use of IPv6 at the network
> layer and all the transport protocols that are associated therewith.
>  Furthermore, nothing prevents implementers, such as those working
> on the Corridor project, from implementing ISO's Fast Network &
> Transport Protocol (which is being harmonized with 1609.3 WSMP at
> this moment) as a more effective and efficient protocol for V2V
> safety messages (esp. CAMs/DENMs/BSMs).
>
> modifications, if any, to the IPv6 suite of protocols might be
> necessary to support the use of IPv6 networking in platooning and
> C-ACC applications. All the issues surrounding the data to be
> exchanged to implement these services are application considerations
> and are therefore outside the scope of the networking layer.
>
>> -----Original Message----- From: Rex Buddenberg
>> [mailto:[email-masked]] Sent: Tuesday, January 20, 2015
>> 11:23 AM To: Jérôme Härri Cc: 'Romascanu, Dan (Dan)'; 'Alexandru
>> Petrescu'; [email-masked] Subject: Re: [geonet/its] FYI - ETSI ITS -
>> work on cooperative cruise control, platooning
>>
>> Dan,
>>
>> There are two (at least) tacit philosophies here.  With lots of
>> bits and pieces that may or may not fit together.
>>
>> The more 'IETF view' is 'extend the internet to mobile platforms'.
>> An example would be an instrumented ambulance where casualty vital
>> signs would be telemetered to the hospital ER and the vehicle's
>> position would be reported to the 911 dispatcher.  This is very
>> much an internetworking point of view where IP is the conventional
>> layer 3
> solution.
>>
>>  e-mail to a specific flavor of ethernet and the eschewing of both
>>  TCP and IP in the layer 3-5 protocol space, and the rather tight
>> apparent coupling to a specific application show a quite different
>> philosophy. A use case here would be the same ambulance in the
>> illustration above broadcasting its position and a 'virtual siren'
>> message. I've poked at this paradigm a few times over the last year
>> or so and don't quite swallow it all.  By eschewing IP, the
>> protocol apparently denies internetworking (meaning no LAN in the
>> vehicle to internetwork with the radio link).  And if you take the
>> label 'TCP' out of the discussion but ask about the features (e.g.
>> reliable delivery) you get a feature list that sounds eerily like
>> TCP.  The geonetworking discussion has the same kind of disquiets:
>> if you code lat/long into a layer 3 datagram, then how do you read
>> it at layer 6-7 without creating an insecurity vector (maybe we
>> should be encoding the same data, in the same format, as part of
>> the MIB?) In general, the vehicle-to-vehicle discussion (at least
>> on this list) seems to confuse the 'what' (e.g. traffic alerts)
>> with the 'how' (e.g. gotta use xyz flavor of ethernet with no
>> internetworking). Not losing any sleep over this -- the protocol
>> discussion routinely allows a dual stack with a conventional IP
>> stack alongside the WAVE stack.  So the virtual ambulance siren
>> example does not exclude the instrumented ambulance example.
>>
>> The above is my take on what I've seen on the list (with a dollop
>> of my own opinions and experiences plowed in).  I've no problem
>> whatsoever with the notion of a self-driving automobile and am a
>> firm believer in better information having the potential for a
>> safer
> environment.
>>
>>
>>
>>
>>
>>> architecture, although having similar goals and principles. The
>>> ETSI architecture is
>> also
>>> specific denomination: ETSI ITS G5. As WAVE, the ETSI
>>> architecture
>> provide
>>> The requirement is indeed described. Now the question is whether
>>> IP is required in this specific case(s). But at this time, the
>>> ETSI requires
>> use
>>> case formulations (as well as communication requirements from
>>> these use cases), so inputs from the IETF ITS WG would of course
>>> be welcomed.
>>>
>>> -----Original Message----- From: its
>>> [mailto:[email-masked]] On Behalf Of Romascanu, Dan
>> (Dan)
>>> Sent: Tuesday 20 January 2015 09:20 To: Alexandru Petrescu;
>>> [email-masked] Subject: Re: [geonet/its] FYI - ETSI ITS - work on
>>> cooperative cruise control, platooning
>>>
>>> This certainly sounds interesting, to the extent that the IETF
>>> can add
>> value
>>>> -----Original Message----- From: its
>>>> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
>>>> Sent: Monday, January 19, 2015 5:53 PM To: [email-masked]
>>>> ETSI ITS continues work on C-ACC and Platooning.  A f2f
>>>> meeting a few days ago reveals, among other things, a
>>>> possibility of developping a requirement for direct
>>>> communication between vehicles ("The C-ACC system shall be able
>>>> to receive data from other vehicle ITS-S or road
>> side
>>> ITS-S").
>>>>
>>>> What do you think?
>>>>
>>>> Alex
>>>>
>>>>> ETSI ITS recently agreed to start working on
>>>>> pre-standardization items called "Cooperative Cruise
>>>>> Control" and "Platooning". These two applications make
>>>>> automobiles (and trucks) talk to each other continuously to
>>>>> keep speed constant.  It helps relieve automobile driver
>>>>> Currently the focus is on requirements including
>>>>> communication requirements.
>>>>>
>>>>> infrastructure.  It would be a simple matter for IP experts
>>>>> to send that same data from other vehicle, without going to
>>>>> the
> infrastructure.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Yours,
>>>>>
>>>>> Alex
>>>>>
>>>>> _______________________________________________ its mailing
>>>>> list [email-masked]
GAFrrU-
>>>> _______________________________________________ its mailing
>>>> list [email-masked]
>>> _______________________________________________ its mailing list
>>>  [email-masked] https://www.ietf.org/mailman/listinfo/its
>>>
>>> _______________________________________________ its mailing list
>>>  [email-masked] https://www.ietf.org/mailman/listinfo/its
>>
>>
>
>
>
>
>

---

From: Jérôme Härri <[email-masked]>
Date: Wed, 21 Jan 2015 15:36:08 +0100

Dear Alex,

example, a java client in one vehicle connects to a server in the nearby
vehicle and sends it its current location and speed.  To have it work that 
> easily, one would have to first establish and maintain an IP path between
the two LANs in each vehicle.  This is currently an unknown, although
several people on the list have some precise - and contrasting
Platooning?
> We need to build use cases before we even start thinking how this 

Thanks for your feedback..

They are applications indeed, but it does not mean it must be IP. The Road
Hazard Warning is an application, but does not work on IP, and if I am not
wrong, the CORRIDOR project provides platooning applications that is not
based on IP but rather on CALM FAST. 

But it is important to describe the application in terms of functional
elements (client, server, information flows, interfaces etc...) and then see
if IP is required or not. Just one point: Platooning could work based on a
client-server paradigm, as the platoon leader will gather and manage its
platoon. As for C-ACC, it is less clear, as the ETSI definition of C-ACC is
that it is a fully distributed system: there is no leader, and as such, a
client-server paradigm might be more difficult.

My suggestion if we want to go further into that direction (and not spend
our life exchanging ideas and point of views over a mailing list ;-) ) is to
gather the related documents on C-ACC and Platooning applications in the
respective ITS standardization entities (ETSI, ISO, WAVE (if any), SAE,..),
talk to the rapporteurs of these documents and report a digest in an
document.  I can do this task from the ETSI side (actually contacting the
two ETSI rapporteurs that I previously named). Maybe others with ties at ISO
or WAVE could do the same...

Best Regards,

Jérôme

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 21 Jan 2015 17:22:41 +0100

> or WAVE could do the same...

At ISO there is something about vehicle-to-vehicle communications and I 
can ask a person in charge to provide a summary of it.

However, I am not sure whether at IEEE WAVE there is anything that may 
pertain to Platooning and C-ACC, or V2V?  We need to identify somebody 
to find out.

Also, I dont think SAE has any activity about C-ACC and Platooning, or 
V2V.  We need to identify somebody to find out.

Alex

---

From: Rex Buddenberg <[email-masked]>
Date: Wed, 21 Jan 2015 19:51:01 -0800

RR,

This time I disagree with your analysis on a quite specific protocol
point.

> imagine using MAC bridging to accomplish host-to-host comms

Bridging is a Bad Idea, especially in this kind of application space
where at least some applications will be mission critical.

Ethernet frames (used by WiFi as well) lack the Time To Live value that
exists in both IPv4 and IPv6 datagrams.  So if they get into a loop,
they will ring around the bridged set of LANs forever.  In order to
control this situation, IEEE 802.1 spanning tree algorithm was
generated.  Spanning tree changes the loop into a tree, thereby shutting
off the ringing.  But it does that by 'breaking' bridging associations
-- effectively breaking links.  What that does is chop off alternate
routes -- that are critical to the high availability and what makes the
internet so resilient. 
    When ethernet became popular for building and campus LANs (in the
'80s) some organizations had phobias about routers (and therefore IP) so
they built these large bridged networks.  They're all gone now ...
there's a good reason.  

b

On Wed, 2015-01-21 at 19:13 -0800, Richard Roy wrote:
> All,
> 
> Excellent analysis Jerome.  While it may be possible to use IPv6 for these
> applications, it may be overkill.  Noting that there will be distributed
> implementations of ITS stations, since these are point to point like apps,
> one could easily imagine using MAC bridging to accomplish host-to-host comms
> on the "wireless LAN connecting hosts inside ITS stations" without the need
> for IP networking. This is one very strong argument for ditching LPD (LLC
> Protocol Discrimination)in favor of EPD (Ethertype Protocol Discrimination)
> in 5.9 radios, but that's a story for another day;^))
> 
> As for WAVE/SAE/ISO and C-ACC and platooning, the IEEE 1609 WG does not deal
> with apps generally (though 1609.11 was developed in the WG as a special
> case).  SAE has taken on the task of looking into messages and message sets
> for various V2V and V2I apps, not just core safety apps, and has decided to
> work with ETSI TS ITS on three apps (vulnerable road users, C-ACC, and
> platooning) so whatever comes out of ETSI TC ITS will presumably joint work
> with SAE.  Noting that ISO's work in ACC is in TC204 WG14 and the effort
> there is largely autonomous, no comms, just radars/lidar/etc. but that's
> slowly changing.  
> 
> So, at present, the good news is that there's currently not that much action
> in these three areas for external bodies to coordinate.  As far as VRUs go,
> the bad news is there is not that much action to coordinate.  Avoiding
> collisions with road workers and other pedestrians is a day-one critical
> safety app and the fact that people are just now starting to look at this is
> somewhat disconcerting to say the least :^(((  Oh well ...
> 
> Cheers,
> 
> RR
> 
> > From: Jérôme Härri [mailto:[email-masked]]
> > Sent: Wednesday, January 21, 2015 6:36 AM
> > To: 'Alexandru Petrescu'; [email-masked]; 'Rex Buddenberg'
> > Cc: 'Romascanu, Dan (Dan)'; [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Jan 2015 13:32:57 +0100

Le 20/01/2015 09:20, Romascanu, Dan (Dan) a écrit :
> add value to the work done in ETSI with our specific expertise.
>

Hello Dan,

With respect to 802.11p, it is good to know that IP runs over 802.11p
links in a straightforward manner.

Whether two vehicles directly exchange CAM messages, or UDP/IP messages,
is some times a matter of programmer's expertise and allocated budget.

A seasoned programmer with much budget and high stakes at SDOs will
acquire expensive hardware, training and binary libraries, and will
realize CAM/DENM/11p prototypes.

A novice programmer on low budget with visceral drive in computing will
acquire cheapest hardware, open source libraries and self-training, and
will realize UDP/IP/11p prototypes.

Tolerant implementations in vehicular Mobile Routers receive and
interpret both CAM/DENM messages _and_ UDP/IP/80211p messages.

Alex

>
> Thanks and Regards,
>
> Dan
>
>
>> -----Original Message----- From: its [mailto:[email-masked]]
>> On Behalf Of Alexandru Petrescu Sent: Monday, January 19, 2015
>> 5:53 PM To: [email-masked] Subject: Re: [geonet/its] FYI - ETSI ITS -
>> other vehicle ITS-S or road side ITS-S").
>>
>> What do you think?
>>
>> Alex
>>
>>>  [email-masked] https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__www.ietf.org_mail
>>> man_listinfo_its&d=AwIF-
>> [email-masked] https://urldefense.proofpoint.com/v2/url?u=https-

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Jan 2015 13:04:42 +0100

Le 24/01/2015 10:31, Richard Roy a écrit :
> Alex,
>
> Answers to your questions:
>
> 1) ISO has been doing V2V comms for over 20 years in TC204 WG16 ( it
> used to be called CALM).  Steve Sprouffske is the current Convener of
> WG16.  I have been involved for the last 10 years working on ALL the
> related ISO standards with a few other very good people.
>
> 2) IEEE 1609 (WAVE) doesn't deal with apps as I mentioned before
> (1609.11 aside).

Note: it may not deal with apps in the sense that 1609 people think of
what apps are.  But, if one asks Internet people whether a particular
functionality is an app, then the perspective is different.

E.g. whereas IEEE P1609.11 "OTA payment exchange protocol" is not an
application in the eyes of IEEE people, in the eyes of Internet people
it is a pure application - it may have been called 
"https-over-IPv6-over-80211p ecommerce with an Android browser".

This apparent confusion is relevant to 'app layer' but also to 
'networking layer', and the others.

> It has developed the networking and security services standards for
> V2V and V2I at 5.9GHz. (I have been working on these standards for 10
> years as well.)

Here we talk services.

I think 'services' are the same thing as 'applications'.

> 3) SAE has just approved the joint work on VRU, C-ACC, and platooning
> with ETSI.  The work is to be done in the SAE DSRC TC (of which I
> have been a member for about 5 years), and Jim Meisner is the current
> Chairman of the DSRC TC.

Thanks!

We have to contact them proposing to synthesize the current SAE work on 
C-ACC and platooning by co-authoring an Internet Draft.

Yours,

Alex

>
> Cheers,
>
> RR
>
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:[email-masked]] Sent: Wednesday, January 21,
>> 2015 8:23 AM To: Jérôme Härri; [email-masked]; 'Rex
>> Buddenberg' Cc: 'Romascanu, Dan (Dan)'; [email-masked] Subject: Re:
>> [geonet/its] FYI - ETSI ITS - work on cooperative cruise control,
>> platooning
>>
>>> example, a java client in one vehicle connects to a server in the
>>> nearby vehicle and sends it its current location and speed.  To
>>> have it work
>> that
>>>> easily, one would have to first establish and maintain an IP
>>>> path
>> between
>>> the two LANs in each vehicle.  This is currently an unknown,
>>>> We need to build use cases before we even start thinking how
>>>> this could be done.
>>>
>>> They are applications indeed, but it does not mean it must be IP.
>>> The
>> Road
>>> Hazard Warning is an application, but does not work on IP, and if
>>> I am
>> not
>>> wrong, the CORRIDOR project provides platooning applications that
>>> is not based on IP but rather on CALM FAST.
>>>
>>> But it is important to describe the application in terms of
>>> functional elements (client, server, information flows,
>>> interfaces etc...) and then
>> see
>>> if IP is required or not. Just one point: Platooning could work
>>> based on
>> a
>>> client-server paradigm, as the platoon leader will gather and
>>> manage its platoon. As for C-ACC, it is less clear, as the ETSI
>>> definition of C-ACC
>> is
>>> that it is a fully distributed system: there is no leader, and as
>>> such,
>> a
>>> My suggestion if we want to go further into that direction (and
>>> not
>> spend
>>> our life exchanging ideas and point of views over a mailing list
>>> ;-) )
>> is to
>>> gather the related documents on C-ACC and Platooning applications
>>> in the respective ITS standardization entities (ETSI, ISO, WAVE
>>> (if any),
>> SAE,..),
>>> talk to the rapporteurs of these documents and report a digest in
>>> an document.  I can do this task from the ETSI side (actually
>>> contacting
>> the
>>> two ETSI rapporteurs that I previously named). Maybe others with
>>> ties at
>> ISO
>> At ISO there is something about vehicle-to-vehicle communications
>> and I can ask a person in charge to provide a summary of it.
>>
>> However, I am not sure whether at IEEE WAVE there is anything that
>> may pertain to Platooning and C-ACC, or V2V?  We need to identify
>> somebody to find out.
>>
>> Also, I dont think SAE has any activity about C-ACC and Platooning,
>> or V2V.  We need to identify somebody to find out.
>>
>> Alex
>>
>>>
>>> Best Regards,
>>>
>>> Jérôme
>>>
>>>
>>>
>>>
>
>
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Jan 2015 15:33:17 +0100

Le 27/01/2015 08:37, Richard Roy a écrit :
> Alex,
>
> A few minor things below:
>
> Cheers,
>
> RR
>
>> From: Alexandru Petrescu [mailto:[email-masked]]
>> Sent: Monday, January 26, 2015 4:05 AM
>> To: [email-masked]; 'Jérôme Härri'; 'Rex Buddenberg'
> [RR>] Actually, the reason I said 1609.11 aside is because 1609 people do
> consider it an app, in  particular, a toll-collection (or EFC) app!

If they consider it an app, then can we ask them what is the networking 
layer used?

> [RR>] Remember that applications do not reside in the ISO application layer,
> APIs among other things do.  Many people get confused by this, but it is
> nonetheless the case.

At IETF there are APIs as well between apps and networking layer, such 
as the BSD Socket Interface.

> [RR>] Yes, and so do others.  The terms "services" and "applications" are
> overloaded in comms speak.  However, in the OSI model, functions in any
> given layer are applications as seen by the layer(s) below, and at the same
> time are services as seen by the layer(s) above.  To make it more
> complicated, functions in the management entity are often referred to as
> management "services".  So, all the security functions (which are actually
> management functions from the OSI stack perspective) are called "security
> services".
>
> Now, to make it even more complicated, stakeholders at the highest levels in
> the system hierarchy use the term service to mean something porvided to a
> user.  So, an ITS service is defined as something of value provided to an
> ITS user.  ITS services are implemented using ITS applications whcih are
> instantiated in ITS-S application processes (software) that actually do the
> work!  Is that clearer now? :^))))

It is terminology used by specifications.  Thanks for the explanation.

> [RR>] Not sure what you mean by synthesizing the current draft.  That said,

Synthesizing _in_ a draft.  Summarizing other activities in a few 
paragraphs.

> I am in constant contact with ALL these guys.  Let me know what you would
> like to get from them, and I'll see what I can do.

Yes, here is what I would like to get from them: what is the documented 
activity at SAE about C-ACC and Platooning?  Could you please write a 
few paragraphs about these activities, together with a few of us, in an 
Internet Draft titled "C-ACC and Platooning use-cases at ETSI ITS, IEEE 
1609, ISO WG, and at SAE".

If so, this may help towards designing an IETF protocol for establishing 
IP networking paths between vehicles.  Once paths are established, 
applications will fluorish.

Alex