Transit Vehicle OBE --> Multi-Access Edge Computing:
signal priority request
This flow may also be implemented by
Transit Vehicle OBE --> Connected Vehicle Roadside Equipment: signal priority request Definitions
signal priority request (Information Flow): Request from a vehicle for priority at an intersection. The request may include the priority level, the desired time and duration of service, and the intended travel path through the intersection. This flow may also allow the originator to cancel a previously issued request for priority.
Transit Vehicle OBE (Source Physical Object): The 'Transit Vehicle On-Board Equipment' (OBE) resides in a transit vehicle and provides the sensory, processing, storage, and communications functions necessary to support safe and efficient movement of passengers. The types of transit vehicles containing this physical object include buses, paratransit vehicles, light rail vehicles, other vehicles designed to carry passengers, and supervisory vehicles. It collects ridership levels and supports electronic fare collection. It supports a traffic signal prioritization function that communicates with the roadside physical object to improve on-schedule performance. Automated vehicle location enhances the information available to the transit operator enabling more efficient operations. On-board sensors support transit vehicle maintenance. The physical object supports on-board security and safety monitoring. This monitoring includes transit user or vehicle operator activated alarms (silent or audible), as well as surveillance and sensor equipment. The surveillance equipment includes video (e.g. CCTV cameras), audio systems and/or event recorder systems. It also furnishes travelers with real-time travel information, continuously updated schedules, transfer options, routes, and fares. A separate 'Vehicle OBE' physical object supports the general vehicle safety and driver information capabilities that apply to all vehicles, including transit vehicles. The Transit Vehicle OBE supplements these general capabilities with capabilities that are specific to transit vehicles.
Multi-Access Edge Computing (Destination 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
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
-
(None-Data) - Secure Wireless Internet (EU) (43)
Selected Solution
(None-Data) - Secure Wireless Internet (EU)Solution Description
|
ITS Application Entity
![]() ![]()
Development needed ![]() |
Click gap icons for more info.
|
||
|
Mgmt
|
Facilities
Development needed ![]() |
Security
![]()
|
|
|
TransNet
|
|||
|
Access
|
|||
Note that some layers might have alternatives, in which case all of the gap icons associated with every alternative may be shown on the diagram, but the solution severity calculations (and resulting ordering of solutions) includes only the issues associated with the default (i.e., best, least severe) alternative.
Characteristics
| Characteristic | Value |
|---|---|
| Time Context | Now |
| Spatial Context | Adjacent |
| Acknowledgement | False |
| Cardinality | Unicast |
| Initiator | Source |
| Authenticable | True |
| Encrypt | False |
| Interoperability | Description |
|---|---|
| National | This triple should be implemented consistently within the geopolitical region through which movement is essentially free (e.g., the United States, the European Union). |
Security
| Information Flow Security | ||||
|---|---|---|---|---|
| Confidentiality | Integrity | Availability | ||
| Rating | Not Applicable | Moderate | Low | |
| Basis | There is no sensitive or confidential information within this messages. Additionally, it could be inferred by observing either the presence of a priority-requesting vehicle near an intersection, or the effect on the timing of the intersection. This is also transmitted as a result of broadcast data. | Only specific vehicles that have been granted authorization to receive priority/preemption should be able to send this request. Allowing other vehicles to send it could negatively impact the performance of the traffic signal network, so authentication and integrity mechanisms must ensure the message cannot be forged or altered. | If the CVRSE does not receive any requests, the vehicle may not receive the priority it requested. In the worst case scenario the vehicle would be forced to wait at some lights until they turned green. It would be more useful for a device to support this application, and only have some messages received, than to not support this application at all. | |
| Security Characteristics | Value |
|---|---|
| Authenticable | True |
| Encrypt | False |


