Re: [gaia] Fwd- Colorado Will Develop a Digital Highway Using Connected-Vehicle Technology

[Rex Buddenberg <[e-mail]>]

Will,

There's a lot the article didn't cover.  Including any of the technical
that ought to be of interest to this group.

Geography.  Descant got what he said right -- mountainous area with
real winter.  By contrast, I-70 east of Denver is flat all the way to
and through Kansas.  But there's a lot that he didn't include. I-70 is
paralleled by a railway; Amtrak's California Zephyr passes through
daily, along with freight (the heavy freight route is next route north
in Wyoming, parallel to I-80).
     What this means is that there is a pre-existing richness of
connectivity here: cellphone and WiFi are already quite common -- much
more so than typical rural.  The area is basically rural, so you won't
get the automobile density that you'd find in, say, Denver.  All of
this will tend to skew the test results in some ways that need to be
understood before scaleup.

Requirements.  I've been through requirements exercises in information
systems enough times to be wary: nobody gets it right.  Consequently
I'm an apostle of open architecture (warning: loose definition) where
we can afford to be wrong and easily correct/ salvage/ scale/ extend.  

Government.  Before 9/11, there was one US federal government agency
dealing with emergency services communications: FCC.  And it never said
anything about protocols, only spectrum management.  Today there are
around a dozen agencies in federal government and some are working at
cross-purposes.  Read stuff like this with a wary eye out.
     Both this build-out and that in Columbus, Oh, are sponsored by
National Highway Traffic Safety Agency, a grant-sponsoring office
within US Dept of Transportation.  

Standards and standards bodies.  The premier body involved here is IEEE
1609 (the IPWAV WG in IETF is a come-lately and, IMHO, hasn't gotten
traction yet).  IEEE 1609 defines two profiles that cover all 7 layers
of the ISO model .... sorta.  To decode this, you need your magic
acronym decoder ring: 
  V2V stands for vehicle-to-vehicle.
  V2I means vehicle to infrastructure, and
  V2X means all of the above.
V2V and V2I each got a standards profile (If you're been through GOSIP
and IPng like I have, this should immediately set off some suspicion
alarms)

The V2V profile voids layers 3,4,5 of the ISO stack -- no IP, no
reliable connection, in fact no connection at all, only the equivalent
of UDP -- spray and pray.  Further, there is a tacit assumption that
each automobile is an end system, not a LAN.  When I ask about relaying
and >1 hop, I get layer 2 bridging answers.
     Layers 1/2.  The protocol specified is a variant of IEEE 802.11
(ocd).  (We need a stress test here, and mountains of Colorado won't
provide it.  Too many nodes sending too much traffic -- remember your
ethernet CSMA lessons).
     Layers 6/7.  1609 essentially specifies an application with a
bunch of data definitions (has parallels to MIME definitions of e-
mail).  I think this area is probably good and I especially like where
the committee has gone in terms of security -- by signing the messages
themselves they protect the data, independent of the plumbing (this
also needs a stress test -- potentially bigger PKI than anything I've
ever seen).  
     Reciting this is useful because the V2V work has gotten most of
the committee's attention.  
     Yet another instance of router-phobia, IMHO. ... how many of us
remember AppleTalk?

The protocol stack for the V2I (and hence the V2X) has gotten less
attention.  It looks a lot more like familiar protocol stacks (except
for the explicit IPv6 callout).  That's clearly what has to be
implemented when you have roadside units, and background wired
internet.  
     Given the other infrastructure in the area, will this get any
play?  As an outlier, the big oops! splash this past week was when
Verizon throttled a San Jose firefighting team's LTE connection in the
middle of a wildfire (the TV stations around here have LOTS of lurid
wildfire footage).  I'm getting increasingly suspicious of government
attempts to do what the commercial world already is.  
     Notice that the SJ strike team was not using emergency service-
specific frequencies, protocols or infrastructure -- they had LTE
cellphones tied to the commercial network (a decade ago this was
expressly prohibited in California!;).  

Others.  Other vendors (Qualcomm is one) are pushing LTE Layer 2
solutions vice 802.11 ones.  But they're not in the NHTSA tent.  Just
whaddya suppose is in those roadside units?  (There's no engineering
reason why 'both' isn't a decent answer).  

This leaves us with the following conundrum:
  - emergency-services specific infrastructure has not done well.  
  - straight commercial infrastructure doesn't meet some critical
emergency services needs (availability, survivability, coverage, etc)
except by accident.
     How do we get past this?


b




Seastory.  A decade ago, the I-35 bridge over the Mississippi River in
Minneapolis collapsed.  Dumped a dozen cars into the river and caused a
monumental traffic jam -- it happened right at the start of afternoon
rush hour.  
     Minneapolis had just contracted (city, therefore taxpayer, money)
with an ISP to provide city-wide WiFi coverage.  Remember, a decade
ago, this was novel.  The intent was to provide primary coverage for
city use; any excess capacity could be sold publicly.  
     When the bridge collapsed, the ISP immediately dropped all
barriers to use of it's WiFi net and left it that way for a day. Today
you can get a free WiFi connection most anywhere urban/suburban in US,
but not a decade ago.  What happened was that lots of laptops in
traffic suddenly got connections so commuters could call home (the
cellphone system was jammed solid).  The effect was that the missing
person's problem was decanted -- the only missing persons left on the
list were the poor folks at the bottom of the river.  This missing
persons problem seems to occur in about half of the major disaster
situations and represents a very serious part of the response problem
-- credit for making it not happen.  





On Sat, 2018-08-25 at 21:25 +0000, William Liu wrote:
> Looks me an yummy article to share:
> http://www.govtech.com/Colorado-Will-Develop-a-Digital-Highway-Using-
> Connected-Vehicle-Technology-.html
>  
> Cheers W
> _______________________________________________
> gaia mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/gaia