Re: [ipwave] ITU-R liaison statement 1686

"Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com> Thu, 22 October 2020 12:33 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 D88983A0B2E for <its@ietfa.amsl.com>; Thu, 22 Oct 2020 05:33:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level:
X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01, URIBL_BLOCKED=0.001, URI_DOTEDU=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 Q1y_iKdloY9M for <its@ietfa.amsl.com>; Thu, 22 Oct 2020 05:33:30 -0700 (PDT)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 263E03A0898 for <its@ietf.org>; Thu, 22 Oct 2020 05:33:30 -0700 (PDT)
Received: by mail-lf1-x129.google.com with SMTP id a7so2027857lfk.9 for <its@ietf.org>; Thu, 22 Oct 2020 05:33:29 -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=h1b3l7X4llUu07OaCOar1rK+E1vIDc/8cTQG1nNg7CY=; b=F5Wm8PQGLodmtcsp4Uy5KPy18M38zHhj+u48aXWFlLGxCgq4cay5DXL1KM8Jy7gz43 zMZ2vAnzSsdhc7/gcVsNEyb432+CsBMMujIpSyJIyzPiMHEDwd6mo6aavEL44OTbPWo/ dDi7T3xsZQtDv/o6WTFaYR/kdJNvz6LCThxjFyLuSxzTQBKBeFqkdRcxJeP8cjvkxhJq BXk2ONoV/qIxLUhn3Sw5ACXxjHQ570LO5u+IJN3HM4x46rjqofhesE+ImmLN/QuwFivc EgWTmkFJRq5UPWmNiU2qYP6JKrymEuPW1P7dDIJ7+eFc3Ix7a7mYqpJdqmQlyplqKjrd hrnQ==
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=h1b3l7X4llUu07OaCOar1rK+E1vIDc/8cTQG1nNg7CY=; b=LPSkuBaKG6B7HUNYDW0kX2ZiSQ0Z28vxz2wdEmrcjYUf6MlxxLala3cC+dLX5NvtHa +Mi7YnMcFj/2+Ko6RDpTO8hTxT9dBFjUCzcbJihcmgpgnwFdLwMMt0/hQvXpdrV78Ksq 4IbJQcf0W/0DqL5CBAzw4mAzwyDCOsbhC3VslbzSw6b+6Aqi72z3yAtHe6aGn7R4ySkp XXmcb+rA4JYW16QwjEps+nkH9fsUub4ow0dnbtzP+G0pTbZR7kCLSoD3Ixhvqf5spB0u 9+jrAsvUU87w2sFRT68NFEtYdibJX3i7FYuhSIm0feZJ0FB9GF+svpFZmiy3p24d0YzM 8fZg==
X-Gm-Message-State: AOAM532ybvfYPc1u8vwvyLVHMKpNJSCRiak3WhPJKWfPDwbFV/veKNIn pZIKHxX4Ka71tJGWgMs/zhL6JJjiG19B6/safuI=
X-Google-Smtp-Source: ABdhPJwQdqrnaNXi5l8Ue3VyamR69oSZkxT28fQ06yAqdCr1qksRS9c+q314YwIYJJpCNHLSRC05ly+4C9GuAevDYdE=
X-Received: by 2002:a19:e03:: with SMTP id 3mr852163lfo.335.1603370007918; Thu, 22 Oct 2020 05:33:27 -0700 (PDT)
MIME-Version: 1.0
References: <4725B596-F5FA-49F9-A312-BC40CD053F23@kuehlewind.net> <9af15ae85892d25b98fc6dda98a8851c@vigilsec.com> <CAPK2DexczsruB-PwP0VXk6eS89F1ZQitOEJEASB1hAraQJR8cw@mail.gmail.com> <eb8f818c-a246-099f-8de3-567bcbbc023e@gmail.com> <1c00cc5f-3b7e-ae37-6f2f-1c28f0c2d3a4@gmail.com> <0fcd17f5b58ea9249bfb97acd9894ffe@vigilsec.com> <bf630134-5830-d175-efbc-3dc330e7bc50@gmail.com> <ACC30712-CBA5-43B4-BF87-2B762894D1B5@vigilsec.com> <6ab7d79a-25af-f8ae-280b-c66d88f87a38@gmail.com> <ab59a476-73d0-3ab1-771b-441b950f5beb@gmail.com>
In-Reply-To: <ab59a476-73d0-3ab1-771b-441b950f5beb@gmail.com>
From: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Date: Thu, 22 Oct 2020 21:32:50 +0900
Message-ID: <CAPK2Dez+PFoNEKY1d2fFLRd0dLfkaEmV2abXO5VJ0+qf3y1NBw@mail.gmail.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: its@ietf.org, skku-iotlab-members <skku-iotlab-members@googlegroups.com>, "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000c3fead05b241ab33"
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/mrjv8g6ZV4WPLvysN6qolmEnkA0>
Subject: Re: [ipwave] ITU-R liaison statement 1686
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, 22 Oct 2020 12:33:34 -0000

Hi Alex,
Thanks for your informative answers.

Russ,
you can decide whether to provide some of Alex's answers for ITU-R or not.

Thanks.

Best Regards,
Paul


On Thu, Oct 22, 2020 at 6:53 PM Alexandre Petrescu <
alexandre.petrescu@gmail.com> wrote:

> Hi, Russ,
>
> I looked again at the liaison statement from ITU-R, and at the freely
> available documents it refers to.  I read again our discussions.
>
> I do not know how to answer best to that statement: there is no
> procedure to reply to it, nor a form at some URL, and not sure about
> the individual/organization status.
>
> However, I think the questions this liaison raises are very relevant.
>
> Allow me to  respond to these questions here, until I can understand how
> and whether a more 'official' response is needed.
>
> I would like to know what other participants in this group think?
>
>  From document R-QUE-SG05.261-2019-MSW-E.doc:
> > 1     What is the definition of connected automated vehicle (CAV) in
> > the context of ITS?
>
> I think the I-D 'Vehicular Networking', the Charter and RFC 8691 do not
> define the term CAV.  The Charter does mention 'connected automated
> driving'.
>
> > 2     What are the radiocommunication elements for CAVs?
>
> A CAV embarks an Internet Protocol On-Board Unit (IP-OBU.)  Along the
> road there might be IP-RSUs deployed.  The IP-OBU and IP-RSU use
> communication interfaces.  These communication interfaces are at 5.9GHz
> and potentially other frequency bands at PHY layer.  At networking layer
> these communication interfaces use IP, as specified in RFC 8691.
>
> > 3     What are the overall objectives and requirements for CAVs,
> > including: –  service requirements: service type, service concept,
> > grade of service;
>
> There are numerous services for CAVs that are implemented using IP.  For
> example, in platooning the steering service is used on IP between two CAVs.
>
> > –     radiocommunication requirements: sensors, radio interfaces, data
> > rate, latency, reliability;
>
> Data rate of IP packets on 802.11bgn OCB mode is around 16mbit/s.  The
> latency is between 0.9ms and 5ms.  On 802.11ac OCB mode (probably
> 802.11bd) the data rate might be 1Gbit/s and latency 500microseconds.
>
> > –     improvement factors: safety, control, energy savings, traffic
> > management, congestion control?
>
> > 4     Which radiocommunication systems have the capabilities to support
> > CAV requirements?
>
> 802.11-OCB (OCB mode for 802.11bgn and for 802.11ac).
> 4G, 4G+, and 5G.
>
> > 5     What CAV functions might benefit from spectrum harmonization?
>
> All CAV functions that use IP might benefit from harmonization at all
> layers.  At app layer, CAM messages might benefit from harmonization
> with BSM messages to benefit inter-continental markets (a single
> software stack).  Further, at networking layer these CAM or BSM messages
> might benefit from being transmitted over IP (instead of being
> transmitted without networking header when on 5.9GHz and with IP when on
> 5G).  Finally, on spectrum, the transmission of all V2X-specific
> messages - on IP - in only a few (ideally just one) frequency band will
> benefit interoperability.
>
> > 6     What are the spectrum requirements for CAV radiocommunication
> > including: –  suitable bands;
>
> Currently most CAVs radiocommunication used for key CAV-specific
> operation are at 5.9GHz and some are at 2.6GHz (4G) and some at 3.6GHz
> (5G).  However, many CAVs depend also very tightly on localization
> involving GNSS systems; the reception of GNSS is around 1.2GHz including
> GPS, Galileo and others.
>
> Many CAV-related communication systems involve also IP on WiFi at
> 2.4GHz, at 5.4GHz and potentially others.
> > –     spectrum bandwidth needed?
>
> width of the band?  (like 10MHz?)
> or bandwidth ? (like 10Mbit/s ?)
>
> It depends.  Essentially, a CAV might function with a bandwidth
> requirement very low (3G-class bandwidth of 300kbit/s) - just attach a
> comma.AI-powered smartphone on the dashboard and plug it on the car's
> CAN.   Other scenarios might need higher bandwidth requirements
> between cars: use IP to stream lidar data between vehicles in a platoon,
> or to stream video for 'see-thru'.  That bandwidth requirement is about
> 1Gbit/s.
>
>  From the document R19-WP5A-C-0085!N16!MSW-E.doc:
> > •     Vehicles Platooning - enables the vehicles to dynamically form a
> > group travelling together
>
> Please note the the Internet Draft of IPWAVE WG titled "Vehicular
> Networking" also defines platooning, in its section 3.1.
>
>
> > Spectrum other than that previously recommended for ITS may be
> > desirable for CAV communications. For example, it may be possible
> > that platooning and/or other very close range cooperative
> > maneuvering communications could best be effectively supported in EHF
> > (30-300 GHz) bands. Laboratory experimentation and field test
> > results becoming available during this ITU-R study period are likely
> > to identify suitable frequency bands, if any, for these types of
> > communication, which could be specifically used for CAV use cases.
>
> For my part, the experimentations of platooning that I am aware of run
> on IP at 5.9GHz.
>
> In order to consider platooning with IP at other frequency bands
> (30-300GHz) there is a need for such devices to appear cheaply on the
> market, and a need for the 5.9GHz to exhibit overcrowdedness, a need for
> codecs to reach limits in providing the necessary bandwidth.
>
> Personally, I am not aware of cheap interfaces in a band somewhere
> between 30GHz and 300GHz, but I wonder whether they exist.
>
> The overcrowdedness at 5.9GHz: currently I think too few 5.9GHz
> deployments exist to consider them overcrowded.  There are much less
> 5.9GHz IP-RSUs than there are 2.4GHz Access Points for WiFi, for examle.
>
> The bandwidth requirements: currently bands of 10MHz width in the 5.9GHz
> range could be grouped together (maybe into 20MHz or 40MHz bands) such
> that the codecs achieve bandwidths of aprroximately 10Gbit/s, in theory.
>   If that is not possible because the bands are already reserved for
> particular uses, then it would be good to find a new space for such
> bands beyond 5.9GHz.  I wonder whether there could be some place found
> for this somewhere between 5.9GHz and 30GHz.
>
> Finally, in addition to platooning, I would like to mention a relevant
> CAV use case that will  almost certainly need IP and IPv6 in particular.
>   The TOD (tele-operated driving, a definition by 5GAA) is a low latency
> guaranteed delivery use-case where a vehicle is controlled by an
> operator in a control center, or by law enforcement or by the car owner
> ('call my car').  The controller sends commands to the car and receives
> video on a feedback.  In this use-case it is necessary to be able to
> discover, identify and reach the car in a scalable manner; the large
> IPv6 address space can ensure that is possible  (with IPv4 is not
> possible).
>
> Alex
>
>
>
> Le 21/10/2020 à 21:55, Alexandre Petrescu a écrit :
> > Hi, Russ,
> >
> > Indeed the scope I wrote might be well beyond the scope of the WG. I
> > just listed topics concerning me now.  But I will not be responding
> > to ITU-R liaison, also because it seems to request material rather
> > from organizations.
> >
> > Alex
> >
> > Le 21/10/2020 à 19:56, Russ Housley a écrit :
> >> Alex:
> >>
> >> This seems to be well beyond the scope of the IPWAVE WG.  Perhaps
> >> you should respond as an individual.
> >>
> >> Russ
> >>
> >>
> >>> On Oct 20, 2020, at 8:22 AM, Alexandre Petrescu
> >>> <alexandre.petrescu@gmail.com> wrote:
> >>>
> >>>
> >>>
> >>> Le 17/10/2020 à 17:17, housley@vigilsec.com a écrit :
> >>>> Since it is from ITU-R, it is about spectrum.
> >>>
> >>> Well, the liaison statement asks this: "Working Party 5A kindly
> >>> requests the interested external organizations to provide
> >>> material on the description, architecture, applications,
> >>> technologies, and operational scenarios of CAVs and the
> >>> radiocommunication requirements for CAVs."
> >>>
> >>> This is a very broad request.  I think it is much more than just
> >>> spectrum requirements for CAVs.  I think only their request of
> >>> 'radiocommunication requirements for CAVs' might indeed relate
> >>> to spectrum requirements.
> >>>
> >>> With respect to 'radiocommunication requirements for CAVs' we
> >>> could list the following: - the use of the 5.9GHz band specific
> >>> to DSRC as used in automated vehicles.  Use IP on the control
> >>> channel of this band. - the use of 3.5GHz band specific to 5G as
> >>> used in demonstrations of tele-operation of automated shuttle,
> >>> such as the October Stockholm demonstration made by Ericsson.
> >>>
> >>> With respect to 'description, architecture, applications,
> >>> technologies and operation scenarios' we could provide a pointer
> >>>  to the Internet Draft titled 'IPv6 Wireless Access in Vehicular
> >>>  Environments (IPWAVE): Problem Statement and Use Cases'.
> >>>
> >>> With respect to just the 'operational scenarios' we can provide
> >>> a few additional pointers to CAV-specific use-cases of
> >>> communication technologies: - the 6G use-cases relating to
> >>> vehicular networking (some such use cases are listed in the 6gip
> >>> email list of IETF), - the ITU-T FG-NET2030 use-cases that
> >>> relate to automated driving, - the recent ToD (Tele Operated
> >>> Driving) use-case described by 5GAA.
> >>>
> >>> An additional possibility might be to provide a list of projects
> >>> involving the use of communication systems in CAVs (Connected
> >>> Automated Vehicles).
> >>>
> >>> Alex
> >>>
> >>>
> >>>> Russ On 2020-10-17 04:37, Alexandre Petrescu wrote:
> >>>>> (For information, the ISO TC204 'ITS' too is looking at
> >>>>> creating, or enhancing, an 'ADCG' - Automated Driving
> >>>>> Control Group.  It is a group trying to oversee how to bring
> >>>>> the different characteristics of work related to AD into the
> >>>>> various WGs of that TC.  They have started a document titled
> >>>>> 'Terms of Reference' on which they might need feedback. This
> >>>>>  is not a liaison statement from ISO TC204, just a FYI.) Alex
> >>>>>  Le 17/10/2020 à 10:31, Alexandre Petrescu a écrit :
> >>>>>> I think too it is a good idea to point to our I-D. But,
> >>>>>> since the ITU-R liaison is about CAV (Connected and
> >>>>>> Automated Vehicles), I think there would be advantageous to
> >>>>>> point to particular places in the draft that make for
> >>>>>> Connected and for Automated. For the Connected part it is
> >>>>>> straightforward, because many communication protocols are
> >>>>>> referred to in the I-D. For the Automated part, maybe the
> >>>>>> V2V use-cases described in the I-D. Maybe other parts of
> >>>>>> the I-D as well. Alex Le 17/10/2020 à 09:47, Mr. Jaehoon
> >>>>>> Paul Jeong a écrit :
> >>>>>>> Hi Russ, We can point out our IPWAVE Problem Statement
> >>>>>>> and Use Cases Draft can be a good foundation for their
> >>>>>>> work:
> >>>>>>>
> https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-19
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>
> >>>>>>>
> >>>>>>>
> > <https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-19>
> >>>>>
> >
> >
> Thanks.
> >>>>>>> Best Regards, Paul On Sat, Oct 17, 2020 at 4:05 AM
> >>>>>>> <housley@vigilsec.com <mailto:housley@vigilsec.com>>
> >>>>>>> wrote: The ITU-R sent a liaison:
> >>>>>>> https://datatracker.ietf.org/liaison/1686/
> >>>>>>> <https://datatracker.ietf.org/liaison/1686/> Does anyone
> >>>>>>> think that the IPWAVE WG should reply? Russ
> >>>>>>> _______________________________________________ its
> >>>>>>> mailing list its@ietf.org <mailto:its@ietf.org>
> >>>>>>> https://www.ietf.org/mailman/listinfo/its
> >>>>>>> <https://www.ietf.org/mailman/listinfo/its> --
> >>>>>>> =========================== Mr. Jaehoon (Paul) Jeong,
> >>>>>>> Ph.D. Associate Professor Department of Computer Science
> >>>>>>> and Engineering 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
> >>>>>> _______________________________________________ its
> >>>>>> mailing list its@ietf.org
> >>>>>> https://www.ietf.org/mailman/listinfo/its
> >>>>> _______________________________________________ its mailing
> >>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its
> >>
> >
> > _______________________________________________ its mailing list
> > its@ietf.org https://www.ietf.org/mailman/listinfo/its
>
> _______________________________________________
> its mailing list
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its
>


-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Computer Science and Engineering
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>