Subject: [ipwave] LTE-V2X term in Problem Statement document

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 17 Apr 2019 13:18:23 +0200

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

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Wed, 17 Apr 2019 20:20:49 +0900

Alex,
I got it.

I will reflect your comments on LTE_V2X along with its definition.

Thanks.

Best Regards,
Paul

On Wed, Apr 17, 2019 at 8:18 PM Alexandre Petrescu <
[email-masked]> wrote:

> _______________________________________________
> its mailing list
> [email-masked]
> 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: [email-masked], [email-masked]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>

---

From: <[email-masked]>
Date: Wed, 17 Apr 2019 12:32:28 +0000

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)

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 <[email-masked]> On Behalf Of Alexandre Petrescu
Sent: Mittwoch, 17. April 2019 13:18
To: [email-masked]
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")

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

LTE-V2X: the transmission of ETSI CAM and DENM messages over IP over a cellular link such as 3G, 4G and successors.

Alex

---

From: Jérôme Härri <[email-masked]>
Date: Wed, 17 Apr 2019 14:46:09 +0200

Hi Alex, All,

Good point…we indeed really need to avoid multiple acronyms.

One aspect worth mentioning is that there is no ‘official’ naming for what we try to indicate in 3GPP. LTE_V2X is just a WI name, which is an internal denomination (a bit when you are in a IEEE PAR and you have a working title, NGV instead of now 11BD). Of course, that is as far the only ‘one-term’ does it all to indicate this. But I would also suggest not to simply use this term, as it implies many unclear aspects:

1)      There are other work items on V2X, which actually do not use the ‘_’, e.g. eV2X, eV2XARC, V2XIMP etc..

2)      This WI no longer exist per say (as created in 2016)..and never produced a specific standard (by itself…, which would have taken the name)….it has been split in various other WIs, like LTE_V2X-Core, LTE_V2X-Perf, etc…

3)      V2X Slidelink

4)      V2X Uu (V2X Uu is not per say part of the WI LTE_V2X), but I suspect that IETF will include this as well.

5)      V2X Direct Communication (different from V2X Discovery)

6)      3GPP generally defines”V2X Services”…

7)      If we refer to horizontal communication, Sidelink is most likely used…but transparently includes D2D and V2X as these are configuration of the former. 

8)      5GAA uses C-V2X (taken from a US proposal, as the US do not use the term LTE, and prefer Cellular ‘whatever’

9)      ETSI/C2C uses LTE-V2X (here, as there was nothing to actually refer to…)

10)   Even found names such as LTE-V, or LTE short range (LTE Sidelink), LTE long range (LTE Uu)

So, my point is: I do not think there is one ‘term’…so, there should be a  decision at IETF to commonly use one, whatever it is, but having a section describing that it refers to (and linking to all other namings). 

Considering that 3GPP does not really has one (or only one), let’s review what is there:

·         SAE uses  (Cellular V2X, would suggest to avoid this, as this is generally not accepted in EU norms…as LTE V2X mode 4 is far from being ‘cellular’),  

·         ISO CALM uses LTE-V2X (ISO/FDIS 17515-3 Intelligent transport systems -- Evolved-universal terrestrial radio access network -- Part 3: LTE-V2X, https://www.iso.org/obp/ui/#iso:std:iso:17515:-3:dis:ed-1:v1:en) 

·         ETSI uses LTE-V2X (future EN (European Norm) 304 613, or the publicly available TS 103 613)…as the term has been used for much more time that IETF…, 

·         IEEE 1609.3 – I could not find a reference…but they might in the update cycle..

So, to be coherent between standards (ETSI, IEEE, SAE and ISO, considering we cannot refer to a standard in 3GPP having a single simple acronym, as far as I know) and common literature. I would suggest to use LTE-V2X as general term, but if LTE_V2X is selected, that is OK as well…we should just explain why and cycle other terms to avoid confusion…

My two cents,

BR,

Jérôme

From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Wednesday 17 April 2019 13:18
To: [email-masked]
Subject: [ipwave] LTE-V2X term in Problem Statement document

Hi IPWAVErs,

Alex

---

From: Jérôme Härri <[email-masked]>
Date: Wed, 17 Apr 2019 15:25:31 +0200

Dear Dirk,

Thanks. I guess we replied with similar thoughts. Now, on your definition, I would also avoid using this:

 

JHNOTE: we should not link CAM/DENM on LTE-V2X…these are layered aspect…LTE-V2X can take whatever comes from higher layers, as long as it is packet-based (no streams) and (most likely) periodical (from the semi-persistent scheduling of the LTE Slidelink V2X scheduler), even if this last point can be discussed.

 

JHNOTE: I think we should not use C-V2X, as the denomination ‘C’ is for ‘Cellular’, which might not be fully the case (e.g. LTE Prose mode 4, a.k.a V2X)

Best Regards,

Jérôme

From: its [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday 17 April 2019 14:32
To: [email-masked]; [email-masked]
Subject: Re: [ipwave] LTE-V2X term in Problem Statement document

Hi Alex,

Or more general:

Just my 2 cents

Kind regards

Dirk

Hi IPWAVErs,

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 17 Apr 2019 15:29:07 +0200

Le 17/04/2019 à 15:25, Jérôme Härri a écrit :
> Dear Dirk,
> 
> Thanks. I guess we replied with similar thoughts. Now, on your 
> definition, I would also avoid using this:
> 
> cellular link such as 3GPP 4G – both via base station and directly 
> between vehicles
> 
> JHNOTE: we should not link CAM/DENM on LTE-V2X…these are layered 
> aspect…LTE-V2X can take whatever comes from higher layers, as long as it 
> is packet-based (no streams) and (most likely) periodical (from the 
> semi-persistent scheduling of the LTE Slidelink V2X scheduler), even if 
> this last point can be discussed.
> 
> 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]
> 
> JHNOTE: I think we should not use C-V2X, as the denomination ‘C’ is for 
> ‘Cellular’, which might not be fully the case (e.g. LTE Prose mode 4, 
> a.k.a V2X)

Is C-V2X term already defined by Qualcomm?  Or by another SDO?

Alex

> 
> Best Regards,
> 
> Jérôme
> 
> *From:*its [mailto:[email-masked]] *On Behalf Of 
> [email-masked]
> *Sent:* Wednesday 17 April 2019 14:32
> *To:* [email-masked]; [email-masked]
> *Subject:* Re: [ipwave] LTE-V2X term in Problem Statement document
> 
> 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)
> 
> -in coverage of cellular system with LTE assistance
> 
> -out of coverage: ad-hoc mode w/o assistance … very similar to OCB.
> 
> 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 <[email-masked]> *On Behalf Of *Alexandre Petrescu
> *Sent:* Mittwoch, 17. April 2019 13:18
> *To:* [email-masked]
> *Subject:* [ipwave] LTE-V2X term in Problem Statement document
> 
> Hi IPWAVErs,
> 
> 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 '-').
>

---

From: Jérôme Härri <[email-masked]>
Date: Wed, 17 Apr 2019 15:42:54 +0200

Hi Alex,

I do not know. What I know is that C-V2X is the general denomination in the US for LTE for V2X services, itself also confusing and misleading...as depending on who talks about it, it is either the sidelink V2X (exclusively) or includes everything: mode 4 (ad-hoc), mode 3 (eNB supervised) and Uu. 

BR,

Jérôme
-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Wednesday 17 April 2019 15:29
To: Jérôme Härri; [email-masked]; [email-masked]
Subject: Re: [ipwave] LTE-V2X term in Problem Statement document

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 18 Apr 2019 15:17:43 +0200

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

---

From: Jerome Haerri <[email-masked]>
Date: Thu, 18 Apr 2019 15:50:24 +0200

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 <[email-masked]> a écrit :
> 
> 
> 
> 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,
> 
> - 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
>

---

From: Jerome Haerri <[email-masked]>
Date: Thu, 18 Apr 2019 15:57:54 +0200

Dear All, 

just minor modification to avoid misunderstanding:
> the EU is quite clear: there should not be technology ban on the ITS-G5 SPECTRUM

Sorry about the confusion,

Jérôme

Envoyé de mon iPhone

> Le 18 avr. 2019 à 15:50, Jerome Haerri <[email-masked]> a écrit :
> 
> Hi Alex, Dirk,
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 18 Apr 2019 19:08:45 +0200

>> the EU is quite clear: there should not be technology ban on the 

I dont understand ban.

My question is simple: is PC5 at 5.9GHZ?

Alex

> Le 18 avr. 2019 à 15:50, Jerome Haerri <[email-masked] 
> <mailto:[email-masked]>> a écrit :
> 
>> 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)
>>
>> 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 
>>> <[email-masked] <mailto:[email-masked]>> 
>>> a écrit :
>>>
>>>
>>>
>>>> Le 17/04/2019 à 14:32, [email-masked] 
>>>> <mailto:[email-masked]> 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 .
>>>> 5G/NR or Rel. 15 and higher (here in still draft TR 21.915) the 
>>>> modes of operation are described as
>>> 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
>>>
>>>> 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:
>>>> mode (via base station / Uu interface) and ad-hoc mode (direct link 
>>>> / sidelink interface) if available [since sidelink is only specified 
>>>> for 4G/5G]
>>>> acronym (which I would not recommend here being not in scope for 
>>>> this document)
>>>> Just my 2 cents
>>>> Kind regards
>>>> Dirk
>>>> *From:*its <[email-masked] <mailto:[email-masked]>> *On 
>>>> Behalf Of *Alexandre Petrescu
>>>> *To:* [email-masked] <mailto:[email-masked]>
>>>> 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 '-').
>>>> LTE-V2X: the transmission of ETSI CAM and DENM messages over IP over 
>>>> a cellular link such as 3G, 4G and successors.
>>>> Alex
>>>
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: Jerome Haerri <[email-masked]>
Date: Thu, 18 Apr 2019 20:29:00 +0200

the standard (3GPP) even forces it (only freq. allowed for PC5 (LTE rel.14)...so yes..

But: it cannot use these frequencies now (well it got some test freq. in the US) (ITU in charge for spectrum allocation in EU) as the coexistence (PHY/MAC) with ITS-G5 needs to be solved first..

BR,

Jérôme

Envoyé de mon iPhone

> Le 18 avr. 2019 à 19:08, Alexandre Petrescu <[email-masked]> a écrit :
> 
> 
> 
>>> Le 18 avr. 2019 à 15:50, Jerome Haerri <[email-masked] <mailto:[email-masked]>> a écrit :
>>> Hi Alex, Dirk,
>>> 
>>>> Le 18 avr. 2019 à 15:17, Alexandre Petrescu <[email-masked] <mailto:[email-masked]>> a écrit :
>>>> 
>>>> 
>>>> 
>>>>> Le 17/04/2019 à 14:32, [email-masked] <mailto:[email-masked]> a écrit :
>>>>> Hi Alex,
>>>>> *From:*its <[email-masked] <mailto:[email-masked]>> *On Behalf Of *Alexandre Petrescu

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 18 Apr 2019 20:54:47 +0200

> the standard (3GPP) even forces it (only freq. allowed for PC5 (LTE rel.14)...so yes..

Thank you.  I really did not know that.

A colleague told that to me a few days ago but I was inclined to not trust.

I was thinking maybe PC5 is at 5.4GHz (not 5.9), or maybe a new 
frequency at 800 MHz, or 3.5GHZ, or 20-something, but not there where 
OCB runs (5.9).

I hope there is understanding about risks of putting together non 802.11 
headers with 802.11 headers in the same frequency.

It is sufficient to drive a little bit around to listen to 5.9GHz and 
see there is already a lot of 802.11-OCB traffic.  Not sure how can that 
coexist with PC5 because this latter does not have 802.11 headers.

> But: it cannot use these frequencies now (well it got some test freq. in the US) (ITU in charge for spectrum allocation in EU) as the coexistence (PHY/MAC) with ITS-G5 needs to be solved first..

Is PC5 using IP, like 5G does?

Alex

---

From: Jerome Haerri <[email-masked]>
Date: Thu, 18 Apr 2019 21:33:51 +0200

> I hope there is understanding about risks of putting together non 802.11 headers with 802.11 headers in the same frequency.

yes, a big one...and a tive research in fibding a solution..but it is slso political. Btw, in the US, you also have OCB 10Mhz headers coexisting with 20MHz Rlan wifi headers..also problematic..

> It is sufficient to drive a little bit around to listen to 5.9GHz and see there is already a lot of 802.11-OCB traffic.  Not sure how can that coexist with PC5 because this latter does not have 802.11 headers.

maybe in a few months I will be able to tell you how...earliest ETSI vote in this, March 2020...
> Is PC5 using IP, like 5G does?

well, 3GPP allows IPv4, IPv6, and ‘non-IP’

yet, in EU, PC5 requires the ETSI geonet stack to operate on 5.9GHz, so no (or through geonet)
As it needs the ETSI security framework (even refered in 3GPP LTE sidelink standard) and use per packet wireless congestion control ..so, good old story..

btw, not clear yet that 5G-V2X will use IP on PC5..too early to tell..unless you have news about it (or you meant LTE Uu, which uses IP)

BR,

Jérôme

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 18 Apr 2019 22:22:10 +0200

Le 18/04/2019 à 21:33, Jerome Haerri a écrit :
> 
>> I hope there is understanding about risks of putting together non
>> 802.11 headers with 802.11 headers in the same frequency.
> 
> yes, a big one...and a tive research in fibding a solution..but it is
> slso political. Btw, in the US, you also have OCB 10Mhz headers
> coexisting with 20MHz Rlan wifi headers..also problematic..
> 
>> It is sufficient to drive a little bit around to listen to 5.9GHz
>> and see there is already a lot of 802.11-OCB traffic.  Not sure how
>> can that coexist with PC5 because this latter does not have 802.11
>> headers.
> 
>>> But: it cannot use these frequencies now (well it got some test
>>> freq. in the US) (ITU in charge for spectrum allocation in EU) as
>>> the coexistence (PHY/MAC) with ITS-G5 needs to be solved first..
>> 

Ok; so I can not stop myself from asking what kind of link-layer headers 
is the PC5 using when in 'non-IP' mode.  I suppose in IP mode it does 
not use any link-layer headers, like a normal 3GPP link from UE to base 
station.

> 
> yet, in EU, PC5 requires the ETSI geonet stack to operate on 5.9GHz,
> so no (or through geonet) As it needs the ETSI security framework
> (even refered in 3GPP LTE sidelink standard) and use per packet
> wireless congestion control ..so, good old story..
> 
> btw, not clear yet that 5G-V2X will use IP on PC5..too early to
> tell..unless you have news about it (or you meant LTE Uu, which uses
> IP)

for clarification: I meant PC5, not LTE Uu.

PC5 is the one without base station.  That is the most similar to the 
use of OCB in convoys.

Alex

> 
> BR,
> 
> Jérôme
> 
> 
>> 
>> Alex
>> 
>>> BR, Jérôme Envoyé de mon iPhone
>>>>> Le 18/04/2019 à 15:57, Jerome Haerri a écrit : Dear All, just
>>>>> minor modification to avoid misunderstanding:
>>>>> Sorry about the confusion, Jérôme Envoyé de mon iPhone
>>>>>> <mailto:[email-masked]>> a écrit : 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)
>>>>>> 
>>>>>> 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
>>>>>> 
>>>>>>> <[email-masked]
>>>>>>> <mailto:[email-masked]>> a écrit :
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> <mailto:[email-masked]> 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
>>>>>>>> -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,
>>>>>>> 
>>>>>>> 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 <[email-masked]
>>>>>>>> <mailto:[email-masked]>> *On Behalf Of *Alexandre
>>>>>>>> Petrescu *Sent:* Mittwoch, 17. April 2019 13:18 *To:*
>>>>>>>> [email-masked] <mailto:[email-masked]> *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 [email-masked] <mailto:[email-masked]> 
>>>>>> _______________________________________________ its mailing
>>>>>> list [email-masked] <mailto:[email-masked]>

---

From: Jérôme Härri <[email-masked]>
Date: Fri, 19 Apr 2019 10:50:36 +0200

Hi Dick,

It always starts with IPR and royalties, indeed...then it gets political :-)

BR,

Jérôme

-----Original Message-----
From: Dick Roy [mailto:[email-masked]] 
Sent: Friday 19 April 2019 03:28
To: 'Jerome Haerri'; 'Alexandre Petrescu'
Cc: [email-masked]; [email-masked]
Subject: RE: [ipwave] PC5 and 5.9GHz?

FYI ... the PC5 vs. 802.11 in 5.9GHz is neither a political nor a technical
issue.  It is all about IPR and royalties.

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Jerome Haerri
Sent: Thursday, April 18, 2019 12:34 PM
To: Alexandre Petrescu
Cc: [email-masked]; [email-masked]
Subject: Re: [ipwave] PC5 and 5.9GHz?

yes, a big one...and a tive research in fibding a solution..but it is slso
political. Btw, in the US, you also have OCB 10Mhz headers coexisting with
20MHz Rlan wifi headers..also problematic..

> It is sufficient to drive a little bit around to listen to 5.9GHz and see
there is already a lot of 802.11-OCB traffic.  Not sure how can that coexist
with PC5 because this latter does not have 802.11 headers.

maybe in a few months I will be able to tell you how...earliest ETSI vote in
this, March 2020...
> 
>> But: it cannot use these frequencies now (well it got some test freq. in
the US) (ITU in charge for spectrum allocation in EU) as the coexistence
(PHY/MAC) with ITS-G5 needs to be solved first..

yet, in EU, PC5 requires the ETSI geonet stack to operate on 5.9GHz, so no
(or through geonet)
As it needs the ETSI security framework (even refered in 3GPP LTE sidelink
standard) and use per packet wireless congestion control ..so, good old
story..

btw, not clear yet that 5G-V2X will use IP on PC5..too early to tell..unless
you have news about it (or you meant LTE Uu, which uses IP)

BR,

Jérôme

>>>>> the EU is quite clear: there should not be technology ban on the
ITS-G5 SPECTRUM
>>>>> 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)
>>>>>> Le 18 avr. 2019 à 15:17, Alexandre Petrescu
<[email-masked] <mailto:[email-masked]>> a écrit
>>>>>>> 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
>>>>>> 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.
>>>>>> - 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.
>>>>>>> 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
>>>>>>> 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]
>>>>>>> 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 '-').