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

"Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com> Tue, 03 September 2019 13:53 UTC

Return-Path: <jaehoon.paul@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 3A3F0120118 for <its@ietfa.amsl.com>; Tue, 3 Sep 2019 06:53:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.987
X-Spam-Level:
X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 81b9vNRRwTYD for <its@ietfa.amsl.com>; Tue, 3 Sep 2019 06:53:40 -0700 (PDT)
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8A9312004C for <its@ietf.org>; Tue, 3 Sep 2019 06:53:39 -0700 (PDT)
Received: by mail-wr1-x42a.google.com with SMTP id 30so6644890wrk.11 for <its@ietf.org>; Tue, 03 Sep 2019 06:53:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ANgj0r64m8ZASTUWTKHyc73bAPm5zQ13M/fRbminY3g=; b=l+jf7MPVNLXB1Y/QAy2kg5NqiOC2or44me+oWgwO5F6XOh7iEIHCE5EPJ6D+jYEB8+ BOvORpz1sOczPcFAnriACMOU34InY50nc81UA60cr673CI22Rs4TsfcZwL9khrihvHMm KIn4fjXllZlzdPO5x81QWNuXrUJyVzO5h9kC0UYP01rkimvkhK8yAs6vm0v+cfJ416fi 5X5dvbGEwC1TN9FBFJ/3WjsOttHv4+firpLaBNrXvj+6fNhS9J0mJ4Hf+SSUgipLyzad VVPO7vm6qHEIWnzu+xQQqsJNx9O2r9EeaO06cp4oxE1CkEiz8oMV1lQseCPIPKzafa1R /3HA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ANgj0r64m8ZASTUWTKHyc73bAPm5zQ13M/fRbminY3g=; b=qxxXFdvwiYbz+TLenC1o693Ud1UC1QfEN9aEBEeKZ9G0vbpkDY9hSof4UO38RvMb60 0Tr11A7j6LRBqoqOVdlFVeTMAOQ/oOwJ/5FLQuyR5mVt+nLvLRsXSjjlRQYBecRfsxAh DJLTPwzwcJKPctF61bi19BZCXFuCdDxUZSPXGj+XAyqDvq9UWPfSdyApy21gxmoJRt6H ZOfPT6rP1uni1g/WhPTrME5T+y1lvRzpp0Z8JtiQQNuUfwF2oMqesfTnn7HEGdoeiJ4R xSlVm53Kp+8RinuiMgVuvNDtA4K4td4Rpw318d4beLC3S5qocYHo1RnowycdI2knkXyX WQoQ==
X-Gm-Message-State: APjAAAV570/vTag9fgdDaAbDVe5ZFqyCuxX0FjswoVQTT6PI9cTRpKxe ALPh6kSxOuMRvbQgVwY1dOqECOgCgnWfxg/oPxLQEJL7pTg=
X-Google-Smtp-Source: APXvYqxoTPRH8gigxfEZW3fY2igN25ggc2oOKfb8l5ljmHkRf1KUpMUjwpvkDGEJ2aEKy2FD6w2XZf7Z8gC7c0Suogw=
X-Received: by 2002:adf:e605:: with SMTP id p5mr19240175wrm.105.1567518817663; Tue, 03 Sep 2019 06:53:37 -0700 (PDT)
MIME-Version: 1.0
References: <b1f427f0-6ddc-89c9-1822-0bca8ce6185b@gmail.com> <CAL1T1NHp+rem4ioXHbyWF4v+-LVudU-EbL6Z9jTjKLV-wVhKNQ@mail.gmail.com> <e2f966fb-19b8-6744-cc72-1d1143146ded@gmail.com> <CAPK2Dew_poeFFRBwhjuajnW164b0Af7W3FuSB3Au3+7n2fN_0A@mail.gmail.com> <7311014e-330b-c416-fea2-b3b9e7a16535@gmail.com> <5d694fcb.1c69fb81.d3329.4387@mx.google.com>
In-Reply-To: <5d694fcb.1c69fb81.d3329.4387@mx.google.com>
From: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Date: Tue, 03 Sep 2019 22:53:01 +0900
Message-ID: <CAPK2DexmpZdjO6hL0wf+6FvaF3mHiE6q-b8JM3WX+aw83V08rA@mail.gmail.com>
To: François Simon <fygsimon@gmail.com>
Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com>, "skku_iotlab_seminar@googlegroups.com" <skku_iotlab_seminar@googlegroups.com>, Chris Shen <shenyiwen7@gmail.com>, "its@ietf.org" <its@ietf.org>, "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000004e3fdf0591a66aff"
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/Wtv3e4urnI1J8A8YiMDj-lYP5j0>
Subject: Re: [ipwave] traffic lights status displayed in the car, and thelatency problem
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: Tue, 03 Sep 2019 13:53:47 -0000

Hi Francois,
Your send documents seem useful.
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.

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.

Best Regards,
Paul




On Sat, Aug 31, 2019 at 1:33 AM <fygsimon@gmail.com> wrote:

> The 802.11 OCB was never intended to communicate with the traffic
> controller, the RSE is.
>
> As far as for latency, It is almost impossible to determine the latency of
> an 802.11 OCB (it is CSMA based).
>
>
>
> 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 <alexandre.petrescu@gmail.com>
> *Sent: *Friday, August 30, 2019 6:31 AM
> *To: *Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com>
> *Cc: *skku_iotlab_seminar@googlegroups.com; Chris Shen
> <shenyiwen7@gmail.com>; 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>>
> 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>>>
>
> >      > 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>>
>
> >      > 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>>
>
> >
>
> >     _______________________________________________
>
> >     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
>
>
>


-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com, pauljeong@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>