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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Thu, 29 November 2018 14:54 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E0F130DF3 for <its@ietfa.amsl.com>; Thu, 29 Nov 2018 06:54:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.633
X-Spam-Level:
X-Spam-Status: No, score=-1.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChwJrp0IP4h9 for <its@ietfa.amsl.com>; Thu, 29 Nov 2018 06:54:53 -0800 (PST)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBF4F1294D0 for <its@ietf.org>; Thu, 29 Nov 2018 06:54:52 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id wATEsooP018046 for <its@ietf.org>; Thu, 29 Nov 2018 15:54:50 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C3121206778 for <its@ietf.org>; Thu, 29 Nov 2018 15:54:50 +0100 (CET)
Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B95B6206680 for <its@ietf.org>; Thu, 29 Nov 2018 15:54:50 +0100 (CET)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id wATEslRP005446 for <its@ietf.org>; Thu, 29 Nov 2018 15:54:50 +0100
To: its@ietf.org
References: <CAPK2DeymfD3ouKN2-PQPy2Fr6pe7dBJFJ5pDfWruxH+7cJsraQ@mail.gmail.com> <6f2adeae-7f01-cba7-f9eb-e470e05b8f08@gmail.com> <CAPK2Dew3NZwMBgB-swYSpdzM92H2+BP-5HbVrtmwvoocSLcniA@mail.gmail.com> <af640b86-4941-17c0-8991-6705c9340d46@gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <65113fb2-d277-d3c2-3212-84ffe15a7360@gmail.com>
Date: Thu, 29 Nov 2018 15:54:46 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
MIME-Version: 1.0
In-Reply-To: <af640b86-4941-17c0-8991-6705c9340d46@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/YxP9KpjSnEDtKGzmK-JqMhmRD5s>
Subject: Re: [ipwave] Communication between the car and the Traffic Lights
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Nov 2018 14:54:56 -0000

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 
>> <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>> 
>> 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: jaehoon.paul@gmail.com <mailto:jaehoon.paul@gmail.com>
>>     <mailto:jaehoon.paul@gmail.com <mailto:jaehoon.paul@gmail.com>>,
>>      > pauljeong@skku.edu <mailto:pauljeong@skku.edu>
>>     <mailto:pauljeong@skku.edu <mailto:pauljeong@skku.edu>>
>>      > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
>>      > <http://cpslab.skku.edu/people-jaehoon-jeong.php>
>>      >
>>      > _______________________________________________
>>      > its mailing list
>>      > its@ietf.org <mailto:its@ietf.org>
>>      > https://www.ietf.org/mailman/listinfo/its
>>      >
>>
>>     _______________________________________________
>>     its mailing list
>>     its@ietf.org <mailto:its@ietf.org>
>>     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: jaehoon.paul@gmail.com <mailto:jaehoon.paul@gmail.com>, 
>> pauljeong@skku.edu <mailto:pauljeong@skku.edu>
>> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php 
>> <http://cpslab.skku.edu/people-jaehoon-jeong.php>
> 
> _______________________________________________
> its mailing list
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its