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

["Sri Gundavelli (sgundave)" <[e-mail]>]

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"
<[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