| Network Working Group | A. Petrescu |
| Internet-Draft | CEA, LIST |
| Intended status: Informational | D. Liu |
| Expires: April 22, 2016 | Alibaba |
| C. Perkins | |
| Futurewei | |
| October 20, 2015 |
Problem Statement for IP in ITS use cases C-ACC and Platooning
draft-petrescu-its-problem-01.txt
Two vehicle-to-vehicle communications use cases are discussed, namely Cooperative Adaptive Cruise Control (C-ACC) and Platooning. For these two use cases, the problems are identified that pertain to development with Internet protocols and connectivity.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 22, 2016.
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Recent years have seen growing interest in vehicle-to-vehicle communications. C-ACC and Platooning are two use cases that hold promise for major increases in vehicle safety as well as fuel efficiency. In this document we explore the problem of realizing solutions for these use cases using well-known Internet protocols and applications.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
This document defines the following terminology:
Several use-cases in Intelligent Transportation Systems (ITS) may be implementable using the TCP/IP suite of protocols and consequently benefit from the global availability of Internet connectivity. Cooperative Adaptive Cruise Control (C-ACC) and Platooning are two such use cases. They both require low-latency data exchanges between vehicles. For these use cases, connecting the vehicles through long-range cellular networks typically incurs too much delay. Instead, it is necessary to connect vehicles directly, by using shorter-range communication technologies.
A vehicle embeds several IP devices, forming a stable network. Typically, Ethernet cables are run through a car, together with the CAN networks. Computers in an automobile perform an ever-growing variety of sensing and control tasks. Typically one edge router is in charge of wireless communications outside the car, potentially via multiple technologies.
The problem is how best to establish low-latency IP communication paths between the computer on the networks embedded in two or more neighboring and potentially fast-moving vehicles. The C-ACC use-case illustrates this problem. When a vehicle sends its coordinates to the vehicle behind it, the latter vehicle may subsequently act by braking under certain circumstances, which then must trigger immediate responses from the other cooperating vehicles.
Vehicle 1 Vehicle 2
e.g.
o)) LTE D2D ((o
| 802.11p |
| LiFi |
| |
+------+ +--+--+ +--+--+ +----------+
|GPS PC| | eR1 | | eR2 | |Braking PC|
+--+---+ +--+--+ +--+--+ +-----+----+
| | | |
| | | |
| Ethernet | | Ethernet |
-+-----------------+- ---+--------------+-----
2001:db8:1::/40 2001:db8:2::/40
Figure 1: Two vehicles with wireless link
Figure 1 depicts two vehicles in close range. Their respective edge routers (eR1 and eR2) can exchange data by using a short-range link-layer wireless technology such as LTE D2D, IEEE 802.11p, Bluetooth, LiFi, among others.
The Ethernet (egress) interfaces of eR1 and eR2 form a single IP subnet. In the figure, there is only one IP hop (a wireless link) between eR1 and eR2.
Within each vehicle there is at least one subnet, but there are potentially several distinct IP subnets in each vehicle. For the case in which there is only one subnet in each vehicle, the IP hop count between one IP device in one vehicle and the IP device in another vehicle is at most 3: 1 IP hop in each vehicle and 1 IP hop between the vehicles.
As an application example, the "GPS PC" in one vehicle sends IP datagrams containing its coordinates to the Braking PC in the other vehicle, controling braking. The IP datagrams are sent through the respective edge routers.
In order for GPS PC to reach Braking PC it is necessary that the two edge routers have forwarding information about their respective subnets: eR1 must learn that prefix 2001:db8:2::/40 is reachable through eR2, and vice-versa. It is thus necessary that they exchange routing information. Otherwise, the GPS PC and Braking PC can not reach one another.
The problem is divided in a discovery sub-problem (how edge routers discover each other) and a prefix exchange sub-problem (how edge routers exchange routing information).
Various information needs to be discovered to set up the IP communication between the vehicles. The information that needs to be discovered by an edge router includes link layer, MAC layer and IP layer information.
For link layer information, wireless link layer parameters need to be obtained. For example, determining the power level of received wireless frames can be used to determine the distance between two neighboring vehicles.
For MAC layer information, the MAC address information of the neighboring edge router needs to be discovered.
For IP layer information, in the above figure, eR1 needs to discover the IP address and IP prefix of eR2 and eR2 also needs to discover the IP address and IP prefix of eR1. Other multicast related information may also need to be discovered.
Service-related information sometimes is also needed. For example, a vehicle might wish to indicate that it offers video translation or VPN services to headquarters.
As mentioned earlier, establishing single-hop forwarding between two neighboring vehicles is part of the overall problem for supporting C-ACC and platooning.
There are two modes of operating a V2V topology:
The peer-to-peer operation of a V2V topology is an important aspect of ITS use cases such as C-ACC and Platooning. This mode of operation allows each vehicle to send and receive application data (coordinates, speed) as IP packets, without the need of assistance from fixed infrastructure. Each vehicle is preconfigured with a unique IPv6 prefix and each computer in a vehicle is identified by a unique IPv6 address.
In order for one computer in one vehicle to reach another computer in another vehicle the edge routers in each vehicle have to learn the IPv6 prefix (and/or the IPv6 address) of the other vehicles. A prefix-exchange mechanism is needed, otherwise the IP communication cannot be established.
After each vehicle has informed the other vehicles nearby about its prefix, the forwarding tables of each vehicle must be updated to contain the tuple [prefix; IP address] of the other vehicles. The updating has to deal with situations when vehicles leave the network, otherwise numerous ICMP Destination Unreachable messages may cause undesirable interference on the inter-vehicle medium.
It is likely that vehicles will join and leave the set of cooperating vehicles for cruise control, and similarly for vehicles in a platoon. Then the neighbor relationships would need to be re-evaluated, and subnet reachability information would also require updates.
In order to establish bidirectional communications with the fixed infrastructure, edge routers must have a topologically correct prefix with the first hop router of the chosen access network for the fixed infrastructure. In order for this to happen, the edge router must first discover the access router for the chosen access network.
In order to be effective, the discovery and exchange operations need to be completed very quickly in order to serve the needs of fast-moving vehicles.
As is the case with typical V2V use cases, privacy is a very important consideration. Information identifying the vehicle could very likely be used to get accurate information about the identity of the driver, and thus the identifiers used for the use cases in this document should be randomly assigned for the purposes required without any necessary correspondence to the actual vehicle identification.
Other information stored in each vehicle's networks must not be inadvertently disclosed by protocol errors or by misuse of supported applications.
There are no IANA actions specified within this document.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [I-D.liu-its-scenario] | Liu, D., "Scenario of Intelligent Transportation System", Internet-Draft draft-liu-its-scenario-00, March 2015. |
| [I-D.petrescu-ipv6-over-80211p] | Petrescu, A., Pfister, P., Benamar, N. and T. Leinmueller, "Transmission of IPv6 Packets over IEEE 802.11p Networks", Internet-Draft draft-petrescu-ipv6-over-80211p-02, June 2014. |
The changes are listed in reverse chronological order, most recent changes appearing at the top of the list.