Re: [ipwave] Communication between the car and the Traffic Lights

[Alexandre Petrescu <[e-mail]>]

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

> 
> Sri
> 
> 
> 
> 
> 
> On 11/29/18, 6:54 AM, "its on behalf of Alexandre Petrescu" 
> <[e-mail] on behalf of [e-mail]>
> 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.
>>> 
>>> 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 
>>>> <[e-mail]
>>>> <mailto:[e-mail]>> 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: [phone] 
>>>>> Email: [e-mail]
>>>>> <mailto:[e-mail]>
>>>> <mailto:[e-mail]
>>>> <mailto:[e-mail]>>,
>>>>> [e-mail] <mailto:[e-mail]>
>>>> <mailto:[e-mail] <mailto:[e-mail]>>
>>>>> Personal Homepage:
>>>> http://iotlab.skku.edu/people-jaehoon-jeong.php
>>>>> <http://cpslab.skku.edu/people-jaehoon-jeong.php>
>>>>> 
>>>>> _______________________________________________ its mailing
>>>>> list [e-mail] <mailto:[e-mail]> 
>>>>> https://www.ietf.org/mailman/listinfo/its
>>>>> 
>>>> 
>>>> _______________________________________________ its mailing
>>>> list [e-mail] <mailto:[e-mail]> 
>>>> https://www.ietf.org/mailman/listinfo/its
>>>> 
>>>> 
>>>> 
>>>> -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. 
>>>> Associate Professor Department of Software Sungkyunkwan
>>>> University Office: [phone] Email:
>>>> [e-mail] <mailto:[e-mail]>, 
>>>> [e-mail] <mailto:[e-mail]> Personal
>>>> Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php 
>>>> <http://cpslab.skku.edu/people-jaehoon-jeong.php>
>>> 
>>> _______________________________________________ its mailing list 
>>> [e-mail] https://www.ietf.org/mailman/listinfo/its
>> 
>> _______________________________________________ its mailing list 
>> [e-mail] https://www.ietf.org/mailman/listinfo/its
> 
>