Subject: Re: [its] P1609.3 Networking Services and IPv6 AddressAuto-Configuration

From: Alison Chaiken <[email-masked]>
Date: Sat, 22 Jun 2013 20:56:12 -0700

Rex explains:
> John,  I've spent the past decade observing the internet-ready standards
> work for extending the internet to mobile platforms (e.g. IEEE 802.16)
> and the past three years or so specifically looking at emergency
> services -- fire, ambulance, police -- and their communications needs.
>
> But none of the NPSTC (National Public Safety Telecom Council) sources
> (to pick just one example) seem to have any reference to IEEE 1609.

Rex and all assembled, I'm intrigued in this context by the following text
about IEEE-1609.2 security that I quote from John Kenney's paper:

The certificate carries a list of PSIDs that the sender is authorized to
use in its WSM transmissions. For example,a vehicle will have certificates
authorizing it to send a WSM with the PSID that is associated with the
Basic Safety Message. The certificate may also indicate content-specific
permissions that the sender has. For example, an SAE J2735 emergency
vehicle alert message (EVAM) might be sent by a number of emergency vehicle
types, including police cars, ambulances, and tow trucks.   A siren
indication within the EVAM is permissible for an ambulance or police car,
but not for a tow truck.

Clearly a "siren indication" is an area where emergency vehicles, whatever
method they use to call back to base, may want communicate to passenger
vehicles, as well.    The superiority of a longer-range siren signal is
obvious: the further back down the road that vehicles know of impending
danger, the better for safety systems (within limits, of course).      An
emergency vehicle could, of course, use LTE to communicate to a RSU that
rebroadcasts 802.11p, but we can all guess how long it might be before such
infrastructure might be widely deployed.

> It appears that extending the internet to mobile platforms is a
> thought-piece that has lots of independent players in their own silos.

Indeed, but the history of emergency responder communications does not make
us hopeful, either.

I'm curious what readers from Europe or Asia have to say here.    Is there
a comparable reference to John K.'s
"Dedicated Short-Range Communications (DSRC) Standards in the United
States" that discusses the status of European and Asian plans?    Is there
a single ETSI document, for example, that someone like me who is just
spectating could purchase and read?

-- Alison, whose day job is writing Linux device drivers for automotive
electronics

-- 
Alison Chaiken                           [email-masked]
650-279-5600                            http://{she-devel.com,
exerciseforthereader.org}
The intermediary between the head and the hands must be the heart.    --
Thea von Harbou

---

From: Rex Buddenberg <[email-masked]>
Date: Sun, 23 Jun 2013 15:07:47 -0700

The quote has things basically right:

On Sat, 2013-06-22 at 20:56 -0700, Alison Chaiken wrote:
> Rex and all assembled, I'm intrigued in this context by the following
> text about IEEE-1609.2 security that I quote from John Kenney's paper:
> 
> The certificate carries a list of PSIDs that the sender is authorized
> to use in its WSM transmissions.

The important thing to note here is that it is the data that is being
protected.  Analogous to signing an e-mail message.  Entirely
independent of the lower layer protocols and technologies.

>  For example,a vehicle will have certificates authorizing it to send a
> WSM with the PSID that is associated with the Basic Safety Message.
> The certificate may also indicate content-specific permissions that
> the sender has. For example, an SAE J2735 emergency vehicle alert
> message (EVAM) might be sent by a number of emergency vehicle types,
> including police cars, ambulances, and tow trucks.   A siren
> indication within the EVAM is permissible for an ambulance or police
> car, but not for a tow truck. 
> 
> 
> Clearly a "siren indication" is an area where emergency vehicles,
> whatever method they use to call back to base, may want communicate to
> passenger vehicles, as well.  

Unless I'm misreading something, the private key is associated with the
siren _sender_.  Anyone can receive the message.  Further, anyone could
relay the message because the message itself is not changed.  And anyone
could validate the signature because the public key is, er, public.  

A passenger car may want to communicate with the ambulance but sending
it a siren message would not be appropriate.  Use a different keypair.  

>   The superiority of a longer-range siren signal is obvious: the
> further back down the road that vehicles know of impending danger, the
> better for safety systems (within limits, of course).   

The WSM messages appear to share the characteristic with Common Alerting
Protocol messages: they contain a geo reference and some sort of polygon
(commonly an ellipse).  

I'm not familiar with the WSM data schema but Common Alerting Protocol
is based on XML so you can inherently use the sign and crypt primitives.
Same/similar??

>    An emergency vehicle could, of course, use LTE to communicate to a
> RSU that rebroadcasts 802.11p, but we can all guess how long it might
> be before such infrastructure might be widely deployed.

To the messages, be they WSM, CAP or any of dozens of other formats,
they don't care -- routable networks are routable networks.  (BTW, what
this IEEE committee calls RSU is known as a BS -- base station -- by
IEEE 802.  TIA, of course, couldn't accept that so they call it CPE.  
> Indeed, but the history of emergency responder communications does not
> make us hopeful, either.
> 
> I'm curious what readers from Europe or Asia have to say here.    Is
> there a comparable reference to John K.'s 
> States" that discusses the status of European and Asian plans?    Is
> there a single ETSI document, for example, that someone like me who is
> just spectating could purchase and read?
> 
> -- Alison, whose day job is writing Linux device drivers for
> automotive electronics
> 
> -- 
> The intermediary between the head and the hands must be the heart.
>  -- Thea von Harbou
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its

---

From: Alison Chaiken <[email-masked]>
Date: Sun, 23 Jun 2013 18:53:22 -0700

> could validate the signature because the public key is, er, public.

Sorry, I failed to ask my question, which is:

If passenger vehicles expect WSM on 802.11p, don't emergency vehicles
then neeed 802.11p to communicate with them, irrespective of LTE plans
for emergency vehicles?     Assuredly in the Grand Connected Future we
don't expect that emergency vehicles will communicate with individual
drivers via audible alarms and flashing lights only?    And assuredly
having emergency vehicles call out siren messages over LTE to
infrastructure which sends 802.11p would be ridiculous?    Adding
802.11p to emergency vehicles will be expensive, but much less so than
adding LTE to all cars.    Even if cars have LTE for (gag)
"infotainment," we can hardly rely on that channel to convey siren
information as well.

---

From: Rex Buddenberg <[email-masked]>
Date: Sun, 23 Jun 2013 19:52:26 -0700

disentangling...

> > could validate the signature because the public key is, er, public.
Ahh.  The above was about data, and definitely not about infrastructure.
And I think WSM is indeed about data too.

ok, this is a collision -- two silos.  Shifting gears:
> for emergency vehicles? 

The cellphone companies are rolling out LTE infrastructure and it's
going in along the highways.  (It's being advertised to you as 4g).  Who
is rolling out 802.11?  

>     Assuredly in the Grand Connected Future we
> drivers via audible alarms and flashing lights only?

The first observation is that both 802.11 and 802.16 (which LTE is a
clone of) are routable networks.  So if there is dual radio-WAN
infrastructures, they will be interoperable.  That's the good news.
Indeed there's no reason a vehicle's router could not be interfaced to
each simultaneously.  

>     And assuredly

Strip off the uses for the moment; quick handwaving technical.  LTE and
802.11 are:
 - both routable networks.
 - more or less RF equivalent: both use OFDM.  Note that 1609 has what
appears to be yet another layer 1/2 protocol (John Moring???)?  The RF
range and power figures you can expect are little different than
non-protocol range figures that several modeling tools will show.  
 - all use ethernet framing within and pass the ethernet contents up
through the layer 2/3 interface, so the integration problems are
familiar.  Routers know what to do with ethernet frames ... or rather
the contents thereof.   

The difference between the two protocols is in the MAC:
  - all 802.11 protocols use CSMA of some flavor, derived from 802.3
ethernet.  This is a contention-access protocol, albeit with some
ifs/ands/buts attached.  Contention protocols are comparatively easy to
implement but they have three defects in the radio-WAN environment that
tend not to show up in the wireless LAN one:
     o contention protocols are unstable under overload.  Too many
users, too much to say, the network segment stalls.  
     o the stall point occurs at depressingly low bandwidth efficiency
levels.  Like around 20% of baseband capacity (depending again on a slew
of ifs/ands/buts).  
     o there's no way to manage your way out of this overload
situation.  

There is exactly one MAC message in WiFi: the so-called busy tone that
tells would-be SS to wait until someone else is finished (in the
labeling, this is the diff between CSMA/CD and CSMA/CA, but it's still
CSMA).  

  - 802.16 and LTE have a contention-free protocol borrowed from DOCSIS
(!!).  It's a TDMA or time-slice arrangement where the base station (BS,
what 1609 calls the roadside unit) assigns each user a time slot where
only that subscriber station transmits.  It's harder to implement (but
the problem is solved -- chipsets are readily available) but is 
     o stable under overload
     o highly bandwidth efficient
     o can be positively managed.  

Business.  At least in US, the cellphone companies are deploying LTE
(Clearwire has ceased expanding its 802.16 deployment because the market
herd all started braying LTE).  There's a bunch of marketing
namecalling, but for all practical purposes '4G' = LTE = 802.16.  I've
never heard any cellphone company or any DIY emergency service outfit so
much as mention 802.11 of any flavor.  
     (The emergency services folks think that they are going to have a
separate 800MHz LTE infrastructure.  Their reasoning is that they need
'assured access' (which I agree with) and therefore they need a separate
freq band (which I do not).  This is their conventional wisdom right
now; it hasn't met economic reality yet).  
     I agree with your observation, Alison, that two infrastructures is
on the ridiculous side.  Better to have one and invest in Ao to make it
work when the chips are down. 
     None of this has any impact _inside_ the vehicle -- it's only the
interface on the radio-WAN side of the router that cares.  And there's
no reason that the router can't have both interfaces.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 24 Jun 2013 09:07:36 -0400

Alison Chaiken <[email-masked]> wrote:
    alison> If passenger vehicles expect WSM on 802.11p, don't emergency
    alison>vehicles then need 802.11p to communicate with them, irrespective
    alison>of LTE plans for emergency vehicles?  Assuredly in the Grand
    alison>Connected Future we don't expect that emergency vehicles will
    alison>communicate with individual drivers via audible alarms and
    alison>flashing lights only?  And assuredly having emergency vehicles
    alison>call out siren messages over LTE to infrastructure which sends
    alison>802.11p would be ridiculous?

I don't know that it would be ridiculous to assume this.
I agree that the latency might suck.  I presume, however two things:

1) the route the *ambulance* or *fire* truck might take is well known
   in advance to the traffic control system ("in advance" is a relative
   term, in this I'm saying that 5s >> 0.1s maximum latency).
   So it need not be the vehicle *itself* that is calling out it's route,
   the vehicle may well be following the route that the traffic control
   system has established.

2) my observation is that flashing lights and sirens have two undesireable
   affects.  On overly consentious drivers (my mom-in-law, former er nurse),
   they yank the wheel, to get out the way, often so fast they nearly
   cause a collision themselves, even when the vehicle won't even be
   coming near them.
   On drivers who day-dream (my mom!  "oh, was there a stop sign back there?")
   they don't notice a thing until the vehicle is stuck behind them.

It would be very useful to both of them to be told that the vehicle is
coming, and that it will in fact affect them.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: John Kenney <[email-masked]>
Date: Mon, 24 Jun 2013 08:29:11 -0700

1609.2 Security Services can be thought of as operating just above
WSMP, so the signed message becomes the payload ("WSM Data") of the
WSM packet. This is subtly different than my 2011 description.

It is also correct that in the siren example the sender is indicating
that it had the authority to set a "siren in use" data field in a
higher layer message. An ambulance would have that authority. A tow
truck would not. The message would be accompanied by a certificate
containing the sender's public key, the PSID(s) the sender is
authorized to include in a WSM (presumably including the PSID value
associated with this EVAM), and possibly an SSP for each PSID. Anyone
can hear the message.

I'm not sure about the base station comment. From an 802.11
perspective there is no difference between an RSU and an OBU. There
are differences in FCC regulations.
Best Regards,
John

Sent from my iPhone

---

From: John Kenney <[email-masked]>
Date: Mon, 24 Jun 2013 08:58:45 -0700

Hi all:
A couple of comments about managing channel load in DSRC. First, we
have one channel on which Basic Safety Messages are sent (Ch. 172),
and it is this one that is likely to be most heavily loaded for the
foreseeable future. The auto industry in the US and Europe is actively
working on channel congestion control algorithms. We see throughput
maximizing at approximately 70-75% of bit rate, e.g. 4 to 4.5 Mbps
when we use the 6 Mbps modulation/coding in 11p. We can control to
this level with provable stability (paper references available for
those interested).

For other channels we have no current congestion concern, but are also
confident we can manage it if/when needed.

Best Regards,
John

Sent from my iPhone

---

From: Rex Buddenberg <[email-masked]>
Date: Mon, 24 Jun 2013 20:19:15 -0700

Michael,

We might want to consider this the snowplow case; gets past some of your
human factors issues.  Try this as a variant to the ambulance/siren
illustration.

One of my friends and sounding board for such stuff works for Wyoming
DoT.  He observes that the casualty rate among snowplow operators in Wy
is higher than among cops.  The typical accident scenario is when the
plow is working on I-80 and is overtaken by other traffic, the villain
usually a semi.  If the semi driver doesn't figure out that it is a
snowplow ahead of him until too late, he's exceeded the intertia/road
slickness limits, and rear-ends the plow.  (Trucks as a class are more
prone to push the weather limits than the family sedan.  If the family
sedan is out in this weather, and is smart, he's tucked in behind the
semi).
    In this case, visibility is routinely awful (it's snowing, and often
blowing).  And even if the plow had a siren, the semi driver probably
wouldn't hear it until too late.  The sedan behind the semi is in an
even worse situation.  
    So this is a good use case for alerting message.

---

From: <[email-masked]>
Date: Wed, 26 Jun 2013 11:19:55 +0200

Hi all,
Speaking of actual use cases it may be of interest that the German project SIMTD - "Safe, Intelligent Mobility - Test field Deutschland (Germany)" has completed to test the functionality, efficacy and feasibility for everyday use of car-to-x communication under real-life driving conditions.  Some detailed information can be found here: http://simtd.de/index.dhtml/0251caae465f8345005d/-/enEN/-/CS/-/ and	 
http://simtd.de/index.dhtml/0251caae465f8345005d/object.media/enEN/8033/CS/-/news/Presse/simTD-Pressemitteilung_2013_EN.pdf

Best regards
Dirk
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rex Buddenberg
Sent: Dienstag, 25. Juni 2013 05:19
To: Michael Richardson
Cc: Alison Chaiken; [email-masked]
Subject: Re: [its] P1609.3 Networking Services and IPv6 AddressAuto-Configuration

Michael,

We might want to consider this the snowplow case; gets past some of your human factors issues.  Try this as a variant to the ambulance/siren illustration.

One of my friends and sounding board for such stuff works for Wyoming DoT.  He observes that the casualty rate among snowplow operators in Wy is higher than among cops.  The typical accident scenario is when the plow is working on I-80 and is overtaken by other traffic, the villain usually a semi.  If the semi driver doesn't figure out that it is a snowplow ahead of him until too late, he's exceeded the intertia/road slickness limits, and rear-ends the plow.  (Trucks as a class are more prone to push the weather limits than the family sedan.  If the family sedan is out in this weather, and is smart, he's tucked in behind the semi).
    In this case, visibility is routinely awful (it's snowing, and often blowing).  And even if the plow had a siren, the semi driver probably wouldn't hear it until too late.  The sedan behind the semi is in an even worse situation.  
    So this is a good use case for alerting message.

---

From: "John Moring" <[email-masked]>
Date: Wed, 26 Jun 2013 09:04:45 -0700

Rex asked:
>appears to be yet another layer 1/2 protocol (John Moring???)? 

The IEEE 1609 WAVE (Wireless Access in Vehicular Environments) standards
assume operation over 802.11 (and specifically the mode of operation
"outside the context of a basic service set," as originally specified in
802.11p). They are intended specifically for the 5.8GHz channels allocated
by the US FCC but could be used in other bands. Unlike their ISO and ETSI
counterparts, their scope is limited to 802.11 MAC/PHY; they do not cover
other media such as LTE. 

1609 does not touch the 802.11 PHY. IEEE Std 1609.4-2010 "WAVE Multi-channel
Operation" adds some layer 2 features to 802.11, and mandates other 802.11
features such as EDCA. The primary added feature is a mechanism for
alternating between the control channel (CCH) and a service channel (SCH)
using one 802.11 radio. The use case that prompted this - safety info and
advertisements on the CCH, another application running on an SCH, each
getting half the time resources - is no longer expected to be as important,
since safety is now using one full channel as described earlier by John
Kenney.

To the best of my knowledge, the 802.11 PHY used in the US (WAVE/DSRC) and
Europe (G5) are interoperable. I would not agree that LTE and 802.11 are
"more or less RF equivalent" but I am not here as an LTE expert.

The advantage of the 802.11 media over wide area technologies is its low
latency, important for vehicle-to-vehicle safety applications. 

Regards,
John Moring

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rex
Buddenberg
Sent: Sunday, June 23, 2013 7:52 PM
To: Alison Chaiken
Cc: [email-masked]
Subject: Re: [its] P1609.3 Networking Services and IPv6
AddressAuto-Configuration

disentangling...

On Sun, 2013-06-23 at 18:53 -0700, Alison Chaiken wrote:
> >> whatever method they use to call back to base, may want communicate 
> >> to passenger vehicles, as well.
> 
> Rex answers:
> > Unless I'm misreading something, the private key is associated with 
> > the siren _sender_.  Anyone can receive the message.  Further, 
> > anyone could relay the message because the message itself is not 
> > changed.  And anyone could validate the signature because the public key
is, er, public.

> then neeed 802.11p to communicate with them, irrespective of LTE plans 

The cellphone companies are rolling out LTE infrastructure and it's going in
along the highways.  (It's being advertised to you as 4g).  Who is rolling
out 802.11?  

>     Assuredly in the Grand Connected Future we don't expect that 
> emergency vehicles will communicate with individual drivers via 
> audible alarms and flashing lights only?

The first observation is that both 802.11 and 802.16 (which LTE is a clone
of) are routable networks.  So if there is dual radio-WAN infrastructures,
they will be interoperable.  That's the good news.
Indeed there's no reason a vehicle's router could not be interfaced to each
simultaneously.  

Strip off the uses for the moment; quick handwaving technical.  LTE and
802.11 are:
 - both routable networks.
 - more or less RF equivalent: both use OFDM.  Note that 1609 has what
appears to be yet another layer 1/2 protocol (John Moring???)?  The RF range
and power figures you can expect are little different than non-protocol
range figures that several modeling tools will show.  
 - all use ethernet framing within and pass the ethernet contents up through
the layer 2/3 interface, so the integration problems are familiar.  Routers
know what to do with ethernet frames ... or rather
the contents thereof.   

The difference between the two protocols is in the MAC:
  - all 802.11 protocols use CSMA of some flavor, derived from 802.3
ethernet.  This is a contention-access protocol, albeit with some
ifs/ands/buts attached.  Contention protocols are comparatively easy to
implement but they have three defects in the radio-WAN environment that tend
not to show up in the wireless LAN one:
     o contention protocols are unstable under overload.  Too many users,
too much to say, the network segment stalls.  
     o the stall point occurs at depressingly low bandwidth efficiency
levels.  Like around 20% of baseband capacity (depending again on a slew of
ifs/ands/buts).  
     o there's no way to manage your way out of this overload situation.  

There is exactly one MAC message in WiFi: the so-called busy tone that tells
would-be SS to wait until someone else is finished (in the labeling, this is
the diff between CSMA/CD and CSMA/CA, but it's still CSMA).  

  - 802.16 and LTE have a contention-free protocol borrowed from DOCSIS
(!!).  It's a TDMA or time-slice arrangement where the base station (BS,
what 1609 calls the roadside unit) assigns each user a time slot where only
that subscriber station transmits.  It's harder to implement (but the
problem is solved -- chipsets are readily available) but is 
     o stable under overload
     o highly bandwidth efficient
     o can be positively managed.  

Business.  At least in US, the cellphone companies are deploying LTE
(Clearwire has ceased expanding its 802.16 deployment because the market
herd all started braying LTE).  There's a bunch of marketing namecalling,
but for all practical purposes '4G' = LTE = 802.16.  I've never heard any
cellphone company or any DIY emergency service outfit so much as mention
802.11 of any flavor.  
     (The emergency services folks think that they are going to have a
separate 800MHz LTE infrastructure.  Their reasoning is that they need
'assured access' (which I agree with) and therefore they need a separate
freq band (which I do not).  This is their conventional wisdom right now; it
hasn't met economic reality yet).  
     I agree with your observation, Alison, that two infrastructures is on
the ridiculous side.  Better to have one and invest in Ao to make it work
when the chips are down. 
     None of this has any impact _inside_ the vehicle -- it's only the
interface on the radio-WAN side of the router that cares.  And there's no
reason that the router can't have both interfaces.