Subject: Re: [ipwave] [lisp] I-D Action: draft-barkai-lisp-nexagon-10.txt

From: "Ratliff, Stanley" <[email-masked]>
Date: Thu, 19 Sep 2019 14:50:24 +0000

This looks like interesting work. But, don't we already have a WG addressing vehicular networks? Has there been any collaboration with the ipwave WG? Just curious.

Regards,
Stan

From: lisp <[email-masked]> On Behalf Of Sharon Barkai
Sent: Thursday, September 19, 2019 1:30 AM
To: Victor Moreno (vimoreno) <[email-masked]>
Cc: [email-masked]
Subject: Re: [lisp] I-D Action: draft-barkai-lisp-nexagon-10.txt

***WARNING! THIS EMAIL ORIGINATES FROM OUTSIDE ST ENGINEERING IDIRECT.***

Thank you Victor.

Quick recap of mobility networks evolution:

1. Couple of decades ago a peer to peer layer2 protocol called DSRC was specified over WiFi spectrum with basic safety messages (BSM) in which cars conveyed their GPS and kinematics sensor events like hard-brake, sharp-turn.
Additional payment and information messages were specified as well.

2. For privacy considerations road-side-units (RSU) were specified as well to hand MAC keys to be used so cars will not be tracked. This double infrastructure presented a barrier so DSRC over cellular was specified CV2X.
The 5G evolution is supposed to match the latency of peer to peer WiFi.

3. The peer to peer challenges however remained, the need to test every product with every other product is a barrier for extending the protocol to support on vehicle vision and sensory annotations which evolved since - such as machine vision and liadr. Also timing sequence for relaying annotations between vehicles remains a problem since both DSRC and CV2X have no memory and cars drive away.

Addressable geo-states brokering solves timing, interoperability, and extendability limitations, and, edge-processing address latency needs => demonstrated in single-digit latencies in production environments, sub 5msecs in labs.

>From here selecting LISP as the layer3 protocol of choice the road is short and explained in the draft:

o The support for logical EIDs for states based on (de-facto) geo-spatial standard grids

o controlling latency and high availability by routing to states at the edge

o supporting ephemeral EIDs for vehicles

o signal-free-multicast for limited cast of many geo-spatial channels

o the distributed connectionless scale

o the multi-vendor interoperability that allows for "bring your own XTR" to protect geo-privacy

o the ability to overlay multiple cellular network providers and multiple cloud-edge providers

.. are some of the features which make LISP a good choice for mobility VPNs. Hope this helps.

--szb
Cell: +972.53.2470068
WhatsApp: +1.650.492.0794

> On Sep 19, 2019, at 7:01 AM, Victor Moreno (vimoreno) <[email-masked]<mailto:[email-masked]>> wrote:
>
> I think a thorough understanding of mobility requirements and dependencies and how LISP may or may not accommodate these scenarios is key. I would like to see us work on this and other mobility related drafts (e.g. Ground based LISP).
>
> Victor
>
>> On Sep 18, 2019, at 11:18 AM, Dino Farinacci <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> I'm a side author on this document and more of a reviewer. But I'll answer your questions on behalf of a WG member.
>>
>>> Before I get more privacy feedback (if I do) I want to know
>>> 1) does the WG actually care about this?
>>
>> I do. Because understanding in deep detail the use-cases, allows us to understand if LISP has the necessary protocol features.
>>
>>> 2) Is it ready for more extensive review?
>>
>> Yes.
>>
>>> I realize we have not adopted this document. Some of this feedback is to help the chairs judge what to do when the authors do ask for adoption.
>>
>> We are at a point of the protocol's life where working on use-cases allows more adoption. I am for making this a working group document (even though the authors have not formally requested).
>>
>> Dino
>>
>> _______________________________________________
>> lisp mailing list
>> [email-masked]<mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/lisp<https://www.ietf.org/mailman/listinfo/lisp>
> _______________________________________________
> lisp mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/lisp<https://www.ietf.org/mailman/listinfo/lisp>

_______________________________________________
lisp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lisp<https://www.ietf.org/mailman/listinfo/lisp>

This electronic message and any files transmitted with it contains information from iDirect, which may be privileged, proprietary and/or confidential. It is intended solely for the use of the individual or entity to whom they are addressed. 
If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of 
this email is strictly prohibited. If you received this email in error, please delete it and immediately notify the sender.

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 19 Sep 2019 09:21:59 -0700

> This looks like interesting work. But, don’t we already have a WG addressing vehicular networks? Has there been any collaboration with the ipwave WG? Just curious.

I had presented draft-ietf-lisp-predictive-rlocs to IPWAVE a couple of years ago.

Dino

---

From: Sharon Barkai <[email-masked]>
Date: Thu, 19 Sep 2019 20:16:42 +0300

Thanks Stan, there is but its focused on establishing IP connectivity to vehicles.

We assume IP connectivity is there cellular or other, and focus on geo-state routing as a LISP use-case and as means of avoiding direct vehicle to vehicle / vehicle to infrastructure communications (safety, privacy, interoperability etc.).

Should defiantly make ipwave wg aware of LISP in-general, and addressable geo-state using LISP in particular. Different problem space networking wise, but, with intersection at high-level eg safer-roads, maintenance, alerts, traffic flow.

Thats a very good point.
Thanks!

--szb
Cell: +972.53.2470068

> On Sep 19, 2019, at 5:50 PM, Ratliff, Stanley <[email-masked]> wrote:
> 
> o the multi-vendor interoperability that allows for “bring your own XTR” to protect geo-privacy
> 
> > On Sep 19, 2019, at 7:01 AM, Victor Moreno (vimoreno) <[email-masked]> wrote:
> > 
> >> On Sep 18, 2019, at 11:18 AM, Dino Farinacci <[email-masked]> wrote:
> >> 
> >> I’m a side author on this document and more of a reviewer. But I’ll answer your questions on behalf of a WG member.
> >> 
> >> We are at a point of the protocol’s life where working on use-cases allows more adoption. I am for making this a working group document (even though the authors have not formally requested).
> >> 
> >> Dino
> >> 
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/lisp
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/lisp
> 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
> 
> 
> 
> This electronic message and any files transmitted with it contains information from iDirect, which may be privileged, proprietary and/or confidential. It is intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please delete it and immediately notify the sender.

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 19 Sep 2019 10:25:46 -0700

By the way, here is the presentation I gave to IPWAVE. For those interested.

Dino

> On Sep 19, 2019, at 10:16 AM, Sharon Barkai <[email-masked]> wrote:
> 
>> ... are some of the features which make LISP a good choice for mobility VPNs. Hope this helps.
>> 
>> --szb
>> Cell: +972.53.2470068

---

From: William Whyte <[email-masked]>
Date: Thu, 19 Sep 2019 18:19:32 +0000

Hi all,

Some of the history below is wrong, so I’d like to correct it (with no comment on LISP itself):

>> 1. Couple of decades ago a peer to peer layer2 protocol called DSRC was specified over WiFi spectrum with basic safety messages (BSM) in which cars conveyed their GPS and kinematics sensor events like hard-brake, sharp-turn. Additional payment and information messages were specified as well.

The V2X system specified by the DSRC/WAVE standards in IEEE and SAE covers the whole stack (not just layer 2) and supports both broadcast and unicast operations (it’s not inherently peer-to-peer, though some of the defined applications are peer-to-peer).

For example, in the US:
* Layers 1 and 2 are defined in 802.11p, now incorporated into the main 802.11 standard as 802.11 *O*utside the *C*ontext of a *B*asic Service Set (OCB)
* Supported transport and network layer protocols include WSMP, a single-hop protocol best suited to broadcast, TCP over IPv6 and IDP over IPv6. These are specified in IEEE 1609.3 and other IEEE 1609 standards
* Applications that use the system and messages that the applications use are defined in IEEE 1609.11 and (mainly) in SAE J2735 and the SAE J2945/x series of standards. The process of specifying applications is ongoing – the para above makes it seem like a set of applications was defined and then the specification process stopped.

(The situation in Europe is similar except that the lower layers above layer 2 are specified in ETSI and the higher layers are specified in CEN, with some overlap; there is also a series of standards from ISO TC 204 which address the same area).

>>2. For privacy considerations road-side-units (RSU) were specified as well to hand MAC keys to be used so cars will not be tracked. This double infrastructure presented a barrier so DSRC over cellular was specified CV2X. The 5G evolution is supposed to match the latency of peer to peer WiFi.

RSUs are not required to be actively involved in V2V safety.

Vehicles use certificates to sign messages, not MAC keys.

Anti-tracking is important, agreed! This is achieved by giving vehicles a large number of simultaneously valid certificates and allowing them to switch between them periodically.

There is no “double infrastructure”.

C-V2X uses the same security system as DSRC and was proposed not so much because of technical shortcomings with DSRC as because of a business model failure – DSRC hasn’t been deployed because of concerns that it wouldn’t be widespread enough to be effective and the hope is that C-V2X will have synergies with other communications hardware on the car that will lower the total cost of ownership (as well as providing a migration path to higher-capacity channels)

>> 3. The peer to peer challenges however remained, the need to test every product with every other product is a barrier for extending the protocol to support on vehicle vision and sensory annotations which evolved since - such as machine vision and liadr.

There is no need to test every product with every other product. OmniAir and ETSI run conformance test services that test conformance to the standards, and products that implement the standards in general interoperate. This is similar to how not every WiFi chip needs to be tested against every other WiFi chip; instead, each chip can be individually certified and give a high confidence of interoperability.

>> Also timing sequence for relaying annotations between vehicles remains a problem since both DSRC and CV2X have no memory and cars drive away.

Memory of “annotations” would be implemented higher up the stack – whether or not the layer 2 protocol maintains the information is immaterial. Some architectures (like the ETSI and ISO ITS Station) identify functional components within the devices that would maintain that state; some (like the IEEE WAVE device architecture) leave it as an implementation choice. I agree that the existing standards don’t fully address this issue, though.

Hope this corrects some misunderstandings.

Cheers,

William

From: its <[email-masked]> On Behalf Of Ratliff, Stanley
Sent: Thursday, September 19, 2019 10:50 AM
To: Sharon Barkai <[email-masked]>; Victor Moreno (vimoreno) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: [EXT] Re: [ipwave] [lisp] I-D Action: draft-barkai-lisp-nexagon-10.txt

Regards,
Stan

From: lisp <[email-masked]<mailto:[email-masked]>> On Behalf Of Sharon Barkai
Sent: Thursday, September 19, 2019 1:30 AM
To: Victor Moreno (vimoreno) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [lisp] I-D Action: draft-barkai-lisp-nexagon-10.txt

Thank you Victor.

... are some of the features which make LISP a good choice for mobility VPNs.. Hope this helps.

--szb
Cell: +972.53.2470068

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 19 Sep 2019 11:48:20 -0700

William, one question, when movement is occurring across the various L2 technologies, does the IPv6 address of the vehicle change?

Dino

> On Sep 19, 2019, at 11:19 AM, William Whyte <[email-masked]> wrote:
> 
> Hi all,
>  
> (The situation in Europe is similar except that the lower layers above layer 2 aore specified in ETSI and the higher layers are specified in CEN, with some overlap; there is also a series of standards from ISO TC 204 which address the same area).
>

---

From: Sharon Barkai <[email-masked]>
Date: Thu, 19 Sep 2019 22:05:49 +0300

Thank you William.

Sorry if my summary did some injustice to the DSRC spec trying to account for the adaptation challenges and the budgets considered necessary by gov-muni.  

But I think you would agree that specifying only the virtual ip geo-state grid-brokering is a different approach. 

It may or may result in different adoption pattern, it may be limited in the end to be a kind of an in-network live-map of furniture, signs, defects etc, or, it may cover the whole spectrum of hazards, alerts, breaches in the end. Testing level at this point is limited to a few thousands of cars in the major US cites.

v2i testing has also been limited to junction traffic light cameras, so overall v2v v2i has been focused mainly on creating an H3 machine vision puzzle using LISP.  

Regardless hope you feel this H3-LISP direction is worth a shot.  

--szb
Cell: +972.53.2470068

> On Sep 19, 2019, at 9:19 PM, William Whyte <[email-masked]> wrote:
> 
> Hi all,
>

---

From: William Whyte <[email-masked]>
Date: Thu, 19 Sep 2019 19:22:55 +0000

No worries, thanks for taking it in good grace. I haven’t looked closely at LISP but I appreciate that it’s a real problem you’re trying to solve and one you’ve thought about hard. I may (*may*) be able to make time to look at it properly over the next while.

Cheers,

William

From: Sharon Barkai <[email-masked]>
Sent: Thursday, September 19, 2019 3:06 PM
To: William Whyte <[email-masked]>
Cc: Ratliff, Stanley <[email-masked]>; Victor Moreno (vimoreno) <[email-masked]>; [email-masked]; [email-masked]
Subject: [EXT] Re: [ipwave] [lisp] I-D Action: draft-barkai-lisp-nexagon-10.txt

Thank you William.

--szb
Cell: +972.53.2470068

On Sep 19, 2019, at 9:19 PM, William Whyte <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

For example, in the US:

Cheers,

William

From: its <[email-masked]<mailto:[email-masked]>> On Behalf Of Ratliff, Stanley
Sent: Thursday, September 19, 2019 10:50 AM
To: Sharon Barkai <[email-masked]<mailto:[email-masked]>>; Victor Moreno (vimoreno) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [EXT] Re: [ipwave] [lisp] I-D Action: draft-barkai-lisp-nexagon-10.txt

Regards,
Stan

Thank you Victor.

--szb
Cell: +972.53.2470068

---

From: Sharon Barkai <[email-masked]>
Date: Thu, 19 Sep 2019 22:33:10 +0300

Sorry, but left out an important point -

A couple carriers suggested to provide CV2X gateway that would turn BSMs to tile geo-state enumerations such as hard-brake.

This will allow car OEMs that walked away from DSRC and those who didn't to interoperate at some level. Stressing the point that the h3-lisp spec is at another layer.

Once again the current network testing is still limited to a few K drivers in each of the US major cities, most are uber/lyft drivers and use smartphones as the cpe, dash-cams with kinematics as the sensors. 

--szb
Cell: +972.53.2470068

> On Sep 19, 2019, at 10:05 PM, Sharon Barkai <[email-masked]> wrote:
> 
> Thank you William.
>

---

From: Sharon Barkai <[email-masked]>
Date: Thu, 19 Sep 2019 22:37:03 +0300

Cheers! and please do.
Will all share these roads:)

--szb
Cell: +972.53.2470068

> On Sep 19, 2019, at 10:22 PM, William Whyte <[email-masked]> wrote:
>

---

From: Sharon Barkai <[email-masked]>
Date: Fri, 20 Sep 2019 05:23:25 +0300

Thank you RR for further clarifying the details behind the effort to date in providing mobility networking that meets latency needs on roads.

I think that all on both lists believe that networking can and should be used to extend on-vehicle sensors beyond their line-of-site to prevent accidents by sharing sensor data between vehicles, and, between vehicles and infrastructure.

The technical interoperability and business challenges should be clearer also to the lispers reviewing the domain from your and William comments. Theres actually no clear market entity measured on maximizing throughput, minimizing accidents of any specific street or road on a moment-by-moment basis. This is unlike airport concourses / taxi lanes for example. Not car companies, insurance, gov-muni, or networkers, though all mean well!

Hoping to attract review and contribution from interested parties to the H3-LISP addressable geo-state  draft attempting to focus solely on the virtual IP or EID layer:

- for leveraging multi-application investment in low-latency cellular IP/edge

Eg single digit msec cellular/edge field test beds in Detroit, Atlanta, Plano, EU, Seoul ..

- for allowing features that enable mobility networks to pay for themselves    

Eg saving dedicated maintenance survey costs or non safety related free-parking  detection 

Thanks again!

--szb
Cell: +972.53.2470068

> On Sep 20, 2019, at 1:40 AM, Dick Roy <[email-masked]> wrote:
> 
> Some additions and possible clarifications to William’s comments (with which I generally agree) …
>  
> RR
>  
> From: its [mailto:[email-masked]] On Behalf Of William Whyte
> Sent: Thursday, September 19, 2019 11:20 AM
> To: Ratliff, Stanley; Sharon Barkai; Victor Moreno (vimoreno)
> Subject: Re: [ipwave] [lisp] I-D Action: draft-barkai-lisp-nexagon-10.txt
>  
> Hi all,
>  
> [RR] The spectrum was and still is dedicated DSRC spectrum (5.850-5.925GHz) which is above the 5GHz ISM band (5GHz Wi-Fi), one channel of which (ch172) was set asidec for safety of life and property applications such as the BSM sending application.  There are other applications that use ch172 as well.
>  
> * Supported transport and network layer protocols include WSMP, a single-hop protocol best suited to broadcast,
> [RR] FYI, WSMP has NO layer 3 addresses, so you could call it (and some do) a null-networking protocol:^))) As such, its an extremely efficient broadcast protocol for RF neighborhoods, while also suitable for unicast or groupcast on LANs (and vLANs).
> TCP over IPv6 and IDP over IPv6. These are specified in IEEE 1609.3 and other IEEE 1609 standards
> [RR] I think he meant UDP, not IDP.  Furthermore, there were no restrictions on the transport layer protocol so others such as SCP could be used.  TCP and UDP were mandated as a minimum set.  Similarly, while IPv6 was mandated, IPv4 can and is implemented in some OBUs and RSUs.
> * Applications that use the system and messages that the applications use are defined in IEEE 1609.11 
> [RR] To clarify, 1609.11 is a standard specifying how the European toll system as specified in ISO14906 and ISO 15628 (called European DSRC to make matters confusing) could be implemented on a WAVE device using WSMP.
> and (mainly) in SAE J2735 and the SAE J2945/x series of standards. The process of specifying applications is ongoing – the para above makes it seem like a set of applications was defined and then the specification process stopped.
>  
> [RR] ETSI also specifies the access layer called G5, and while it is virtually identical to US DSRC, there is currently one major difference that makes the two systems (technically) non-interoperable. For those in the know, US uses EPD and the ETSI still insists on LPD.
> 
> [RR] This is a really long story, however, C-V2X is being specified as an alternative to US DSRC, not as a cellular access technology since that’s already available and deployed.  The reason LTE Release 14 and successors is being specified has nothing to do with its lineage as a child of cellular; in fact, it is provably a square peg being forced into a round hole and we all know how that generally ends up, and that’s a story for another day
> [RR] 5G is nothing but hype at the moment and simply matching the latency would be no reason to switch from DSRC to another access technology for V2V safety, though nothing prevents the addition of 5G NR access technologies in ITS stations (aka OBUs) for other uses.
>  
> [RR] Though nothing prevents them from being involved for example sending red-light warning messages etc.. It’s a bit complicated.
>  
> [RR] and for it to be of any use, ALL immutable identifiers on all active media should change at the same time, and this is not a trivial task generally.
>  
> [RR] While this may seem logical, there are other opinions on the subject.
> 
> [RR] Machine vision is an application that uses sensor inputs including LIDAR and there is nothing in the communication protocols that prevents their implementation, nor sharing of the information they generate  
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 25 Sep 2019 13:28:53 +0200

I wonder why is the draft using 64bit id's and not variable length id's.

I wonder whether the hexagon style can be applied in 3D where drone 
taxis need to follow a certain traffic regulation, potentially a 3D 
extension of regular (2D) traffic lights.

I wonder whether the H3 geospatial indexing is the same as 
what3words.com.  Because the what3words recent presentation I have seen 
did not mention anything similar, neither does H3.  Yet they seem so 
similar to me.

Alex

Le 19/09/2019 à 16:50, Ratliff, Stanley a écrit :
> This looks like interesting work. But, don’t we already have a WG 
> addressing vehicular networks? Has there been any collaboration with the 
> ipwave WG? Just curious.
> 
> Regards,
> 
> Stan
> 
> *From:*lisp <[email-masked]> *On Behalf Of *Sharon Barkai
> *Sent:* Thursday, September 19, 2019 1:30 AM
> *To:* Victor Moreno (vimoreno) <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [lisp] I-D Action: draft-barkai-lisp-nexagon-10.txt
> 
> 1. Couple of decades ago a peer to peer layer2 protocol called DSRC was 
> specified over WiFi spectrum with basic safety messages (BSM) in which 
> cars conveyed their GPS and kinematics sensor events like hard-brake, 
> sharp-turn.
> 2. For privacy considerations road-side-units (RSU) were specified as 
> well to hand MAC keys to be used so cars will not be tracked. This 
> double infrastructure presented a barrier so DSRC over cellular was 
> specified CV2X.
> 3. The peer to peer challenges however remained, the need to test every 
> product with every other product is a barrier for extending the protocol 
> to support on vehicle vision and sensory annotations which evolved since 
> - such as machine vision and liadr. Also timing sequence for relaying 
> annotations between vehicles remains a problem since both DSRC and CV2X 
> have no memory and cars drive away.
> 
> Addressable geo-states brokering solves timing, interoperability, and 
> extendability limitations, and, edge-processing address latency needs => 
> demonstrated in single-digit latencies in production environments, sub 
> 5msecs in labs.
> 
>  > On Sep 19, 2019, at 7:01 AM, Victor Moreno (vimoreno) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>  >
>  > I think a thorough understanding of mobility requirements and 
> dependencies and how LISP may or may not accommodate these scenarios is 
> key. I would like to see us work on this and other mobility related 
> drafts (e.g. Ground based LISP).
>  >
>  > Victor
>  >
>  >> I’m a side author on this document and more of a reviewer. But I’ll 
> answer your questions on behalf of a WG member.
>  >>
>  >> I do. Because understanding in deep detail the use-cases, allows us 
> to understand if LISP has the necessary protocol features.
>  >>
>  >>> I realize we have not adopted this document. Some of this feedback 
> is to help the chairs judge what to do when the authors do ask for adoption.
>  >>
>  >> We are at a point of the protocol’s life where working on use-cases 
> allows more adoption. I am for making this a working group document 
> (even though the authors have not formally requested).
>  >>
>  >> Dino
>  >>
>  >> [email-masked] <mailto:[email-masked]>
>  > [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> This electronic message and any files transmitted with it contains 
> information from iDirect, which may be privileged, proprietary and/or 
> confidential. It is intended solely for the use of the individual or 
> entity to whom they are addressed. If you are not the original recipient 
> or the person responsible for delivering the email to the intended 
> recipient, be advised that you have received this email in error, and 
> that any use, dissemination, forwarding, printing, or copying of this 
> email is strictly prohibited. If you received this email in error, 
> please delete it and immediately notify the sender.
> 
> 
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 25 Sep 2019 16:13:48 +0200

Hi

Le 20/09/2019 à 04:23, Sharon Barkai and Dick Roy ([RR]) wrote:
[...]
>> */[RR] This is a really long story, however, C-V2X is being specified 
>> as an alternative to US DSRC, not as a cellular access technology 
>> since that’s already available and deployed.  The reason LTE Release 
>> 14 and successors is being specified has nothing to do with its 
>> lineage as a child of cellular; in fact, it is provably a square peg 
>> being forced into a round hole and we all know how that generally ends 
>> up, and that’s a story for another day/*
>>

When that matches, WiFi will have leaped forward to below 
100micro-second latency.  This was so (cellular catching up with a 
leaping forward WiFi latency) since the invention of WiFi 20 years ago, 
and it wont change.  It's a constant of evolution.

>> */[RR] 5G is nothing but hype at the moment 

Here is a more precise status, according to my personal understanding. 
This obviously differs from many people's understandings, who may be 
more knowledgeable.

In France, frequencies for use in 5G radio would start to be discussed 
now in September, with allocation towards December.  The allocation is 
similar, but not quite like, the process that was used for 3G: auction 
sales.  The differences from 3G are: (1) it is not expected to generate 
huge revenues for gov't and (2) some sales, like of the 3.5GHz band, 
would actually be a re-allocation from what was previously allocated to 
wimax operators  (e.g. SDH in France) and to City Authority (like Mayor) 
in places where there was no operator).

Obviously, until these frequencies are allocated one cant really talk 
about 5G deployment on public roads, even if...

If one wants to talk about 5G like when talking a higher bandwidth and 
lower latency than 4G, then one assumes 4G to be 50ms latency and 
2Mbit/s bandwidth.  One can talk then about 25ms latency and 10Mbit/s, 
and claim that to be 5G.  But it is not 5G.  It is just another Class or 
Category of 4G.  In theory, one can still be 4G and run at 1Gbps (e.g. 
Category 16).

Also, one can talk about a higher bandwidth outdoors network by running 
802.11 WiFi on 5.4 GHz and, why not, at 5.9GHz.

Colleagues call these 'acrobatics 5G'.

This is when one wonders: what is 5G anyways? with its associated 
question: why was the predecessor of 5G called 'LTE' (Long Term 
Evolution), or where is the long term?  Is 5G LTE?

With respect to other countries, I heard two recent announcements, about 
Spain and Germany.

They both claim 5G is deployed in the respective areas.

This claims 15 cities in Spain on June 15th, by Vodafone:
https://www.xataka.com/empresas-y-economia/red-5g-comercial-vodafone-espana-tiene-fecha-lanzamiento-15-ciudades-15-junio

This claims 5 cities in Germany, but it does not say when, by Deutsche 
Telekom:
https://www.telekom.de/start/netzausbau?wt_mc=alias_1070_netzausbau

As hardware for end users, this is the situation now:
- there is no 5G smartphone for sale in France.  I guess it is the same
   in more countries.  If it were different, it would be an isolation
   easily spot by many.
- iphone 11 just launched features 'Gigabit-class LTE' and 'LTE
   Advanced' but no '5G'.  They run on 'LTE Bands' which are your typical
   frequencies below 5GHz for cellular communications, but nowhere like a
   26GHz of 5G.  No such band is called a '5G band'.
- one can buy off the shelf modules, like miniPCIe (I have a list) that
   go very high in terms of bandwidth, well beyond what normal 4G would
   do, but couldnt really use them at that high parameters.

Alex

>> and simply matching the 
>> latency would be no reason to switch from DSRC to another access 
>> technology for V2V safety, though nothing prevents the addition of 5G 
>> NR access technologies in ITS stations (aka OBUs) for other uses. /*

I agree.

[...]

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 26 Sep 2019 14:49:57 +0200

Le 25/09/2019 à 16:13, Alexandre Petrescu a écrit :
>>> being forced into a round hole and we all know how that generally 
>>> ends up, and that’s a story for another day/*
>>>

Further details after searches of public documents:

iphone 11 pro understands a 5G frequency band:

it is specified to understand several frequency bands, among which also 
TD-LTE Band number 42, which is 3400MHz - 3600MHz.  This band is a 5G 
band.  Part of this band (3490MHz - 3600MHz) is being considered for 
allocation by regulator ARCEP.  It has not yet been allocated, but under 
discussion.

ARCEP considers to also allocate Band 43 at 3600MHz - 3800MHz, for 5G. 
But this band is not covered by iphone 11 specs.

ARCEP is silent about the range 3400MHz-3490MHz.  I suspect there might 
be some errors here.

iphone 11 pro also understands TD-LTE Band 46 at 5150 MHz - 5925 MHz, 
which covers WiFi 5.4GHz and 802.11-OCB at 5.9GHz.  I suspect there 
would be some clashes here between deployed Road-Side Units and iphones.

For highways and roads requirements, ARCEP seems to plan to require the 
licensee to cover them by December 2025.  And the required bandwidth is 
between 50mbit/s to 100Mbit/s and 10ms latency.  These figures are 
obviously little incitative, because 2025 is very late, 50mbit/s is what 
4G already does and 10ms is much higher than 1ms 802.11-OCB today.

On another hand, ARCEP requires the 5G licensee to support IPv6, 
starting end of 2020. (in French: "Le  titulaire  est  tenu  de  rendre 
son  réseau  mobile  compatible  avec  le  protocole  de  routage  IPv6 
à compter du 31décembre2020.").  This means that by that time, if IPv6 
under its form IPv6-over-OCB does not see a huge deployment compared to 
just 802.11-OCB WSMP, it might be that IPv6-over-5G on routes would be 
more likely.  Which may raise a question of the potential usefulness of 
a spec IPv6-over-5G.

So, this is to say that where I live it is not very clear how these 
things will unfold.

Alex

>>> and simply matching the latency would be no reason to switch from 
>>> DSRC to another access technology for V2V safety, though nothing 
>>> prevents the addition of 5G NR access technologies in ITS stations 
>>> (aka OBUs) for other uses. /*
> 
> I agree.
> 
> [...]
> 
> Alex
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 26 Sep 2019 15:58:31 +0200

> https://www.telekom.de/start/netzausbau?wt_mc=alias_1070_netzausbau

The claims of 5G Experimentations in France are there:
https://www.arcep.fr/cartes-et-donnees/nos-publications-chiffrees/experimentations-5g-en-france/tableau-deploiements-5g.html

Alex

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 26 Sep 2019 23:46:46 +0900

Hi Alex,
Thanks for your opinion and status of 5G.

I think IPWAVE needs to consider IPv6 over C-V2X based on 5G because
C-V2X has higher bandwidth than 802.11-OCB based on WAVE.

My SKKU group is studying how to efficiently support IPv6 over C-V2X in
vehicular networks.
This will be a possible WG item for IPWAVE WG.

Thanks.

Paul

-- 
===========================
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: Thu, 26 Sep 2019 15:19:07 +0000

Hi Paul and Alex,
I can only agree that C-V2X or PC5 (as 3GPPs V2V link is called) is very important here.
Implementations also support IPv6 (see e.g. https://site.eettaiwan.com/events/iovev2019/dl/03_Keysight.pdf) and a planned SDR implementation based on Open source SDR LTE software suite from Software Radio Systems (SRS) also allow for IPv6 communication since some time (https://github.com/srsLTE/srsLTE/blob/master/CHANGELOG).
We hopefully will be able until end of this year to report some measurements …
Best regards
Dirk

From: its <[email-masked]> On Behalf Of Mr. Jaehoon Paul Jeong
Sent: Donnerstag, 26. September 2019 16:47
To: Alexandre Petrescu <[email-masked]>
Cc: [email-masked]; Mr. Jaehoon Paul Jeong <[email-masked]>; [email-masked]
Subject: Re: [ipwave] 5G deployment status

Hi Alex,

My SKKU group is studying how to efficiently support IPv6 over C-V2X in vehicular networks.
This will be a possible WG item for IPWAVE WG.

Thanks.

Paul

On Thu, Sep 26, 2019 at 9:50 PM Alexandre Petrescu <[email-masked]<mailto:[email-masked]>> wrote:

Alex

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

---

From: Sharon Barkai <[email-masked]>
Date: Thu, 26 Sep 2019 20:41:56 +0300

Thank you Alex for this clarification.
Just to further clarify the proposal at hand:

1. There are significant challenges in having sensors information producers communicating directly with consumer driving applications.

- sensors may be periodically wrong or otherwise misleading, PKIs try to protect from some of that as well as protect privacy, but direct is typically more exposed. 

- its very hard to evolve the content of the information because of the intrtop matrix
its unlikely that any vendor will trust a single vendor to set the bar on all  interoperable functionality  

- its hard to navigate consumption through a flood of information from all sensors around, and, without aggregation timing gaps may preclude critical information and result in pile-ups

For these reasons among others it was suggested to use the EID layer of LISP virtual IP as a standard in-network service for aggregating and brokering information - rather then using proprietary servers.

Among the “other reasons” is one that was cited by people on the thread which is - allowing for immediate business success of mobility networks.

Until which time where each road is measured on throughout and safety on a moment by moment basis by any of the market player - gov-muni, car OEM, insurance .. we need to keep extending mobility network functionality with economical features quickly. This is hard to do without EID indirection.

2. A LISP EID based mobility brokering does not specify in any way the layer2 or RAN used for mobile IP. If there is a pervasive economical low-latency mobile IP network based on WiFi then it should be used. Cellular mobile IP is currently more pervasive and economical because it is multi-application. However its latency limits some of the heads up alert specified in the EID layer. Limits lifted gradually by real (and theres a lot of fake) 5G and MobileEdge deployments.

In any case network based alerts are there to extend the reach of the on-car sensors. For example, a heads up alert on a baby-stroller beyond the corner spotted by cross traffic immediate no-network sensors will actually meet the timeline required for vehicles making the turn when brokered over regular LTE . The point is that a lot of progress can be made using cellular mobile IP available right now.

So hopefully there is no contention between the EID based efforts using H3 virtual terrestrial state “tiles” vs other direct terrestrial communications efforts. 
Hopefully these different approaches are complementary.

--szb
Cell: +972.53.2470068

> On Sep 25, 2019, at 5:13 PM, Alexandre Petrescu <[email-masked]> wrote:
> 
> Hi
> 
>>> */[RR] This is a really long story, however, C-V2X is being specified as an alternative to US DSRC, not as a cellular access technology since that’s already available and deployed.  The reason LTE Release 14 and successors is being specified has nothing to do with its lineage as a child of cellular; in fact, it is provably a square peg being forced into a round hole and we all know how that generally ends up, and that’s a story for another day/*
>>> 
> When that matches, WiFi will have leaped forward to below 100micro-second latency.  This was so (cellular catching up with a leaping forward WiFi latency) since the invention of WiFi 20 years ago, and it wont change.  It's a constant of evolution.
> 
> Here is a more precise status, according to my personal understanding. This obviously differs from many people's understandings, who may be more knowledgeable.
> 
> In France, frequencies for use in 5G radio would start to be discussed now in September, with allocation towards December.  The allocation is similar, but not quite like, the process that was used for 3G: auction sales.  The differences from 3G are: (1) it is not expected to generate huge revenues for gov't and (2) some sales, like of the 3.5GHz band, would actually be a re-allocation from what was previously allocated to wimax operators  (e.g. SDH in France) and to City Authority (like Mayor) in places where there was no operator).
> 
> Obviously, until these frequencies are allocated one cant really talk about 5G deployment on public roads, even if...
> 
> If one wants to talk about 5G like when talking a higher bandwidth and lower latency than 4G, then one assumes 4G to be 50ms latency and 2Mbit/s bandwidth.  One can talk then about 25ms latency and 10Mbit/s, and claim that to be 5G.  But it is not 5G.  It is just another Class or Category of 4G.  In theory, one can still be 4G and run at 1Gbps (e.g. Category 16).
> 
> Also, one can talk about a higher bandwidth outdoors network by running 802.11 WiFi on 5.4 GHz and, why not, at 5.9GHz.
> 
> This is when one wonders: what is 5G anyways? with its associated question: why was the predecessor of 5G called 'LTE' (Long Term Evolution), or where is the long term?  Is 5G LTE?
> 
> With respect to other countries, I heard two recent announcements, about Spain and Germany.
> 
> This claims 5 cities in Germany, but it does not say when, by Deutsche Telekom:
>>> and simply matching the latency would be no reason to switch from DSRC to another access technology for V2V safety, though nothing prevents the addition of 5G NR access technologies in ITS stations (aka OBUs) for other uses. /*
> 
> I agree.
> 
> [...]
> 
> Alex