Re: [ipwave] ITU-R liaison statement 1686

Alexandre Petrescu <> Thu, 22 October 2020 09:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 219D23A0808 for <>; Thu, 22 Oct 2020 02:52:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.425
X-Spam-Level: *
X-Spam-Status: No, score=1.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NICE_REPLY_A=-0.247, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001, URI_DOTEDU=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 73cioz7IrWWs for <>; Thu, 22 Oct 2020 02:52:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9641E3A07E6 for <>; Thu, 22 Oct 2020 02:52:50 -0700 (PDT)
Received: from ( []) by (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 09M9qlAN011555 for <>; Thu, 22 Oct 2020 11:52:47 +0200
Received: from (localhost []) by localhost (Postfix) with SMTP id B17F7204303 for <>; Thu, 22 Oct 2020 11:52:47 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTP id A6D74204214 for <>; Thu, 22 Oct 2020 11:52:47 +0200 (CEST)
Received: from [] ( []) by (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 09M9qlpL027742 for <>; Thu, 22 Oct 2020 11:52:47 +0200
References: <> <> <> <> <> <> <> <> <>
From: Alexandre Petrescu <>
Message-ID: <>
Date: Thu, 22 Oct 2020 11:52:48 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.3.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
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: Thu, 22 Oct 2020 09:52:55 -0000

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

> 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

 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).


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: 
> <>
>>>>>>> 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