Re: [ipwave] PC5 and 5.9GHz?

Jerome Haerri <jerome.haerri@eurecom.fr> Thu, 18 April 2019 13:55 UTC

Return-Path: <jerome.haerri@eurecom.fr>
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 5C8B512014A for <its@ietfa.amsl.com>; Thu, 18 Apr 2019 06:55:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 J_hpKHQTFKA8 for <its@ietfa.amsl.com>; Thu, 18 Apr 2019 06:55:49 -0700 (PDT)
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210]) by ietfa.amsl.com (Postfix) with ESMTP id E563612033C for <its@ietf.org>; Thu, 18 Apr 2019 06:55:48 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.60,366,1549926000"; d="scan'208";a="9950074"
Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236]) by drago1i.eurecom.fr with ESMTP; 18 Apr 2019 15:55:47 +0200
Received: from [10.53.14.224] (unknown [92.184.112.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtps.eurecom.fr (Postfix) with ESMTPSA id 3DBA832E; Thu, 18 Apr 2019 15:55:47 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Jerome Haerri <jerome.haerri@eurecom.fr>
Mime-Version: 1.0 (1.0)
Date: Thu, 18 Apr 2019 15:50:24 +0200
Message-Id: <EA7C2CE7-599F-4352-8EA7-3B20B6461950@eurecom.fr>
References: <abfbf312-be3c-c957-d58e-67b141697a14@gmail.com> <LEXPR01MB06697DF790A19AEBC7E7E4D2D1250@LEXPR01MB0669.DEUPRD01.PROD.OUTLOOK.DE> <c9f2c360-dee7-c0cb-5cce-e493ef203c42@gmail.com>
Cc: Dirk.von-Hugo@telekom.de, its@ietf.org
In-Reply-To: <c9f2c360-dee7-c0cb-5cce-e493ef203c42@gmail.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
X-Mailer: iPhone Mail (16E227)
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/tLFsMOr-3pzNg4rmwar1TRienqc>
Subject: Re: [ipwave] PC5 and 5.9GHz?
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, 18 Apr 2019 13:55:53 -0000

Hi Alex, Dirk,

the EU is quite clear: there should not be technology ban on the ITS-G5 as long as it is for ’safety-related’ applications for road ITS. 
This being said, for another technology to use ITS-G5 spectrum, it must coexist with existing technologies, and be commercially available.

For now, the EU commission in its DA estimates that these two points are not there yet, thus recommened to use ITS-G5 on the CCH, only (the EU still pushes for both technologies in other channels for Day 2 applications..no regulation yet)

Indeed as of today, LTE-V2X and ITS-G5 cannot coexist at PHY and MAC layer..

Both ETSI ERM and C2C are working on PHY and MAC extentions for coexistence.

Yet, indeed even at L3, we should envision ways to differentiate between technologies. Let’s see once PHY/MAC coexistence will be completed...

BR,

Jérôme

Envoyé de mon iPhone

> Le 18 avr. 2019 à 15:17, Alexandre Petrescu <alexandre.petrescu@gmail.com> a écrit :
> 
> 
> 
>> Le 17/04/2019 à 14:32, Dirk.von-Hugo@telekom.de a écrit :
>> Hi Alex,
>> I strongly agree with you that we need a precise definition on what we mean with cellular V2X (often denoted as C-V2X in general – so covering LTE and 5G/NR) – especially since – as you correctly pointed out - 3GPP has none such official definition as LTE-V2X or NR-V2X .
>> However when defining LTE-V2X we should be aware that there are two different modes of operation for V2X communication in 3GPP cellular systems (as also described in Annex A.5 of PS document https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-08).
>> E.g. according to 3GPP TR 21.914 giving a Release 14 (i.e. LTE) Description and Summary of Rel-14 Work Items, but similarly also for 5G/NR or Rel. 15 and higher (here in still draft TR 21.915) the modes of operation are described as
>> -Direct V2X communication between UEs over a 3GPP sidelink (PC5 interface)
>> -V2X communication over LTE-Uu interface (i.e. via base stations / eNBs)
> 
> Dirk,
> 
> A colleague in a group perform a study of latency comparison between 802.11-OCB and LTE-Uu between cars.  It is simulation.  They found numbers comparing the latency.
> 
> On another hand,
> 
> Do we know whether the use of the PC5 interface is allowed at 5.9GHz?
> 
> That may have an impact on an IP-over-OCB thing:
> - if PC5 is allowed at 5.9GHz then the only way to make sure it co-exists with OCB at same frequency is to use Traffic Class or Flow Label field in IPv6 header.  That is a good work item.
> 
> If that work item works, then one may need to map these QoS fields into the QoS fields of the 802.11 header, fields required in the IPv6-over-OCB document.
> 
> Alex
> 
>> In addition there are 2 different modes for PC5/sidelink:
>> -in coverage of cellular system with LTE assistance
>> -out of coverage: ad-hoc mode w/o assistance … very similar to OCB.
>> So I would recommend to specify more exactly what we have in mind.
>> LTE-V2X: the transmission of ETSI CAM and DENM messages over IP over a cellular link such as 3GPP 4G – both via base station and directly between vehicles
>> Or more general:
>> C-V2X: the transmission of ETSI CAM and DENM messages over IP over a cellular link such as 3G, 4G and successors – both in infrastructure mode (via base station / Uu interface) and ad-hoc mode (direct link / sidelink interface) if available [since sidelink is only specified for 4G/5G]
>> Or one may even reflect differentiation between those modes in the acronym (which I would not recommend here being not in scope for this document)
>> Just my 2 cents
>> Kind regards
>> Dirk
>> *From:*its <its-bounces@ietf.org> *On Behalf Of *Alexandre Petrescu
>> *Sent:* Mittwoch, 17. April 2019 13:18
>> *To:* its@ietf.org
>> *Subject:* [ipwave] LTE-V2X term in Problem Statement document
>> Hi IPWAVErs,
>> The IPWAVE Problem Statement document uses the term 'LTE-V2X' at one point. ("e.g., IEEE 802.11-OCB and LTE-V2X")
>> I would like to suggest to make a careful definition of the term 'LTE-V2X'.
>> One would expect the term 'LTE-V2X' to be defined precisely at 3GPP or similar.  But that is not the case.  The 3GPP document that is closest to this term is RP-161298, publicly available, defines the term 'LTE_V2X' (remark underscore '_', instead of dash '-').
>> I suggest the addition of the following term in the Problem Statement draft:
>> LTE-V2X: the transmission of ETSI CAM and DENM messages over IP over a cellular link such as 3G, 4G and successors.
>> Alex
> 
> _______________________________________________
> its mailing list
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its