Intelligent Transportation Systems (ITS) is a generic name for using any of a wide range of information technologies to move people, freight, and other devices across roads, waterways, air, and space. Uses may include Internet access in cars, trains, and planes; multimodal itinerary planning across smart cities; high-speed multioperator road and park tolling; goods-delivery tracking; traffic supervision and management; self-driving cars and car platooning; emergency calls; and highly-improved safety of traffic of automobiles and trucks. To support such a wide range of uses, applications need reliable communication capabilities across complex systems involving a variety of mobile and fixed devices with disparate wireless and wired links. To that end, technical committees at the International Standards Organization (ISO) and the European Telecommunications Standards Institute (ETSI), an ITU collaboration effort, and a connectivity-focused US government programme are but a handful of organizations and activities carrying an ITS acronym in their names (e.g., ISO TC204 ITS, ETSI TC ITS, ITU Collaboration on ITS Communication Standards, USDOT ITS JPO).
Acknowledging that many design requirements of the early-stage Internet were related to safety, reliability, and heterogeneity, and considering the successful Internet deployments of recent decades, it is tempting to contemplate the use of the TCP/IP family of protocols to support applications in ITS use-cases. At IETF meetings, participants are versed in the design and deployment for such requirements. For example, one illustration of reliability is the best-effort nature of IP packet delivery on a path through a maze of routers worldwide, with an available alternative if a known path fails, across heterogeneous networks.
The communication systems currently used in transportation are satisfactory in some use-cases. For example, multimodal itinerary ticketing, 50km/h toll passage, and incumbent car platooning rely extensively on dedicated communication systems; they are all successful in trial phases, even though the penetration of the current[1] IP family of protocols in these use-cases is relatively limited, if not outright absent.
ITS discussions at the IETF offer hope of TCP/IP protocols in vehicular communications in the near future. TCP/IP protocol stacks are already present in many cars that are connected to the Internet with a cellular modem, typically LTE. In addition, widespread in-car technologies like MirrorLink, Apple CarPlay, and Android Auto use IP. Current demonstrators of security mechanisms for out-of-car DSRC[2] need an ancillary Internet connection, often LTE with TCP/IP support, to realize the transfer of security material (certificates, revocation lists, and so on).
Recent demonstrators featuring vehicle-to-vehicle (V2V) use-cases (e.g., platooning), rely on ITS-G5 link-layers and CAM application-layers. Within these demonstrators, the platoon size limits (number of cars in a platoon) have been exhibited due to the radio range of ITS-G5. It is believed that the involvement of IP protocols (with ETSI ITS applications) featuring IP subnet structures between cars may lead to arbitrary-size platoons (like the size of the Internet can be arbitrary), where packets are IP-forwarded rather than broadcasted.
Adopting TCP/IP would also help address the fact that the pairing operation of vehicles is independently being developed by organizations that often overlook fundamental interoperability requirements. Furthermore, recent lessons learned at a European demonstration event illustrated the necessity of sending vehicle position corrections over IPv6.
DSRC and ITS-G5 messages, such as BSP or CAM, are broadcast periodically (IP is not used); there is a need for a mechanism to allow the sender to learn whether or not a message was received with a certain degree of reliability. Using the request-response semantics of some IP protocols may help achieve improved reliability when necessary (e.g., ICMP Neighbor Solicitation/Advertisement, or TCP SYN/ACK).
Arguably, where smartphone-to-server TCP/IP is the preferred method of mobile interaction, rarely, if ever, does a deployed multimodal travel planning application run on IPv6. More importantly, too often application-glued-on-link communication protocols (i.e., protocols without networking layers[3]) are involved in communications between automobiles. In this context, further involvement of applications relying on TCP/IP and of IP forwarding mechanisms is expected to result in significant improvements to the security of communications (IPsec), and orders of magnitude more interactions between numerous directly reachable devices in vehicles (IPv6). Applications that are unimaginable today will be possible, when every car can talk to every other car around the world, as computers do via the Internet. And since the value of the network grows with the number of connected parties, it is expected that the Internet’s value and reach will increase even more when cars are connected. The potential growth can be further illustrated by vehicles forming an independent network on a road linking smart cities; to some extent the question whether to connect the network of vehicles to the Internet may be turned the other way around.
The ITS BoF in Buenos Aires
Participants at the IETF have published Internet-Drafts that are explicitly or implicitly related to ITS use-cases on many occasions in recent years. In April 2016, at the IETF meeting in Buenos Aires, a Birds-of-a-Feather (BoF) meeting, chaired by Carlos Pignataro and Russ Housley, was held specifically on the topic of ITS. Problem statements were discussed about the use of IP in vehicle networks: IP for vehicle-to-vehicle and vehicle-to-infrastructure communications, IPv6-over-foo, IP path establishment, and naming. The presented use-cases involve direct communications between vehicles (V2V), for example, vehicle platooning. Additional use-cases involve communications between a server situated along or near the road (Road-Side Unit) and vehicles passing by. A tutorial on the use of IP in vehicle networks exposed the advantages of a narrow-waist networking layer (compared with network layer absence or with other link-specific or application-specific networking layers), including the support of link layers, such as 802.11-OCB (also known as DSRC or 802.11p), with a variety of modulation methods (e.g., WiFi, LTE, and VLC). Other aspects of using packetised data exchange principles were described as comparing favorably to the use of bouncing-signal principles of communication between vehicles, such as when Light Detection And Ranging (LIDAR) or cameras are involved (Figure 1). These two aspects raised a number of comments from the audience; together with the previously expressed security and privacy concerns, these comments can be found in the meeting minutes.
The establishment of a Category A liaison between the IETF and the ISO Technical Committee TC204, ITS, was announced during the ITS BoF in Buenos Aires. One liaison statement from ISO/TC204 was announced, with a slide set from the ISO/TC204 liaison officer.
Charter Work and Interim
The initial text of a charter[4] for an ITS WG was presented in Buenos Aires. In the initial phases of charter writing, a significant number of work domains were suggested: communications between automobiles (V2V, V2I), space, airline, and unmanned aerial vehicle communications, information- and content-centric networking applied in vehicular communications, alternative mobility protocols and locator-identifier split for networked vehicles (AERO, LISP) and more. Facing this potentially enormous scope, extensive discussions led to more than just improving the text, it helped narrow down the number of deliverables: two Informational documents on the context and the problem statement for the use of IP in vehicular communications, and one Standards Track document on “IPv6-over-802.11p”. This charter structure was further finalized during the virtual interim ITS BoF held on 31 May 2016 via audio-conference with remote slide presentation. The details are described in the minutes of the virtual interim meeting.
The item “IPv6 over 802.11p” is regarded as a typical IETF “IPv6 over foo” document, based on “IPv6 over Ethernet” RFC 2464. The model of an IPv6-over-802.11p layered stack of protocols can be compared against other models of running IPv6 over 802.11p (DSRC) found at pertinent Standards Development Organizations. Three such models are illustrated in Figure 2.
Prior to the BoF in Buenos Aires, the topic of vehicular networks was presented at the IETF 93 technical plenary in Prague, Czech Republic. Presentations from academic and industry experts in vehicle networks, security, and standardization were discussed. For more on the plenary, see “Vehicular Networks Are Expected to Save Lives But Carry Privacy Risks,” IETF Journal, Vol. 11, Issue 2 (https://www.internetsociety.org/publications/ietf-journal-november-2015/vehicular-networks).
A Proposal for an ITS WG
The goal of the proposed ITS WG is to standardize and/or profile IP protocols for establishing direct and secure connectivity between moving networks.
Definitions
The Working Group defines the terms V2V, V2I, and V2X as follows:
V2V (vehicle-to-vehicle communications). The communications can be direct (without requiring an access point or relay by the road-side), or indirect (relying on one or multiple relays along the road-side).
V2I (vehicle-to-infrastructure communications). Data flows happen between a mobile vehicle and a server in the fixed infrastructure nearby. Sometimes V2I stands for vehicle-to-Internet communications, referring to a server anywhere in the Internet.
V2X (vehicle-to-‘any other’ communications). In some contexts it is a handy term to mean both V2V and V2I at the same time, e.g., “V2X technology enables a vehicle to stay connected to both the Internet and other cars”. In other contexts it means vehicle-to-‘something other than vehicle or infrastructure, most notably a human’ communications, e.g., V2P (vehicle-to-pedestrian), V2N (vehicle-to-nomadic pedestrian), and V2D (vehicle-to-device of pedestrian).
Models and Use-Cases
Two use-cases were discussed at the BoF: cooperative adaptive cruise-control (C-ACC) and platooning. These communication models are illustrated in Figures 3 and 4.
Looking Forward
The charter text is now stable, and work has started on the initial work items. Four Internet-Drafts have been identified as good candidates for the first three work items. More people have joined the email list and some of those have expressed interest in submitting Internet-Drafts to address the goals in the current proposed charter.
If you are interested in the use of IP protocols in vehicular communications, please subscribe to the email list https://ietf.org/mailman/listinfo/its and submit an Internet-Draft targeting one of the three proposed work items: ITS General Problem Area, IPv6 over 802.11p, or Problem Statement. You are also invited to read the existing Internet-Drafts in this group, review them, and make comments.
Footnotes
[1]Ahead of general thinking, the IETF considers the current version of the IP family of protocols to be IPv6. Work is being considered to declare IPv4 as “Historic”, or “Restricted Standard”, and, simultaneously, work is ongoing to promote IPv6 as “Internet Standard”. See page 1.
[2]The term Dedicated Short-Range Communications (DSRC) is used with multiple meanings. An earlier IETF Journal article defines DSRC as “802.11e for quality of service; 802.11j-2004 for half-clocked operations, which are a more robust form of communication; and 802.11p for operation in the 5.9 GHz band and a new mode called OCB for Outside the Context of a Basic Service Set.” Also, DSRC MAC and PHY layers are defined by ASTM E2213 – 03(2010), which may refer to IEEE documents. The DSRC application layer is defined by SAE J2735_201603. In Europe, DSRC is defined by CEN/TC278. An additional standard used in Europe for 5 gigahertz, in lieu and place of DSRC, is defined by ETSI as “ITS-G5”.
[3]An early example of an application protocol glued onto the link layer (without a network layer) is the Wireless Application Protocol (WAP). It was used in the initial deployments of interactive applications in the first smartphones, only to be phased out by the arrival of TCP/IP. Today, WAP has largely disappeared, yet similar tendencies persist to develop such protocols within and outside ITS.
[4]See the latest proposed charter at https://tools.ietf.org/wg/its/trac/ .