Subject: Re: [ipwave] Request for Review on IPWAVE PS Draft

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Tue, 4 Dec 2018 09:15:21 +0900

Hi Alex,
In South Korea, people are aware of PRESTO (ISO 22951:2009)
for traffic light control for emergency vehicles, but it seems like
there is no standardized, implemented protocol in South Korea yet.
I guess that Korean people will try to implement the ISO's PRESTO in future.

The PRESTO does not specify a specific delivery protocol, so
our IPWAVE will be a good candidate for this traffic light control, so
we can include this into our PS document as a use case.

Thanks.

Best Regards,
Paul

On Wed, Nov 28, 2018 at 9:43 PM Alexandre Petrescu <
[email-masked]> wrote:

> Hi Paul,
>
> Thank you for the reply.
>
> In this particular case, I am not asking to make modifications to the
> draft.
>
> But, for my information, I would like to learn: what protocol is used in
> in S Korea to communicate with the traffic lights controller?
>
> I need such a protocol in a use-case where the car may have the ability
> to ask, under certain circumstances, the traffic light to turn to green,
> or to learn how much time is left for red.
>
> In France that protocol is called "DIASER" (it is an abbreviation for
> "DIAlogue Standard des Equipements de Régulation de trafic".)
>
> At ISO, which is an International SDO, there is "PRESTO" (ISO 22951:2009
> "Data dictionary and message sets for preemption and prioritization
> signal systems for emergency and public transport vehicles (PRESTO)).
>
> Alex
>
> Le 28/11/2018 à 02:28, Mr. Jaehoon Paul Jeong a écrit :
> > Hi Alex,
> > I will address your comments with other reviewers' comments for the
> > revision.
> >
> > Thanks.
> >
> > Best Regards,
> > Paul
> >
> > On Tue, Nov 27, 2018 at 11:00 PM Alexandre Petrescu
> > <[email-masked] <mailto:[email-masked]>>
> wrote:
> >
> >     Hi Paul,
> >
> >     I have a few comments to the draft that I would like to mention.
> >
> >     At this time, I do not request to modify the draft.  Thank you.
> >
> >     Here are my comments:
> >
> >     In the V2V section:
> >     - do not forget there is a funny typo: "obstables".
> >     - the 4 paragraphs in this section read good and make sense.
> >     - at ISO/TC204, there is recently an activity called
> >         "Vehicle to Vehicle Intersection Collision Warning System
> (VVICW)"
> >         The private Word document ISO 23376:20##(E) has 16 pages and I
> can
> >         discuss it in private with interested parties.
> >
> >     In the V2I section:
> >     - the three paragraphs read good.
> >
> >     - in addition, in my project, we consider V2I to also mean direct
> >         communication between the car and the nearby Traffic Lights
> >         Controller.
> >
> >         The communication between the car and the traffic lights
> controller
> >         can happen in two distinct V2I ways: from car to TCC and back to
> >         traffic lights controller, or from car to traffic traffic lights
> >         controller (not through TCC).
> >
> >         The end-to-end protocol between car and traffic lights
> >     controller can
> >         be the same protocol as the protocol between TCC and the traffic
> >         lights controller.  In France that protocol is called "DIASER".
> >     But,
> >         for international (maybe France - Netherlands) we also consider
> the
> >         ISO protocol called "PRESTO".  DIASER runs over IP (and on
> serial),
> >         but we wonder whether PRESTO runs over IP.
> >
> >     In section "5.1.2 Routing":
> >     - the section lists "VANET Geo Routing",
> >         but we do not use geographical routing.
> >     - the section lists
> >         "IPv6 Neighbor Discovery for IP-Based Vehicular Networks"
> >         for potential use for V2V communications.
> >         Instead, we use RFC4191 "More Specific Routes".
> >         This RFC4191 has a problem in that it is only for Hosts.
> >         We want RFC4191 to be for Routers as well.
> >         This RFC4191 is partially implemented in two alternatives in
> linux:
> >         (1) in the linux kernel and (2) in openwrt's odhcp6c.  The latter
> >         needs a little bit of extension because by default it is not
> capable
> >         of doing _only_ "more specific routes", it wants to also do
> default
> >         route and address autoconfiguration.
> >
> >     Alex
> >
> >     Le 21/11/2018 à 05:27, Mr. Jaehoon Paul Jeong a écrit :
> >      > Hi Sri Gundavelli and Jung-Soo Park,
> >      > Thanks for your volunteering on the review of our IPWAVE PS draft:
> >      >
> https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-07
> >      >
> >      > Could you share your review within this December?
> >      >
> >      > Once I get your comments, I will address yours along with the
> >     co-authors.
> >      >
> >      > Thanks again.
> >      >
> >      > Best Regards,
> >      > Paul
> >      > --
> >      > ===========================
> >      > Mr. Jaehoon (Paul) Jeong, Ph.D.
> >      > Associate Professor
> >      > Department of Software
> >      > Sungkyunkwan University
> >      > Office: +82-31-299-4957
> >      > Email: [email-masked] <mailto:[email-masked]>
> >     <mailto:[email-masked] <mailto:[email-masked]>>,
> >      > [email-masked] <mailto:[email-masked]>
> >     <mailto:[email-masked] <mailto:[email-masked]>>
> >      > Personal Homepage:
> http://iotlab.skku.edu/people-jaehoon-jeong.php
> >      > <http://cpslab.skku.edu/people-jaehoon-jeong.php>
> >      >
> >      > _______________________________________________
> >      > its mailing list
> >      > [email-masked] <mailto:[email-masked]>
> >      > https://www.ietf.org/mailman/listinfo/its
> >      >
> >
> >     _______________________________________________
> >     its mailing list
> >     [email-masked] <mailto:[email-masked]>
> >     https://www.ietf.org/mailman/listinfo/its
> >
> >
> >
> > --
> > ===========================
> > Mr. Jaehoon (Paul) Jeong, Ph.D.
> > Associate Professor
> > Department of Software
> > Sungkyunkwan University
> > Office: +82-31-299-4957
> > Email: [email-masked] <mailto:[email-masked]>,
> > [email-masked] <mailto:[email-masked]>
> > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
> > <http://cpslab.skku.edu/people-jaehoon-jeong.php>
>

-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked], [email-masked]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 4 Dec 2018 11:00:04 +0100

Hi Paul,

Thank you for the reply.

> we can include this into our PS document as a use case.

This initiative seems appropriate.

I would need to understand what do you mean by IPWAVE.

On my side, I think IP/OCB protocol developped by IPWAVE WG would be a
good intermediary means to network IP packets between car and traffic
light controller (other intermediary segment is Ethernet, with
IP/Ethernet, within the IP-RSU box, and within the car).

But there need to be IP routes between the car and the traffic light
controller too.  To achieve that we need a mechanism.

And there would need to be an application layer protocol (PRESTO?  SPAT?
  DIASER?  SRM/SSM? HTTP?) between the car and the traffic light controller.

Alex

> 
> Thanks.
> 
> Best Regards,
> Paul
> 
> 
> 
> On Wed, Nov 28, 2018 at 9:43 PM Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Paul,
> 
>     Thank you for the reply.
> 
>     In this particular case, I am not asking to make modifications to
>     the draft.
> 
>      > <[email-masked]
>     <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >
>      >     Hi Paul,
>      >
>      >         The private Word document ISO 23376:20##(E) has 16 pages
>     and I can
>      >         for international (maybe France - Netherlands) we also
>     consider the
>      >         ISO protocol called "PRESTO".  DIASER runs over IP (and
>     on serial),
>      >         This RFC4191 is partially implemented in two alternatives
>     in linux:
>      >         needs a little bit of extension because by default it is
>     not capable
>      >         of doing _only_ "more specific routes", it wants to also
>     do default
>      >      > Hi Sri Gundavelli and Jung-Soo Park,
>      >      > Thanks for your volunteering on the review of our IPWAVE
>     PS draft:
>      >      >
>      >      >
>      >      > Could you share your review within this December?
>      >      >
>      >      > Once I get your comments, I will address yours along with the
>      >     co-authors.
>      >      >
>      >      > Thanks again.
>      >      >
>      >      > Best Regards,
>      >      > Paul
>      >      > --
>      >      > ===========================
>      >      > Mr. Jaehoon (Paul) Jeong, Ph.D.
>      >      > Associate Professor
>      >      > Department of Software
>      >      > Sungkyunkwan University
>      >      > Office: +82-31-299-4957
>      >      > Email: [email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>,
>      >      > [email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      > Personal Homepage:
>      >      > <http://cpslab.skku.edu/people-jaehoon-jeong.php>
>      >      >
>      >      > _______________________________________________
>      >      > its mailing list
>      >      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >      > https://www.ietf.org/mailman/listinfo/its
>      >      >
>      >
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 5 Dec 2018 02:36:04 +0000

Alex,

Ack! We did face some interop/parsing issues with some of the BSM messages
that are there in the public domain. We were not aware of the fact that
the current version of J2735 has no backward compatibility with the
pre-2009 version, which some of the public domain PCAP files appears to be
based of. But, looks like there should not be many implementations of
pre-2009, so hopefully we can ignore them. But, we are looking for a good
set of PCAP files that we can test against.

Below points are great points, but not sure what we can do here in this
group.

Sri

On 11/29/18, 6:54 AM, "its on behalf of Alexandre Petrescu"
<[email-masked] on behalf of [email-masked]> wrote:

>Hi,
>I wanted to give an update about my quest for this protocol for traffic
>lights controller.
>
>I received private indication from another person that S Korea is likely
>to use SPAT messaging for communications between car to talk to traffic
>lights.
>
>That said, here is the 4 points I wanted to tell the list:
>
>1. I was afraid of SPAT, as much of BSM, because their specification is
>paying (cca 100USD) on SAE website.  When behind a paywall, one cant say
>much about it.  But what I needed was only the ASN.1 specification
>(grammar) in order to implement automatically.  Such a grammar is
>available for free for CAM messages in publicly available ETSI ITS
>documents in Europe.  Such a grammar was not available for free for SPAT
>in America, and I had no means to tell whether the J2735 contained it,
>because behind a paywall.
>
>Another person sent me an earlier version of J2735, but that is
>currently held by some security filters for 24h, so I still cant see it.
>
>Until then, I found out much to my trill, that asn1 playground site
>gives that specification for free.  Just go to "asn1 playground", select
>schema "ITS J2735" and click on "ASN.1 Specification".  That will output
>the "ITS 20J2735.asn" file.  This file can then, supposedly, be
>automatically processed by the open source asn1c software, to generate
>parsers and generators for SPAT, BSM and probably MAP, if not others too.
>
>2. another implementer told me that there are some problems of
>interoperability of BSM messages.  It has to do with UPER vs apparently
>deprecated DER/BER, with 0x20 vs 0x02 problems (endianness?) and others.
>  Since BSM is same spec as SPAT (J2735), this can risk become a huge
>problem of interoperability between cars and RSUs that I am concerned
>about.
>
>To that end, I would very much like to put BSMs on XER (rather than
>UPER/BER/DER), and thus on IP, just like several of us put CAMs on XER
>on IP in the car.  XER is easily understandable by many people and
>computers, because clear text.
>
>3. I wait for an answer to learn what protocol is used on Traffic Lights
>in Netherlands (I know France is DIASER, S Korea and America are SPAT).
>
>4. In a Traffic Light, there are clearly two distinct computers: the
>Traffic Light Controller (TLC), and the Road-Side Unit (RSU).  The TLC
>has no 802.11-OCB interface, but does have Ethernet, serial, and
>potentially 4G.  The RSU has 802.11-OCB in addition to the others.
>
>In France, the TLC does not implement SPAT/MAP.  It implements DIASER.
>It's the RSU that implements SPAT/MAP.  The RSU has, or can have, a
>software converter SPAT-DIASER.  So a car requesting green, would use at
>least two converters (one in car, one in RSU) between two protocols,
>rather than a pure end-to-end transmission like when I browse the web
>with HTTP.
>
>In S Korea, and in America, there is SPAT/MAP, but it is not clear
>whether that is implemented by TLC or by RSU, or by both.  My
>supposition is that only the RSU implements SPAT/MAP (not the TLC).
>Because the preference for UPER encoding rules for SPAT means that is
>for wireless, so not for Ethernet.  TLC does not have wireless.
>
>I wait for an answer telling whether in America it's the TLC or the RSU
>that implement SPAT/MAP.
>
>Alex
>
>Le 28/11/2018 à 13:43, Alexandre Petrescu a écrit :
>> Hi Paul,
>> 
>> Thank you for the reply.
>> 
>>>         lights controller.  In France that protocol is called
>>> "DIASER".     But,
>> [email-masked]
>[email-masked]

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 5 Dec 2018 02:37:13 +0000

Hi Paul,

Ack! Will close the reviews. Sorry for the delays.

Sri

From: "Mr. Jaehoon Paul Jeong" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 20, 2018 at 8:27 PM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, Jung-Soo Park <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Mr. Jaehoon Paul Jeong" <[email-masked]<mailto:[email-masked]>>
Subject: Request for Review on IPWAVE PS Draft

Once I get your comments, I will address yours along with the co-authors.

Thanks again.

Best Regards,
Paul
--
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php<http://cpslab.skku.edu/people-jaehoon-jeong.php>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 5 Dec 2018 12:02:22 +0100

Le 05/12/2018 à 03:36, Sri Gundavelli (sgundave) a écrit :
> Alex,
> 
> Ack! We did face some interop/parsing issues with some of the BSM
> messages that are there in the public domain. We were not aware of
> the fact that the current version of J2735 has no backward
> compatibility with the pre-2009 version, which some of the public
> domain PCAP files appears to be based of. But, looks like there
> should not be many implementations of pre-2009, so hopefully we can
> ignore them. But, we are looking for a good set of PCAP files that we
> can test against.
> 
> Below points are great points, but not sure what we can do here in
> this group.

We could put something on IP/OCB between car and Traffic Lights.

That could be: SPAT/XER/IP/OCB, DIASER/UDP/IP/OCB (DIASER is a protocol
for traffic lights in France used over Ethernet, not over OCB),
PRESTO/IP/OCB (PRESTO is an ISO protocol for traffic lights).

Some company building RSUs have already developped other protocols than
SPAT or DIASER or PRESTO, which does run over HTTP/IP.

In this there are obvious accessibility aspects to the specs.  (e.g.
SPAT 2016 is paying but SPAT 2009 is free at a place, DIASER is only
paying, HTTP/IP is free, etc.)  This makes deployment cumbersome.

We could also build our own IPWAVE protocol for the car to talk to the
traffic lights.  That spec would obviously be open.

Alex

>> Hi, I wanted to give an update about my quest for this protocol for
>> traffic lights controller.
>> 
>> I received private indication from another person that S Korea is
>> likely to use SPAT messaging for communications between car to talk
>> to traffic lights.
>> 
>> 1. I was afraid of SPAT, as much of BSM, because their
>> specification is paying (cca 100USD) on SAE website.  When behind a
>> paywall, one cant say much about it.  But what I needed was only
>> the ASN.1 specification (grammar) in order to implement
>> automatically.  Such a grammar is available for free for CAM
>> messages in publicly available ETSI ITS documents in Europe.  Such
>> a grammar was not available for free for SPAT in America, and I had
>> no means to tell whether the J2735 contained it, because behind a
>> paywall.
>> 
>> Until then, I found out much to my trill, that asn1 playground
>> site gives that specification for free.  Just go to "asn1
>> playground", select schema "ITS J2735" and click on "ASN.1
>> Specification".  That will output the "ITS 20J2735.asn" file.  This
>> file can then, supposedly, be automatically processed by the open
>> source asn1c software, to generate parsers and generators for SPAT,
>> BSM and probably MAP, if not others too.
>> 
>> interoperability of BSM messages.  It has to do with UPER vs
>> apparently deprecated DER/BER, with 0x20 vs 0x02 problems
>> (endianness?) and others. Since BSM is same spec as SPAT (J2735),
>> this can risk become a huge problem of interoperability between
>> cars and RSUs that I am concerned about.
>> 
>> To that end, I would very much like to put BSMs on XER (rather
>> than UPER/BER/DER), and thus on IP, just like several of us put
>> CAMs on XER on IP in the car.  XER is easily understandable by many
>> people and computers, because clear text.
>> 
>> 3. I wait for an answer to learn what protocol is used on Traffic
>> Lights in Netherlands (I know France is DIASER, S Korea and America
>> are SPAT).
>> 
>> 4. In a Traffic Light, there are clearly two distinct computers:
>> the Traffic Light Controller (TLC), and the Road-Side Unit (RSU).
>> The TLC has no 802.11-OCB interface, but does have Ethernet,
>> serial, and potentially 4G.  The RSU has 802.11-OCB in addition to
>> the others.
>> 
>> In France, the TLC does not implement SPAT/MAP.  It implements
>> DIASER. It's the RSU that implements SPAT/MAP.  The RSU has, or can
>> have, a software converter SPAT-DIASER.  So a car requesting green,
>> would use at least two converters (one in car, one in RSU) between
>> two protocols, rather than a pure end-to-end transmission like when
>> I browse the web with HTTP.
>> 
>> supposition is that only the RSU implements SPAT/MAP (not the
>> TLC). Because the preference for UPER encoding rules for SPAT means
>> that is for wireless, so not for Ethernet.  TLC does not have
>> wireless.
>> 
>> I wait for an answer telling whether in America it's the TLC or the
>> RSU that implement SPAT/MAP.
>> 
>> Alex
>> 
>>> But, for my information, I would like to learn: what protocol is
>>> used in in S Korea to communicate with the traffic lights
>>> controller?
>>> 
>>> I need such a protocol in a use-case where the car may have the
>>> ability to ask, under certain circumstances, the traffic light to
>>> turn to green, or to learn how much time is left for red.
>>> 
>>> In France that protocol is called "DIASER" (it is an abbreviation
>>> for "DIAlogue Standard des Equipements de Régulation de
>>> trafic".)
>>> 
>>> At ISO, which is an International SDO, there is "PRESTO" (ISO 
>>> 22951:2009 "Data dictionary and message sets for preemption and
>>> prioritization signal systems for emergency and public transport
>>> vehicles (PRESTO)).
>>> 
>>> Alex
>>> 
>>>> Hi Alex, I will address your comments with other reviewers'
>>>> comments for the revision.
>>>> 
>>>> Thanks.
>>>> 
>>>> Best Regards, Paul
>>>> 
>>>> <mailto:[email-masked]>> wrote:
>>>> 
>>>> Hi Paul,
>>>> 
>>>> In the V2V section: - do not forget there is a funny typo:
>>>> "obstables". - the 4 paragraphs in this section read good and
>>>> make sense. - at ISO/TC204, there is recently an activity
>>>> called "Vehicle to Vehicle Intersection Collision Warning
>>>> System (VVICW)" The private Word document ISO 23376:20##(E) has
>>>> 16 pages and I can discuss it in private with interested
>>>> parties.
>>>> 
>>>> In the V2I section: - the three paragraphs read good.
>>>> 
>>>> - in addition, in my project, we consider V2I to also mean
>>>> direct communication between the car and the nearby Traffic
>>>> Lights Controller.
>>>> 
>>>> controller can happen in two distinct V2I ways: from car to TCC
>>>> and back to traffic lights controller, or from car to traffic
>>>> traffic lights controller (not through TCC).
>>>> 
>>>> controller can be the same protocol as the protocol between TCC
>>>> and the traffic lights controller.  In France that protocol is
>>>> called "DIASER".     But, for international (maybe France -
>>>> Netherlands) we also consider the ISO protocol called "PRESTO".
>>>> DIASER runs over IP (and on serial), but we wonder whether
>>>> PRESTO runs over IP.
>>>> 
>>>> In section "5.1.2 Routing": - the section lists "VANET Geo
>>>> Routing", but we do not use geographical routing. - the section
>>>> lists "IPv6 Neighbor Discovery for IP-Based Vehicular
>>>> Networks" for potential use for V2V communications. Instead, we
>>>> use RFC4191 "More Specific Routes". This RFC4191 has a problem
>>>> in that it is only for Hosts. We want RFC4191 to be for Routers
>>>> as well. This RFC4191 is partially implemented in two
>>>> alternatives in linux: (1) in the linux kernel and (2) in
>>>> openwrt's odhcp6c.  The latter needs a little bit of extension
>>>> because by default it is not capable of doing _only_ "more
>>>> specific routes", it wants to also do default route and address
>>>> autoconfiguration.
>>>> 
>>>> Alex
>>>> 
>>>>> Hi Sri Gundavelli and Jung-Soo Park, Thanks for your
>>>>> volunteering on the review of our IPWAVE PS
>>>> draft:
>>>>> 
>>>>> Best Regards, Paul -- =========================== Mr. Jaehoon
>>>>> (Paul) Jeong, Ph.D. Associate Professor Department of
>>>>> Software Sungkyunkwan University Office: +82-31-299-4957 
>>>> <mailto:[email-masked]>>,
>>>>> _______________________________________________ its mailing
>>>>> list [email-masked] <mailto:[email-masked]> 
>>>> _______________________________________________ its mailing
>>>> list [email-masked] <mailto:[email-masked]> 
>>>> -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. 
>>>> Associate Professor Department of Software Sungkyunkwan
>>>> University Office: +82-31-299-4957 Email:
>>>> [email-masked] <mailto:[email-masked]>, 
>>>> [email-masked] <mailto:[email-masked]> Personal
>>>> Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php 
>>> _______________________________________________ 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: Alexandre Petrescu <[email-masked]>
Date: Wed, 5 Dec 2018 12:18:05 +0100

> Below points are great points, but not sure what we can do here in

We could consider how the IP path is established between car and
Road-Side Unit.  It's on that path that the IP messages for traffic
light controller go.

To establish an IP path between car and IP Road-Side Unit, one would use
RFC4191 "More Specific Routes" developped by 6MAN WG, but this time for
Routers.  We would thus write a draft titled "More Specific Routes for
Routers".

The problem is in section 5.1.3 'Prefix Dissemination/Exchange' of
draft-ietf-ipwave-vehicular-networking-07.

The use-case is the same as the V2V use-case in
draft-ietf-ipwave-vehicular-networking-07.  (the second 'V' is an IP
Road-Side Unit, so V2IPRSU).

Would one be interested?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 5 Dec 2018 16:05:10 +0100

I learn that in Netherlands the protocols for traffic lights are, maybe 
among others:

   VLOG

   IVERA

They run on wire, or on some wireless, but not clear whether that's 
GPRS.  Not clear whether they run on IP.  They run, among others, 
between Traffic Lights Controller (TLC, near the lights) and Traffic 
Control Center (TCC, in the cloud).

Yours,

Alex

Le 05/12/2018 à 12:02, Alexandre Petrescu a écrit :
>>>>> The communication between the car and the traffic lights controller 
>>>>> can happen in two distinct V2I ways: from car to TCC
>>>>> The end-to-end protocol between car and traffic lights controller 
>>>>> can be the same protocol as the protocol between TCC
>>>>>> Software Sungkyunkwan University Office: +82-31-299-4957 Email: 
>>>>>> [email-masked]

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Fri, 7 Dec 2018 00:20:19 +0900

Alex,
I mean IP-based networking for V2V and V2I by IPWAVE protocols.
As you said, I agree we need an application protocol between a vehicle and
a traffic light either directly or via an RSU.
Right now, I am not sure which application protocol will be popularly used
for the traffic light controller.

Best Regards,
Paul

On Tue, Dec 4, 2018 at 7:00 PM Alexandre Petrescu <
[email-masked]> wrote:

> >     used in
> ability
> >     22951:2009
> direct
> >     "DIASER".
> >      >      > Email: [email-masked]

---

From: Tony Li <[email-masked]>
Date: Thu, 6 Dec 2018 11:29:47 -0800

> We could put something on IP/OCB between car and Traffic Lights.

Applications should be on top of a transport protocol (TCP/UDP/QUIC) and should NOT directly affect IP/OCB whatsoever.  Anything else is a major layering violation.

Tony

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 7 Dec 2018 08:46:15 +0100

Le 06/12/2018 à 20:29, Tony Li a écrit :
> Applications should be on top of a transport protocol (TCP/UDP/QUIC)
> and should NOT directly affect IP/OCB whatsoever.  Anything else is a
> major layering violation.

I agree.  We need to avoid major layering violations.

I suppose HTTP/TCP/IP/OCB would be a reasonable layering architecture to 
transmit Traffic Light status and commands.

One may consider maybe also QUIC, but not sure HTTP runs on QUIC.

Alex