Re: [ipwave] traffic lights status displayed in the car, and the latency problem

Hi François, Paul,

Le 03/09/2019 à 15:53, Mr. Jaehoon Paul Jeong a écrit :
> Hi Francois, Your send documents seem useful.

François, please send me the document as well.  I could not receive it
in my regular folder.  Your message was dropped entirely somewhere,
although it is present in the archives at ietf.org/mailman/listinfo/its.

I learned of your message because Paul reply to it :-)

> Thanks.
> 
> For the communication between a vehicle and a traffic controller 
> using 802.11-OCB, we can use 802.11e for EDCA (Enhanced Distributed 
> Channel Access) to give a higher priority to the messages for traffic
> light control. Even through the combination of 802.11-OCB and
> 802.11e-EDCA cannot guarantee perfect collision avoidance, the 
> traffic light control at an intersection can be handled by such a 
> combination.

I agree we could request to put something about higher priority in the
link layer fields of packets carrying important data such as the current
color of the light.   If that is in 802.11e, or a new PCF mode - then so
be it.  It could be a sort of special IPv6-over-OCB specification.

In implementation, it should be something with ath10k OCB mode or with
an Intel ip* driver in OCB mode (neither exists, but it is possible to do).

At the same time, there is need for something to make the IP path
between the laptop in the car, through the mobile Router in the car,
through the fixed Router in the roadside cupboard (term?) and to the
traffic lights controller (tlc).

Each of these 4 entities has an IP address.  They are on distinct subnets:

                             OCB
laptop ----- mobile Router ----- fixed router ---- tlc

These would thus bew two things: a link layer mechanism for OCB
to speed up urgent messages, and an IP mechanism to quickly establish an
IP path between laptop and tlc.

> For a better V2I communication between a vehicle and an RSU (or 
> traffic controller), we need a new PCF (Point Coordination Function)
>  mode for IPWAVE that needs no association procedure between the 
> vehicle and the RSU whenever a vehicle approaches the coverage of an
>  RSU. We can take advantage of a vehicle's trajectory and mobility 
> information to handle the association along the vehicle's movement 
> through the vehicular infrastructure network having RSUs and a 
> Mobility Anchor like PMIPv6.

YEs.   The application on the laptop in the vehicle would need to know
what is the IP address of the tlc to send queries to.  This IP address
would be in a table.  Depending on where the vehicle is, and where it
goes, one could identify which is the IP address to query the status of
lights.

That is a new mechanism needed.

People think it is something obvious, but it is not at all simple to do.
  There are several ways to achieve it, each with its advantages and
inconvenients.

Things depending on GPS position, and calculations of proximity are
inherently very hard to do, despite an aparent simplicity.

[...]

> The 802.11 OCB was never intended to communicate with the traffic 
> controller, the RSE is.

Well, RSE is the Road-Side Entity, right?

The implementations that I know and that run on RSE do indeed query the
traffic lights controller (tlc) using a protocol specific for tlc.  It
is DIASER in France; they run DIASER on Ethernet cable.  These RSE
implementations obtain the status data from tlc and then put it in the
SPAT-EM message.  It is this SPAT-EM message that is put on OCB wireless
towards the cars.

However, that DIASER query is a periodic query: it is once every second
or so (1 Hz).  One can go higher than one second, but it risks
overloading the computation capability of the tlc.  We have performed
measures and came up with 1 Hz being very good, but 2 Hz overloading the
tlc.

(I am not aware of any protocol for traffic lights controllers, like
DIASER, that would work more in a subscribe-notify, or publish-subscribe
manner.  They all work in a client-server mode, query-response mode,
like http does.  If there were one, I am willing to learn.)

Once that result of the 1 Hz periodic query is obtained, it is put in
the SPAT-EM message, and sent on OCB wireless.  Some people send that
SPAT-EM at a higher rate (frequency), like 20 Hz: one SPAT-EM every
50ms, instead of every second.  So the car gets very frequent SPAT-EM.
Despite this higher rate, the value of the status of the lights (i.e.
red, or green) does not change according the the true displayed color.
So that 20Hz is useless to improve the latency.

And, true also, there are other semantics involved than this on-board
display of color.  Some tlcs send their data to a cloud (not to car)
that 'reasons' over these statuses of lights and then advices the car to
a certain 'ideal' speed to maintain such as to avoid red lights.  (GLOSA
comes to mind, and similar).

Yet, the efficiency of these GLOSA-likme chanisms is largely disbelieved
(not trusted) by experienced developpers of tlcs.  The reason is that it
is sufficient for an unexpected event to occur (a pedestrian push a
button), or a car detected in an otherwise quiet road, that the entire
planning falls apart, and the advice given to maintain a certain speed
is nullified.

> As far as for latency, It is almost impossible to determine the 
> latency of an 802.11 OCB (it is CSMA based).

I am not asking to determine precisely the latency of 802.11-OCB.

I am asking it to not be 1second systematically.  I noticed this 1second
difference in many places.  I heard reports of 1second after, or
_before_ (read 'prediction': the computer tells 1 second in advance a
status that will happen 1 second later).  This is way too much to trust.

I am asking that the latency (time difference between when the traffic
light color changes and when the on-board computer display changes) be
less than what the human can perceive.  The human analyzes images at a
rate of 25 images per second.  So it is sufficient for this latency to
be around 40 ms.  With such a latency, the human driver can start to
trust a traffic lights color displayed in the car, and the law can even
agree to her/him.  (there are other dangers to that, but it's too early
to mention).

In this 40ms one should fit the communication latency (on OCB it is
something between 1 and 10ms) and the computation latency.

I think it is reasonable to expect that.

But it depends so much on how the system is designed: how many
compute-intensive conversions between tlc-specific formats (e.g. DIASER)
and SPAT-EM formats, how many 1Hz loops, how many direct communications,
etc.

Or we can stay satisfied with GLOSA-like claims that things work anyways
as they do today, without end user satisfaction, without end user trust
in system.

Alex

> 
> __ __
> 
> Please find attached old documents 2011 which may help you 
> understand.
> 
> __ __
> 
> Fygs
> 
> __ __
> 
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for 
> Windows 10
> 
> __ __
> 
> *From: *Alexandre Petrescu <mailto:alexandre.petrescu@gmail.com> 
> *Sent: *Friday, August 30, 2019 6:31 AM *To: *Mr. Jaehoon Paul Jeong
>  <mailto:jaehoon.paul@gmail.com> *Cc: 
> *skku_iotlab_seminar@googlegroups.com 
> <mailto:skku_iotlab_seminar@googlegroups.com>; Chris Shen 
> <mailto:shenyiwen7@gmail.com>; its@ietf.org <mailto:its@ietf.org> 
> *Subject: *Re: [ipwave] traffic lights status displayed in the car, 
> and thelatency problem
> 
> __ __
> 
> Paul,
> 
> __ __
> 
> Le 30/08/2019 à 11:56, Mr. Jaehoon Paul Jeong a écrit :
> 
>> Alex,
> 
>> The detour path through the VPN server using LTE links
> experiences such
> 
>> a long delay.
> 
>> This is why IPWAVE is required to allow a vehicle and a traffic
> light
> 
>> controller to communicate directly with each other
> 
>> using IEEE 802.11-OCB links.
> 
>> 
> 
>> Did you measure the response time from a laptop to a traffic light
> 
>> controller using 802.11-OCB?
> 
> __ __
> 
> No, we did not yet perform tests with 802.11-OCB between car and 
> traffic
> 
> lights controller.
> 
> __ __
> 
> We can consider that.
> 
> __ __
> 
>> We need to break down the delay components to analyze the
> bottleneck in
> 
>> this traffic light control scenario.
> 
> __ __
> 
> I agree.
> 
> __ __
> 
> Alex
> 
> __ __
> 
>> 
> 
>> Thanks.
> 
>> 
> 
>> Paul
> 
>> 
> 
>> 
> 
>> 
> 
>> On Fri, Aug 30, 2019 at 6:17 PM Alexandre Petrescu
> 
>> <alexandre.petrescu@gmail.com
> <mailto:alexandre.petrescu@gmail.com> 
> <mailto:alexandre.petrescu@gmail.com 
> <mailto:alexandre.petrescu@gmail.com>>> wrote:
> 
>> 
> 
>> Hi Chris,
> 
>> 
> 
>> Le 30/08/2019 à 10:52, Chris Shen a écrit :
> 
>>> Hi Alex,
> 
>>> 
> 
>>> Thanks Alex, it is good to see this experiment.
> 
>>> 
> 
>>> About the latency, it seems that you use a shared cloud
> server for
> 
>>> both car and traffic light to access. That is the traffic
> light
> 
>>> updates its status to the cloud server, and the car
> queries the
> 
>>> cloud server if there is any update. There is no direct
> 
>>> communication between the traffic light and the car. So
> how do you
> 
>>> measure the E2E latency from car to traffic light?
> 
>> 
> 
>> Thank you for the reply.
> 
>> 
> 
>> Do you consider a cloud server that stores the status of
> traffic lights?
> 
>> 
> 
>> We measure the E2E latency in two manners: the RTT displayed
> by ping
> 
>> command between laptop and traffic lights controller, and the
> time
> 
>> difference between the UDP DIASER request and response
> recorded on the
> 
>> laptop.  See the points 1 and 2 below.
> 
>> 
> 
>> The car does not query the cloud server, but it queries the
> traffic
> 
>> lights controller through VPN.  The traffic lights controller
> does not
> 
>> send its status periodically to a server, but it responds to
> requests
> 
>> issued by the laptop through VPN.  We do not store the
> traffic lights
> 
>> status on the server. If we did this, then it would add up to the
> 
>> latency.
> 
>> 
> 
>> 1. the VPN server in the cloud is a rendez-vous point.  It
> runs OpenVPN
> 
>> software.  The car laptop opens an openvpn connection to this
> server.
> 
>> Also the router-modem of the traffic lights controller opens
> such a
> 
>> connection to the same VPN server.  Once the two VPN
> connections are
> 
>> open, the car laptop can ping the router-modem of the traffic
> light
> 
>> controller and thus note the RTT reported by ping command.
> This ping
> 
>> gets through the VPN server.
> 
>> 
> 
>> 2. the laptop originates an UDP DIASER request for status of
> traffic
> 
>> lights.  This request is captured by the wireshark in the
> laptop.  This
> 
>> UDP DIASER request is sent on the Internet, arrives at VPN
> server and
> 
>> gets forwarded to the router-modem attached to the traffic lights
> 
>> controller.  The router-modem does port forwarding and
> forwards the
> 
>> request to the controller.  The controller sends back the UDP
> DIASER
> 
>> reply containing the status.  This UDP DIASER reply is
> captured by the
> 
>> wireshark in the laptop.  The time difference between those
> two messages
> 
>> makes for the E2E latency.
> 
>> 
> 
>> 
> 
>> Alex
> 
>> 
> 
>>> 
> 
>>> Thanks! Chris.
> 
>>> 
> 
>>> On Fri, Aug 30, 2019 at 5:15 PM Alexandre Petrescu
> 
>>> <alexandre.petrescu@gmail.com
> <mailto:alexandre.petrescu@gmail.com>
> 
>> <mailto:alexandre.petrescu@gmail.com
> <mailto:alexandre.petrescu@gmail.com>>
> 
>> <mailto:alexandre.petrescu@gmail.com
> <mailto:alexandre.petrescu@gmail.com>
> 
>> <mailto:alexandre.petrescu@gmail.com
> <mailto:alexandre.petrescu@gmail.com>>>>
> 
>>> wrote:
> 
>>> 
> 
>>> Hi,
> 
>>> 
> 
>>> Has someone else filmed a demo of displaying the traffic
> lights
> 
>>> status in the car?  (a communicated status, not a camera
> recognized
> 
>>> status).
> 
>>> 
> 
>>> We filmed recently several such trials.  We noticed a
> systematic
> 
>>> problem with latency.  This problem lies in the difference
> between
> 
>>> the color displayed by the traffic light bulb and the color
> 
>>> displayed in the car.
> 
>>> 
> 
>>> Ideally, at no time should a human perceive a difference
> between
> 
>>> what the light bulb displays and what the laptop displays
> in the
> 
>>> car.
> 
>>> 
> 
>>> https://youtu.be/RR5hpL29-vk
> 
>>> 
> 
>>> At point 3 second, the bulb displays green whereas the laptop
> 
>>> displays red.  This undesirable situation lasts for 1
> second.  It is
> 
>>> an enormous time lapse.  It is sufficient for the driver
> to loose
> 
>>> confidence in the laptop display, and it is ample time for a
> 
>>> self-driving car to do many undesirable things.  A typical
> reason
> 
>>> for human loosing confidence in laptop display is that
> during such
> 
>>> lapse of time (1 second) in many places in Paris area one gets
> 
>>> honked (klaxonned) if one is first in line and does not
> leave at a
> 
>>> moment's notice; because the last in line risks having to
> wait a
> 
>>> second cycle - everyone in line knows that and at least
> one will honk
> 
>>> (klaxon). It is forbidden to klaxon in city.
> 
>>> 
> 
>>> For this video, we did our best to reduce the latency.  The
> 
>>> communication path between the traffic lights controller
> and the car
> 
>>> was set with 4G.  There are two 4G links in sequence: one
> between
> 
>>> the traffic lights controller and the VPN server in the
> cloud, and
> 
>>> another between the VPN server and the car.  The measured
> end-to-end
> 
>>> latency from laptop to traffic lights controller averages
> 100ms.
> 
>>> The queries to obtain the status of lights are sent with a
> frequency
> 
>>> of approx. 20 Hertz, which is approx. each 50ms. (DIASER
> on UDP on
> 
>>> IPv4).  The laptop is a recent thinkpad with python doing
> queries
> 
>>> and display.  The traffic lights controller is an Aximum
> Maestro with
> 
>>> a Motorola MC-something.
> 
>>> 
> 
>>> We could put 802.11-OCB there, to further gain on the
> communication
> 
>>> latency.
> 
>>> 
> 
>>> We could try recent pre-5G chipsets.
> 
>>> 
> 
>>> We could try the ITS-G5 SPAT-EM technology which relies on
> DIASER
> 
>>> still.
> 
>>> 
> 
>>> But we are not sure the 1s delay exposed above will get any
> 
>>> improvement by any of these steps.
> 
>>> 
> 
>>> This is why I am asking if this situation of latent display of
> 
>>> traffic lights in car was witnessed elsewhere, and which
> paths could
> 
>>> be explored to improve the latency?
> 
>>> 
> 
>>> Alex
> 
>>> 
> 
>>> 
> 
>>> _______________________________________________ its
> mailing list
> 
>>> its@ietf.org <mailto:its@ietf.org> <mailto:its@ietf.org
> <mailto:its@ietf.org>> <mailto:its@ietf.org <mailto:its@ietf.org>
> 
>> <mailto:its@ietf.org <mailto:its@ietf.org>>>
> 
>>> https://www.ietf.org/mailman/listinfo/its
> 
>>> 
> 
>>> 
> 
>>> 
> 
>>> -- Yiwen (Chris) Shen, Ph.D. Candidate
> 
>>> 
> 
>>> Homepage: https://chrisshen.github.io IoT Lab:
> 
>>> _http://iotlab.skku.edu <http://iotlab.skku.edu/>_
> Sungkyunkwan
> 
>>> University, Suwon, South Korea Mobile:+82-(0)10-6871-8103
> Email:
> 
>>> chrisshen@skku.edu <mailto:chrisshen@skku.edu>
> <mailto:chrisshen@skku.edu <mailto:chrisshen@skku.edu>>
> 
>> <mailto:chrisshen@skku.edu <mailto:chrisshen@skku.edu>
> <mailto:chrisshen@skku.edu <mailto:chrisshen@skku.edu>>>
> 
>> 
> 
>> _______________________________________________
> 
>> its mailing list
> 
>> its@ietf.org <mailto:its@ietf.org> <mailto: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>
> <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
> 
> __ __
> 
> 
> 
> -- =========================== 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>