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

[Alexandre Petrescu <[e-mail]>]

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 
> <[e-mail] <mailto:[e-mail]>> 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
>      > <[e-mail]
>     <mailto:[e-mail]>
>     <mailto:[e-mail]
>     <mailto:[e-mail]>>>
>      > 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
>      > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      > 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:[phone] Email:
>      > [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
> 
>     _______________________________________________
>     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>