Multi-Access Edge Computing --> ITS Roadway Equipment:
signal preemption request
This flow may also be implemented by
Connected Vehicle Roadside Equipment --> ITS Roadway Equipment: signal preemption request Definitions
signal preemption request (Information Flow): Direct request for preemption to a traffic signal controller that results in preemption of the current control plan and grants right-of-way to the requesting vehicle. This flow identifies the required phase and timing of the preemption. This flow may also cancel the preemption request (e.g., when the requesting vehicle clears the intersection).
Multi-Access Edge Computing (Source Physical Object): 'Multi-Access Edge Computing' ((MEC) previously known as mobile edge computing) represents computing devices that operate and are managed like a cloud server, but are deployed at the edge of a network (typically a cellular network, but it could be any network). While not in strict proximity to the transportation network, these systems do benefit from vastly decreased distances to the roadway compared to central systems, and so can provide lower latency than strictly backoffice systems
ITS Roadway Equipment (Destination Physical Object): 'ITS Roadway Equipment' represents the ITS equipment that is distributed on and along the roadway that monitors and controls traffic and monitors and manages the roadway. This physical object includes traffic detectors, environmental sensors, traffic signals, highway advisory radios, dynamic message signs, CCTV cameras and video image processing systems, grade crossing warning systems, and ramp metering systems. Lane management systems and barrier systems that control access to transportation infrastructure such as roadways, bridges and tunnels are also included. This object also provides environmental monitoring including sensors that measure road conditions, surface weather, and vehicle emissions. Work zone systems including work zone surveillance, traffic control, driver warning, and work crew safety systems are also included.
Included In
This Triple is in the following Service Packages:
This triple is associated with the following Functional Objects:
This Triple is described by the following Functional View Data Flows:
- None
This Triple has the following triple relationships:
| None |
Communication Solutions
Characteristics
| Characteristic | Value |
|---|---|
| Time Context | Recent |
| Spatial Context | Adjacent |
| Acknowledgement | True |
| Cardinality | Unicast |
| Initiator | Source |
| Authenticable | True |
| Encrypt | True |
| Interoperability | Description |
|---|---|
| Local | In cases where an interface is normally encapsulated by a single stakeholder, interoperability is still desirable, but the motive is vendor independence and the efficiencies and choices that an open standards-based interface provides. |
Security
| Information Flow Security | ||||
|---|---|---|---|---|
| Confidentiality | Integrity | Availability | ||
| Rating | Moderate | High | Moderate | |
| Basis | It does not matter if someone is able to eavesdrop on this request. There will be many other more obvious indicators that the request was made, such as sirens and flashing lights on the emergency vehicle; however, all communications between field infrastructure should be protected from viewing to prevent attackers from analyzing traffic and developing attack methods. | The system must be able to trust these requests. Emergency Vehicles should be able to send these requests and know that they are being operated on by the receiving system. Additionally, if an unauthorized vehicle is able to send these requests it could bring traffic to a standstill by disrupting signal coordination citywide. | The alternative to this request is existing mechanisms – such as using the sirens to stop traffic. The difference between the emergency signal preemption application and existing practice is not significant enough to justify a HIGH availability requirement. | |
| Security Characteristics | Value |
|---|---|
| Authenticable | True |
| Encrypt | True |