Re: [ipwave] ITU-R liaison statement 1686

Russ Housley <> Fri, 23 October 2020 16:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 769693A0EDF for <>; Fri, 23 Oct 2020 09:39:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F2hMDZVz8VDh for <>; Fri, 23 Oct 2020 09:39:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0BF523A0ED9 for <>; Fri, 23 Oct 2020 09:39:30 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 73C8C300B7E for <>; Fri, 23 Oct 2020 12:39:27 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id L24FhxWe587I for <>; Fri, 23 Oct 2020 12:39:24 -0400 (EDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id 583B5300A3B; Fri, 23 Oct 2020 12:39:24 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Russ Housley <>
In-Reply-To: <>
Date: Fri, 23 Oct 2020 12:39:25 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <>
To: Alexandre Petrescu <>
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: <>
Subject: Re: [ipwave] ITU-R liaison statement 1686
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 23 Oct 2020 16:39:32 -0000

Alex, you have certainly done your homework.  Thanks for putting in the effort.  That said, I am quite reluctant to speak to the ITU-R as the IETF IPWAVE WG with only two people offering a point of view.  More people need to speak up if we are going to make a formal response.


> On Oct 22, 2020, at 5:52 AM, Alexandre Petrescu <> 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 <> wrote:
>>>> Le 17/10/2020 à 17:17, 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:
>> <>
> Thanks.
>>>>>>>> Best Regards, Paul On Sat, Oct 17, 2020 at 4:05 AM < <>> wrote: The ITU-R sent a liaison: <> Does anyone think that the IPWAVE WG should reply? Russ _______________________________________________ its mailing list <> <> -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department of Computer Science and Engineering Sungkyunkwan University Office: +82-31-299-4957 Email: <>, <> Personal Homepage: <> _______________________________________________ its mailing list
>>>>>>> _______________________________________________ its
>>>>>>> mailing list
>>>>>> _______________________________________________ its mailing list
>> _______________________________________________ its mailing list
> _______________________________________________
> its mailing list