Connected Communities Infrastructure - Roadways Solution
Roadways and intersections have grown more complex since the first traffic lights were installed. Whether it’s a two-lane road or a multi-level stack interchange, safety, security, and optimization are paramount. To achieve these goals, a traffic management center needs ever higher levels of connections to the infrastructure. This includes monitoring traffic patterns, weather conditions, and even communicating with the vehicles themselves.
Components
The components needed to achieve this connectivity are summarized below:
This includes the applications and services which connect to and monitor the roadside devices. These applications can be on the premises, in the cloud, or a combination of both.
This is the backbone network that connects the roadside to the customer-owned headquarters or datacenter. This network can be customer-owned dark fiber, leased lines from a public service provider, or cellular based -- or some combination of all of these.
At the roadside or intersection are the roadways devices and network components that monitor and analyze traffic. These can include traffic light controllers, weather sensors, traffic/pedestrian detectors, dynamic message signs, and V2X Roadside Units (RSU). The networking components include the routers, switches and computing modules that can analyze data and communicate back to the traffic management center.
This design guide covers numerous use cases related to the operations and management of a corridor, roadside, or intersection.
At the heart of an efficient traffic intersection is the ability to provide traffic signals for routing traffic. As traffic volume increases, it is imperative that the signal timing reflects how and when traffic flows through an intersection. And when a single street can have many intersections, it is important to be able to optimize the entire system of traffic controllers to minimize unsynchronized lights which increases flow rate and even fuel efficiency.
Closely linked to traffic signal controllers are video detectors. While simple (inductance) loop detectors in the road can sense when a car is in the lane, video detectors, using their analytics, can “see” pedestrians, bicycles, as well as vehicles. This enables better awareness of how many people and vehicles are using the roads at what times of day and in what volumes.
Depending on the capabilities of the system in place, this insight can even be used to dynamically adjust the Signal Phase and Timing (SPaT) of the traffic controller, and whether the detection system is based on loops, video, radar, microwave or lidar they all need connectivity to allow the data, which could be vehicle counts, classification, vectors etc., to be shared with traffic engineers.
Some intersections may be heavily susceptible to adverse weather conditions like rain, snow, ice, wind, etc. In these cases, a Road Weather Information System (RWIS) can be used to provide that data and alerts to an operator in the traffic management center. In a connected roadside network, this data can also be used to influence the operation of the intersection.
In a roadways scenario, information can be given to drivers in a few safe ways. Dynamic/Variable Message Signs (DMS/VMS) like those seen on a highway overpass can convey information to a large number of drivers but can also include variable speed limit signs on a single street. When connected to the roadside network, these devices can be monitored and adjusted remotely in near real time which reduces labor and increases safety and efficiency.
Another emerging way of passing information to the driver is using Connected Vehicle technology. Radios installed in a vehicle can communicate with radios at the roadside using short distance DSRC or C-V2X communication. These roadside units RSUs can send numerous message types to onboard units (OBU) installed on a vehicle to convey information that is localized to a single intersection. Additionally, the OBU can send telemetry data to the RSU which effectively makes it an anonymous mobile sensor. These messages follow the SAE J2735 standard and some commonly used messages are listed below.
Table 2 SAE J2735 Messages (continued)
In addition to communicating with an application in the cloud or on premises, these roadside devices frequently must interact with each other or 3rd party applications as part of a larger traffic management system. The National Transportation Communications for Intelligent Transportation System (ITS) Protocol (NTCIP) is a set of standards used in the United States as well as other countries that provide rules for communicating along with the object definitions needed to let equipment from different manufacturers work together as a unified system. This common set of rules is implemented by relying on SNMP to get and set the appropriate OIDs.
More details can be found at https://www.ntcip.org.
The architecture to support these use cases is detailed in the next sections.
Solution System Level Overview
CCI Roadways and Intersections Solution System Level Architecture depicts a high-level system view of the Roadways and Intersections Solution under the CCI infrastructure.
Figure 1 CCI Roadways and Intersections Solution System Level Architecture
Centralized Infrastructure
This is the area encompassing the CCI data center or headquarters PoP and the shared services. Included here are the services that monitor traffic data including roadside equipment, video analytics, and device managers that communicate with cloud services for the roadside devices.
Because numerous devices are needed to make a complete traffic management system, there are numerous ways to consume the data from a roadside device. This can take the form of aggregating the data in a larger traffic management platform which consumes data from compatible equipment, or it can be a single application that communicates with a specific type of equipment. And because of the variety of network interfaces available at a location due to cost or age, traffic profiles are usually low bandwidth to accommodate cellular connections or other low bandwidth options.
As roadside networks continue to modernize and data starts moving to the cloud, it is necessary to provide solutions for those devices with direct Internet access and those who do not have a direct connection. For those networks with limited access to the cloud, a device manager can be installed in the management center that communicates with the roadside device and then sends the data to the cloud application. This device manager can be installed in a secure environment and act as the gatekeeper between the potentially insecure roadside devices and the Internet.
Backhaul
The CCI infrastructure supports three types of backhaul:
- transparent backhaul where traffic resides entirely within the SDA fabric using an SDA Transit (e.g. routed over a private or dark fiber, or using a wireless technology such as CURWB)
- opaque backhaul where traffic exits the SDA fabric domain to an IP transit network (e.g. a Service Provider or private MPLS network) and returns to the SDA fabric at the other side of the transit network
- cellular backhaul for remote locations where traffic behind a cellular router travels over a public cellular network and enters the SDA fabric domain through a firewalled connection at the customer site
Refer to the section “Backhaul for Points of Presence” in the CCI General Solution Design Guide for more information. All types of backhaul are applicable for the roadside environment.
Connected Roadside
The CCI network spreads across a large geographical area, logically divided into several Points-of-Presence (PoPs). Each Edge PoP has one or more Access Rings comprised of extended or policy extended node IE switches (Maximum 30) in a Resilient Ethernet Protocol (REP) ring. The IE switch models include IE3300, IE3400, IE 4000, and IE 5000. Refer to the “Point of Presence (PoP)” section in the CCI General Solution Design Guide for more detail.
If a hardwired connection is not available to the roadside or intersection, a cellular or wireless connection can be used. In the case of cellular, this is called a Remote Point of Presence and more details are found in that section. If higher throughput is needed or the location is nearby a wired connection, a wireless connection using Cisco Ultra Reliable Wireless Backhaul can be used to extend the connectivity. See the section on “CURWB Fixed Infrastructure” in the CCI General Solution Design Guide for more details.
The roadside devices connect to the IE switches in the PoPs within a roadside virtual network (VN) and based on the segmentation rules, can be segmented to a high degree.
Roadside Cabinet and Devices
The roadside devices at the edge enable the operator to monitor the safety and status of the intersection or corridor. The devices can be standalone and operate independently of any other system, such as a traffic signal controller. They can also be integrated into a larger system such as having several weather sensors that are part of a Road Weather Information System. The weather sensors may be analog or digital and connected to a datalogger that gathers all the data into a single interface for efficient data capturing.
To leverage the power of the CCI Solution, it is recommended to use IP enabled roadside devices instead of serial or other legacy type connections, however if only serial is available Cisco industrial routers can be used to encapsulate RS-232 and RS-485 serial over an IP network.
The roadside is further enhanced within the CCI network because of the centralized management system and integration with datacenter as well as cloud resources. With Cisco DNAC, not only are the roadside cabinet network switches securely onboarded and provisioned, but the roadside devices can also be onboarded securely using 802.1x or MAB. Even the cabinet door state can be monitored within Cisco DNAC by using the contact closure alarm input on the IE switch to send a syslog message when the door opens or closes. Details on alarm input configuration can be found here: https://www.cisco.com/c/en/us/td/docs/switches/lan/cisco_ie3000/software/release/15-0_2_ey/configuration/guide/IE3000Config/swalarms.html. Furthermore, when using the “dying gasp” feature on the IE switch, a message can be sent to Cisco DNAC indicating that a switch lost power instead of only being informed that the switch was unreachable. Details on dying gasp can be found here: https://www.cisco.com/c/en/us/td/docs/routers/connectedgrid/cgr2010/software/15_2_3_t/configuring_dying_gasp.html.
Other IP-enabled roadside devices work in conjunction with a cloud application that provide monitoring and analytics for all such devices installed across all the intersections. These devices can use the secure CCI network to reach the cloud applications without requiring an out of band cellular modem. For example, products from Econolite, a traffic signal controller manufacturer, can be installed at the traffic intersection and communicate with the cloud application. Centracs(R) Mobility, also from Econolite, can monitor the traffic signal controller status and analyze traffic patterns while still using the overall CCI security data policies. The VantageNext(R) video detection system from Iteris can also be used with the VantageLive!(TM) cloud application to count and analyze pedestrian, bicycle, and vehicle traffic giving traffic engineers more data to increase optimization and safety at the intersection.
Traffic engineers can also use V2X radios installed in the roadside cabinet to communicate with appropriately configured vehicles as mobile sensors. As vehicles communicate with the V2X radios, they can transmit their direction, speed, and any events such as traction lost or hard braking. This data can be correlated with video analytics and traffic light patterns to further optimize the intersection efficiency and safety.
Security between the V2X radios is essential as an RSU and OBU need to ensure they are communicating with legitimate devices. The current security mechanism is known as Security Credential Management System (SCMS) and is detailed below.
- Ensures integrity: users can trust that the message was not modified between sender and receiver
- Ensures authenticity: users can trust that the message originates from a trustworthy and legitimate source
- Ensures privacy: users can trust that the message appropriately protects their privacy
- Interoperability: different vehicle makes, and models will be able to talk to each other and exchange trusted data without pre-existing agreements or altering vehicle designs
- SCMS is one security concept under review for V2X. SCMS is not documented in detail as part of CCI. More information can be found IN the Security Credential Management System (SCMS) Proof Of Concept (POC) at the following URL:
Connected Communities Infrastructure - Roadways Solution Design Guide
Bias-Free Language
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
- Updated:
- November 8, 2021
Feedback