CAVWAY Components
|
CAVNET
|
|
Components discussed here have been modeled in the CAVWAY Software Prototype (CSIM), meant as a proof-of-concept model. The CAVWAY Communications Network (CAVNET) is discussed in the right-hand column.
Roadway Early CAVWAYs are likely to comprise lanes taken from existing freeways. A typical CAVWAY might include two traffic lanes and a spare lane, allowing continuous traffic flow even when one lane is blocked, and some traffic flow even when two lanes are blocked. A precedent for allocating lanes from existing freeways has been set by the existence of High-Occupancy Vehicle (HOV) or "Diamond" lanes. CAVWAY Nodes Nodes include on and off ramps, merges and splits, and intersections. Nodes will be instrumented to send, receive, and forward messages to each other using CAVNET. Hardware and software at each node will monitor local traffic loads and control access such that CAVWAY capacity is not exceeded. Mismatches between CAV access demand and CAVWAY-access supply will be addressed through protocols such as congestion pricing. Nodes will authenticate the certification-status of CAVs seeking CAVWAY entry and allocate access according to protocols in effect. Nodes can refuse CAVWAY access to CAVs whose maps or protocols are not current, whose fuel gauges or other indicators are outside accepted tolerances, or which are overweight. CAVWAY Control (CC) CAV operations will be controlled by protocols. CC will be capable of modifying protocols, such as when to change lanes, by sending messages to CAVs via CAVNET. Although CC will enable CAV coordination, CC control will be indirect. This separation of functionality will allow CC, CAVNET, and CAVs to be protected independently. Because of the critical role it will play in CAV-System operations, CC will be protected by a fault-tolerant design, such as Triple-Modular Redundancy (TMR). Navigation System CAVs on the CAVWAY will require a reliable, resilient navigation system. Present-day CAVs often rely on GPS to determine their positions. Fortunately, GPS vulnerabilities to environmental conditions and jamming are known and mitigations are in place. Unfortunately, that these weaknesses exist indicates that GPS is not invulnerable [reference]. Therefore, CAVWAY design will include a backup navigation system. A candidate backup might resemble the one now used “to ensure National Airspace System (NAS) Ground-Based Navigation” [reference]. Redundancy will protect the system from any single point of failure. The utility of such a ground-based system will be validated through critical experiments. The question of which will be the primary system need not be resolved now. |
CAVNET, the CAVWAY Communications Network, which will support message exchanges among CAVs, nodes, and the CC, is described here in the context of a layered architecture, beginning with the physical layer and moving through data link, network, transport, and applications.
The design described here is for illustration and to allow feasibility to be validated using CSIM - specifics within the layers will surely benefit from changes and improvements over time. CAVNET will be a private network available only to CAV Systems. For security reasons, it will be separate and inaccessible from public networks such as the Internet. Physical Layer As illustrated in Figure 2 below, CAVNET would comprise
CAVNET might use a Multiple-Access protocol to allocate bandwidth to CAVs sufficient to enable health-reporting. Network Layer In general, messages would pass between two nodes, or between a node and a CAV. In the first case, the sending node would transmit the message on the backbone; a receiving node would accept a message addressed to it. In the second case, routing would be based on proximity; a CAV would only communicate directly with the closest upstream node. Transport Layer CAVNET would support point-to-point, broadcast, and multicast transmissions, features well within the current state of networking practice. 
An alternative to the dedicated land line to support voice communication, would be to implement a quality-of-service [reference] feature within the backbone to support an analog to present-day voice over IP [reference]. Comparison of these options can be deferred to take advantage of appropriate network technologies at implementation time.
Point-to-Point Messages Application Layer Nodes would use point-to-point messages to allocate CAVWAY access to CAVs. CC would use point-to-point messages to signal lane assignments and lane changes to CAVs. Current multiple-access strategies include Time-Division Multiple Access (TDMA), Code Division Multiple Access (CDMA) and Frequency Division Multiple Access (FDMA). Broadcast Messages Broadcast messages would go to all nodes and CAVs. CC would use broadcast messages to send map changes to nodes and CAVs to implement detours and merges to manage abnormal conditions. CC would use broadcast messages to transmit clock-time updates to all nodes and CAVs such that all are in sync. Multicast Messages Multicast messages would go to all members in a multicast group. For example, nodes and CAVs might use multicast messages to communicate with the (three) nodes comprising the CC. CC would use multicast messages to warn affected CAVs of a blockage or other abnormal condition. |
