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

[Alexandre Petrescu <[e-mail]>]

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 :
> 
> 
> 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
>>
>>
> 
> _______________________________________________
> its mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/its