Subject: [its] Arguments for using IP for automotive connectivity

From: Bob Briscoe <[email-masked]>
Date: Fri, 29 Jul 2016 10:52:08 +0100

Alexandre, Carlos, [cc'ing [email-masked], but I'm not subscribed]

I just read your article in the IETF Journal about Intelligent 
Transportation Systems.

Your arguments for using IP are largely aspirational or observational 
(ie. either "we hope IP will be used", or "we notice IP is being used").

This article [Briscoe04] gives some more solid arguments for why it is 
important and likely that most devices will implement an IP stack. Even 
though it dates from 2004 I believe most of the points it makes are 
still relevant. The argument for an interoperable generic stack is 
spread throughout, but particularly section 2.2 on connectivity, and the 
sections leading up to the straw-man proposal in section 3.1.

First, I'll quote from the conclusions to sum up the economic arguments 
for a generic stack:

    "We have questioned the assumption that tiny cheap computing devices
    will be considered disposable and application-specific. Economies of
    scale in volume device manufacturing will always favour reuse of the
    investment in generic device /designs/, whether each unit is
    disposable or not.  Also, the investment in /deploying/ devices will
    be higher than their cost, tending to encourage new ways to combine
    deployed devices to novel ends."

This last point is based on the idea from [Fine99] that different 
industries have different "clock-speeds". Because the automotive 
industry's clock-speed is so much slower than the computing industry's, 
it will want to deploy computing devices within vehicles that can be 
soft-updated many times during the vehicle's lifetime.

There is also a practical argument about creating connectivity (e.g. how 
do you platoon a set of cars that includes imported vehicles using 
different radio frequencies, or vehicles of a wide range of ages?). 
Quoting from section 2.2:

    "It is true that humans will often deploy sensor networks for
    specific purposes and ensure that their wireless transmissions can
    all reach each other, that they are all transmitting on the same
    frequencies, with the same codings and with the same application
    level languages and formats. However, many applications will include
    the creation of connectivity as part of the application. And it will
    be desirable to be able to use existing devices and models to create
    new applications. So we have to allow devices to find each other and
    form into networks in the first place. [...]

    There are dozens of radio link standards in fashion at any one time
    (Bluetooth, the WiFi family, etc), using different frequencies in
    each region. And hundreds of legacy standards still in use across
    thousands of different devices. To find each other by radio contact,
    the [device] would have to scan many frequency ranges and try all
    common [and legacy] coding, link and message formats (e.g. Jini,
    SLP, Twine, JESA, etc). The chances of such an approach leading to
    reliable seamless connectivity, any time, anywhere, are slim unless
    only one or two link standards predominate for all time.

    An alternative approach would be to arrange at least the first
    stages of connectivity over a network common to any randomly chosen
    pair of devices, which was the purpose of introducing the Internet
    protocol — an intermediary between different link technologies (‘IP
    over everything’).  So both the PDA and the monitor use their own
    link technologies to connect to their respective points of presence
    on the Internet. The monitor advertises its location on a
    geographical extension of the Web (e.g. geographic mark-up language
    or SensorML), and the [device], knowing its own location and
    coverage, uses a geographical search engine to find suitable [peer
    devices] within range.

    Clearly, the indirect approach to connectivity may also fail to
    connect our two devices due to lack of mutually understood standards
    at the application level (e.g. the XML format of the appropriate
    geographical search responses). However, the direct link approach
    has the same chances of mismatch at the application layer on top of
    the chances of mismatch at the physical, link and transport layers."

*References**
*

    [Briscoe04] The Implications of Pervasive Computing on Network
    Design, Bob Briscoe (BT), chapter in Alan Steventon and Steve Wright
    (Eds.) Intelligent spaces (2006), Springer Verlag, ISBN:
    1-84628-002-8 Pre-print: http://www.bobbriscoe.net/pubs.html#pervimp

    [Fine99] Fine, Charles H. "Industry clockspeed and competency chain
    design: An introductory essay." In /Automation in Automotive
    Industries/, pp. 6-10. Springer Berlin Heidelberg, 1999.
    http://link.springer.com/chapter/10.1007/978-3-642-59864-7_2#page-1

HTH

Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 29 Jul 2016 09:31:35 -0400

Having worked, and worked with the Automotive Industry for most of my 
life, I could refute a number of assumptions stated below. Don't have 
the energy right now, having just flown on the redeye back from IEEE 802 
plenary.

but Bob's point about the article in the IETF Journal, I have to agree 
with.  For much the same reasons.

Other fights are going on in the Industry.  What will happen in the next 
two years remains a open question.  Look for real applications that 
cannot be met by other services.  Consider that IP offers a new attack 
platform, so carefully consider how to deal with that before offering 
yet another superhighway into the cars.

On 07/29/2016 05:52 AM, Bob Briscoe wrote:
> important and likely that most devices will implement an IP stack. 
> Even though it dates from 2004 I believe most of the points it makes 
> are still relevant. The argument for an interoperable generic stack is 
> spread throughout, but particularly section 2.2 on connectivity, and 
> the sections leading up to the straw-man proposal in section 3.1.
>
> First, I'll quote from the conclusions to sum up the economic 
> arguments for a generic stack:
>
>     "We have questioned the assumption that tiny cheap computing
>     devices will be considered disposable and application-specific.
>     Economies of scale in volume device manufacturing will always
>     favour reuse of the investment in generic device /designs/,
>     whether each unit is disposable or not.  Also, the investment in
>     /deploying/ devices will be higher than their cost, tending to
>     encourage new ways to combine deployed devices to novel ends."
>
> industry's clock-speed is so much slower than the computing 
> industry's, it will want to deploy computing devices within vehicles 
> that can be soft-updated many times during the vehicle's lifetime.
>
> There is also a practical argument about creating connectivity (e.g. 
> how do you platoon a set of cars that includes imported vehicles using 
>     level languages and formats. However, many applications will
>     include the creation of connectivity as part of the application.
>     And it will be desirable to be able to use existing devices and
>     models to create new applications. So we have to allow devices to
>     find each other and form into networks in the first place. [...]
>
>     There are dozens of radio link standards in fashion at any one
>     time (Bluetooth, the WiFi family, etc), using different
>     frequencies in each region. And hundreds of legacy standards still
>     in use across thousands of different devices. To find each other
>     by radio contact, the [device] would have to scan many frequency
>     ranges and try all common [and legacy] coding, link and message
>     formats (e.g. Jini, SLP, Twine, JESA, etc). The chances of such an
>     approach leading to reliable seamless connectivity, any time,
>     anywhere, are slim unless only one or two link standards
>     predominate for all time.
>
>     stages of connectivity over a network common to any randomly
>     chosen pair of devices, which was the purpose of introducing the
>     Internet protocol — an intermediary between different link
>     technologies (‘IP over everything’).  So both the PDA and the
>     monitor use their own link technologies to connect to their
>     respective points of presence on the Internet. The monitor
>     advertises its location on a geographical extension of the Web
>     (e.g. geographic mark-up language or SensorML), and the [device],
>     knowing its own location and coverage, uses a geographical search
>     engine to find suitable [peer devices] within range.
>
>     connect our two devices due to lack of mutually understood
>     standards at the application level (e.g. the XML format of the
>     appropriate geographical search responses). However, the direct
>     link approach has the same chances of mismatch at the application
>     layer on top of the chances of mismatch at the physical, link and
>     transport layers."
>
> *References**
> *
>
>     Design, Bob Briscoe (BT), chapter in Alan Steventon and Steve
>     Wright (Eds.) Intelligent spaces (2006), Springer Verlag, ISBN:
>     [Fine99] Fine, Charles H. "Industry clockspeed and competency
>     chain design: An introductory essay." In /Automation in Automotive
> Bob Briscoehttp://bobbriscoe.net/
>
>
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its